When this policy applies
Support duration, coverage, backup responsibilities and response targets will be agreed in writing before the applicable support period begins. Ongoing support is included only where expressly stated in the project agreement.
A development project does not automatically include indefinite maintenance, hosting, monitoring or emergency support. The signed statement of work and any service-level agreement determine scope, fees, coverage dates and responsibilities. This policy does not independently create response-time or uptime guarantees, service credits or limits on mandatory legal rights.
Covered work and exclusions
A maintenance plan may include troubleshooting, correction of reproducible defects, dependency and security updates, compatibility checks, performance investigation and agreed monitoring. The supported systems, versions, environments and included hours must be listed.
New features, redesigns, major migrations, data recovery, remediation of unauthorized changes, third-party subscription charges and work outside the supported environment require separate scope unless explicitly included. Defect-warranty terms remain those in the development agreement.
Submitting a support request
Use the support channel in your agreement. If no dedicated channel has been established, contact support@koddox.com and include the project name, affected environment, time first observed, business impact, reproduction steps and a redacted screenshot or log excerpt.
Never send passwords or full production datasets through ordinary email. Provide access through an approved secure method. The team may need additional information or client approval before work can proceed.
Priority and triage
Critical: a production outage, suspected active security incident or a core workflow unavailable without a workaround. High: a major function is degraded and materially affects users. Normal: a reproducible issue has a workable alternative. Request: a question, planned change or enhancement.
These categories guide triage. Severity is assessed against actual impact, affected users and available workarounds. Acknowledgement, investigation, workaround and resolution are different milestones. Their targets, escalation contacts and update cadence belong in the SLA; no universal response or resolution time is promised here.
Coverage and international collaboration
Agree support hours, working days, holidays, time zone and emergency escalation in writing. For international clients, specify times using an unambiguous time zone and account for daylight-saving changes.
Outside-hours or 24/7 coverage requires a specifically staffed and priced arrangement. Sending an email outside coverage hours does not create an immediate-response commitment. Third-party outages may depend on the provider’s own escalation process.
Updates and change approval
For planned maintenance, assess the change, dependencies, testing requirements and deployment risk. Agree a maintenance window and notify the designated client contact when disruption is expected. Use staging or another suitable validation environment where available.
Before release, define authorization, a rollback approach and post-release checks. Emergency changes should follow the agreed incident process, including documenting why a shortened approval path was needed. Major upgrades may require separate compatibility work and commercial approval.
Backups and recovery
The support agreement must name the backup owner and define the systems covered, schedule, retention, storage protection and restoration responsibilities. A theme or source-code backup alone is not a full database and application backup.
Agree recovery point and recovery time objectives where needed, along with restoration testing. No backup or recovery service should be assumed from this page. Recovery depends on available usable backups, provider capabilities and the agreed scope.
AI systems and external dependencies
Model behavior, API contracts, usage limits, provider pricing and third-party availability can change. AI maintenance may include evaluation-set updates, prompt or retrieval changes, quality checks and review of tool permissions when specifically scoped.
A model or provider change can require regression testing and client approval. Cloud, domain, plugin, model and software subscriptions must remain current under the responsibility assigned in the agreement. Provider fees are separate unless the contract states otherwise.
Client responsibilities and reporting
Maintain designated decision-makers, provide timely approvals and appropriate access, disclose relevant changes by other suppliers and keep client-owned licenses active. Koddox should explain dependencies that prevent progress rather than silently treating a blocked task as complete.
Agree the reporting format and frequency: completed work, open issues, changes, significant risks and use of allocated hours. Unused-hour rollover, overage rates, billing, renewal and cancellation terms are set in the contract.
Exit and handover
At the end of support, agree delivery of the applicable source code, documentation, open-issue register and access inventory, subject to ownership and licensing terms. Transfer operational responsibility and review or remove access.
Data return, deletion, backup expiry and any transition assistance follow the contract and applicable legal requirements. Support after the termination date requires an extension or new agreement.
Company and contact
Koddox Technologies, 9 Star Arcade, Opposite DHA Bosan Road Gate, Multan, Pakistan. Support enquiries: support@koddox.com.
Questions? support@koddox.com