Skip to content

12. Production Support
What Client-facing triage, escalation, and resolution of production issues against strict SLAs.
Owner Support Lead and Support team, with the Development Lead for escalations.
Triggers A client submits a request through an official channel.

Summary

Production Support is the client-facing front door. Its purpose is a rapid, consistent, efficient experience for clients through clear roles, escalation paths, and strict response-time SLAs. Support gives a fast first response, triages whether an issue is client-side, an application question they can resolve, or something needing development, and escalates with a complete information block when needed. Development acknowledges and updates against defined SLAs. Code-change resolutions are logged in the tracker so they enter the normal planning flow.

Full detail

Roles

Role Responsibility
Support Lead Oversees the support process, manages the team, ensures SLAs are met.
Support Person First point of contact: initial response, triage, escalation.
Development Lead for Support Primary technical contact: acknowledges and assigns escalated issues.
Backup Development Lead Assumes the Development Lead's responsibilities in their absence.
Development Team Investigates and resolves escalated issues. Working hours 1:00 PM to 10:00 PM PKT.

The workflow

Step 1: Client request and initial response

A client submits a request via an official channel (email, chat). The Support Person MUST send a first response within 2 minutes, acknowledging receipt and setting expectations (for example, "We have received your request and are looking into it now").

Step 2: Triage and information gathering

The Support Person works to understand the issue, then decides:

  • Client-side issue (for example a device issue, not the application): the Support Person resolves it and informs the client on the same channel, making clear it was not an application issue.
  • Application issue resolvable without development (how-to question, configuration): the Support Person resolves it immediately, logs the outcome, and informs the client on the same channel.

  • Needs development support: before escalating, the Support Person gathers the full escalation information block:

    SaaS Name:
SaaS URL:
Branch:
Branch Env:
Device Type:
Build Version:
Issue Platform:
Issue Detail:

Step 3: Escalation to Development Lead

The Support Person escalates immediately via the official channel with all gathered details, and logs the issue in the Support Issues Sheet for tracking.

Step 4: Development Lead acknowledgement and assignment

Window Acknowledgement SLA
Working hours (1:00 PM to 10:00 PM PKT) within 5 minutes
Off-hours within 15 minutes

If the Development Lead does not acknowledge in time, the Support Person calls them directly. If still unavailable, escalate immediately to the Backup Development Lead. Once acknowledged, the Development Lead assigns the issue to the most relevant Development Team member.

Step 5: First development update

The assigned developer provides a first update within 30 minutes of assignment, with either a preliminary resolution or an ETA. If no update arrives in 30 minutes, the Support Person calls the Development Lead or Backup Lead.

Step 6: Second development update and resolution path

A second update follows within 90 minutes of the first, with either the final resolution or a revised ETA. If none arrives, the Support Person calls the Development Lead again. If the resolution requires code changes, the developer logs the issue in the tracker for proper tracking and sprint planning (and, if urgent, the Hotfix path).

Step 7: Communication and resolution

The Support Person relays all updates to the client clearly and promptly. Once a fix is deployed or the issue is resolved, the Support Person confirms with the client and formally closes the ticket in the system and the Support Issues Sheet.

flowchart TD
    A[Client request via official channel] --> B[First response within 2 min]
    B --> C{Triage}
    C -->|client-side| D[Resolve, inform client it is not the app]
    C -->|app, no dev needed| E[Resolve, log outcome, inform client]
    C -->|needs dev| F[Gather escalation info block]
    F --> G[Escalate to Dev Lead + log in Support Issues Sheet]
    G --> H{Ack in SLA? 5 min working / 15 min off}
    H -->|no| I[Call Dev Lead, then Backup Lead]
    H -->|yes| J[Dev Lead assigns to developer]
    I --> J
    J --> K[First update within 30 min: resolution or ETA]
    K --> L[Second update within 90 min: resolution or revised ETA]
    L --> M{Code change needed?}
    M -->|yes| N[Log in tracker for planning / hotfix]
    M -->|no| O[Relay resolution to client]
    N --> O
    O --> P[Confirm with client, close ticket + sheet]

Severity and fix timeline

The Development Team, with the Development Lead and Support Team, determines severity (Critical, High, Medium, Low). The timeline for a permanent fix is set from that assessment. Critical bugs that affect all users or cause downtime are prioritized for an immediate hotfix.

Workarounds

If Support or Development makes a temporary configuration change as a workaround, they MUST note the original configuration. If the change will stay in place for hours or days, the person who made it creates a calendar reminder (including their lead) for when it must be reverted, so temporary changes do not silently become permanent.

Example

A client reports that printing fails at one branch. Support responds within two minutes, then triages: it is reproducible in the application, so it needs development. Support gathers the escalation block (SaaS name, URL, branch, environment, device type, build version, platform, detail) and escalates on the official channel within working hours. The Dev Lead acknowledges in four minutes and assigns it. The developer gives a first update in twenty minutes with an ETA, then a fix path in the next hour. Because it is a code change, it is logged in the tracker; being branch-wide but not all-clients, it is scheduled rather than hotfixed.