Technical support is typically structured in levels: L1 (Level 1/First Line) handles common user issues — how-to questions, account access, configuration guidance, and straightforward problems with known solutions. L2 (Level 2/Second Line) handles application-level issues — bugs, unexpected behaviour, feature problems requiring investigation beyond the knowledge base. L3 (Level 3/Third Line) handles complex engineering issues — root cause investigation of difficult bugs, database issues, infrastructure problems, and issues requiring code-level analysis. We provide all three levels, with issues moving between levels based on complexity.

Response time SLAs depend on the support tier selected and are agreed in the support contract. Typical commitments: Critical (system down, complete business function unavailable) — initial response within 1 hour, active resolution ongoing; High (major functionality broken, significant user impact) — initial response within 4 hours, resolution within 1 business day; Medium (partial functionality affected, workaround available) — response within 1 business day, resolution within 3 business days; Low (minor issue, cosmetic, limited impact) — response within 2 business days, resolution in next scheduled maintenance window. These are starting points — we agree specific SLAs based on your business criticality.

Issues that require code changes move through our engineering process: the issue is diagnosed and the required fix is identified; the fix is developed and peer-reviewed; the fix is tested in a staging environment; the fix is deployed to production following the agreed deployment process. For critical production issues, we can accelerate this process — implementing an emergency fix with appropriate expedited review, then following up with a proper code change in the next release. We always document the change and maintain the production change log.

Yes. We provide support for applications built by other teams or vendors. Support onboarding for unfamiliar systems takes longer — we need time to understand the architecture, codebase, and common issues before we can respond efficiently. For systems where we have full code access, we can provide complete L1–L3 support. For SaaS or licensed software where we do not have code access, we provide L1 and L2 support while managing escalation to the vendor for L3 issues. We are transparent about what we can support without code access.

Standard support is available during business hours (with hours defined in the support contract). For businesses requiring out-of-hours coverage, we offer on-call support arrangements — providing emergency contact capability for critical production incidents outside business hours. On-call support is typically scoped to critical severity issues only — production down or severe data integrity risks — with standard issues queued for the next business day. Out-of-hours support is priced as an additional component of the support engagement.

Knowledge base development begins during support onboarding — we document the systems we are supporting, their architecture, common issues, and known solutions. As we resolve support incidents, we capture the solution in the knowledge base when it is likely to recur. We structure the knowledge base for two audiences: support engineers (detailed technical procedures) and end users (self-service guides for common questions). A good knowledge base reduces support volume over time — users self-serve common questions, and engineers resolve recurring issues faster.

Key support quality metrics: First Response Time (how quickly issues are acknowledged — a proxy for responsiveness); Time to Resolution (how long issues take to resolve — by severity tier); First Contact Resolution Rate (percentage of L1 issues resolved without escalation — higher is better); Reopen Rate (percentage of issues that are marked resolved but reported again — lower is better indicating thorough resolution); User Satisfaction Score (post-resolution rating from users); and Recurring Issue Rate (issues that occur repeatedly — indicating systemic problems that should be fixed, not just repeatedly resolved). We report all of these in monthly support reports.