This Standard Operating Procedure establishes the role-differentiated workflows, escalation paths, and handoff protocols for the operations support function. It defines what each role is authorized to do, in what order, and under what conditions authority transfers to the next tier.
A role-based SOP exists because not all operational actions belong to all roles. Executing the wrong procedure at the wrong tier, whether by under-escalating a critical issue or by over-escalating a routine one, degrades both resolution speed and team capacity. This document eliminates ambiguity by making each role's scope explicit, bounded, and non-overlapping.
Design Principle
Each section of this SOP is scoped to a specific role. Practitioners should read the section corresponding to their role and the escalation criteria section in full. Reading sections for other roles is encouraged for situational awareness but is not required for operational compliance.
Scope of Coverage
| In Scope |
Out of Scope |
Governing Document |
| Tier 1 triage and initial response |
Customer refund authorization |
FIN-POL-004 |
| Tier 2 investigation and resolution |
Data deletion requests under privacy regulations |
PRI-PCD-012 |
| Team lead override and priority adjustment |
Infrastructure provisioning and deprovisioning |
INF-PCS-007 |
| Shift handoff between all roles |
Third-party vendor escalations |
VND-PCS-003 |
| Exception handling and deviation logging |
Security incident response (Severity 1) |
SEC-PCD-001 |
Each role in this SOP carries a defined scope of authority. Acting within that scope is expected. Acting outside it without explicit authorization from the tier above is a procedure deviation that must be logged. Authority boundaries exist to protect both the practitioner and the customer, not to create bureaucratic friction.
| Role |
Primary Responsibility |
Authorized Actions |
Escalates To |
| Tier 1 Support |
Initial triage, classification, and resolution of routine issues within the defined resolution playbook |
Classify, acknowledge, apply Standard Fixes 1 to 12, close resolved tickets, escalate per criteria |
Tier 2 Support |
| Tier 2 Support |
Investigation, root cause analysis, and resolution of escalated and non-routine issues |
All Tier 1 actions, access to diagnostic tooling, config read access, apply Extended Fixes 1 to 8 |
Team Lead |
| Team Lead |
Priority overrides, cross-team coordination, SLA breach intervention, and exception authorization |
All Tier 2 actions, config write access, SLA override, exception log authorization, vendor contact |
Operations Manager |
| Operations Manager |
Policy exceptions, cross-functional escalations, and operational incident declarations |
Full authority within operations scope, policy deviation authorization, incident declaration |
Executive escalation |
Authority Boundary Reminder
Borrowing authority, applying an action that belongs to a higher tier because it seems faster, is a procedure deviation regardless of outcome. If you believe escalation criteria are not well-calibrated, log the deviation and raise it in the next SOP review cycle. Do not self-authorize.
Escalation is not a failure signal. It is a routing decision. The criteria below define when an issue has exceeded the current role's scope of authority or resolution capability and must be transferred to the next tier. Apply them without judgment. They exist so that practitioners do not need to make judgment calls under pressure.
Tier 1 → Tier 2 Escalation Triggers
| Condition | Trigger | Action |
|---|
| Time threshold exceeded |
Issue unresolved after 20 minutes of active work |
Escalate immediately |
| Standard Fix exhausted |
All applicable Standard Fixes applied, issue persists |
Escalate immediately |
| Classification uncertainty |
Issue does not clearly match any documented category |
Escalate for classification |
| Data access required |
Resolution requires accessing customer data beyond read-only profile |
Escalate, do not proceed |
| Configuration change required |
Resolution requires any system configuration change |
Escalate, do not proceed |
| Pattern detected |
Three or more identical issues reported within one hour |
Escalate + flag as potential incident |
Tier 2 → Team Lead Escalation Triggers
| Condition | Trigger | Action |
|---|
| SLA at risk |
Issue approaching SLA breach with no clear resolution path |
Notify lead immediately |
| Extended Fix exhausted |
All applicable Extended Fixes applied, root cause unidentified |
Escalate for investigation |
| Customer impact broadening |
Issue confirmed to affect more than one customer account |
Escalate + open incident draft |
| External system dependency |
Resolution requires coordination with another team or vendor |
Escalate for coordination |
| Policy exception needed |
Resolution requires action outside the defined authorization boundary |
Escalate, do not self-authorize |
Non-Negotiable Escalation
Any issue involving suspected data breach, unauthorized access, or potential regulatory exposure must be escalated to Team Lead immediately, bypassing normal escalation sequence if necessary. Do not attempt to investigate or resolve independently. Do not communicate findings to the customer before escalation.
Phase A | Ticket Receipt and Initial Classification
1
Open the ticket and record the receipt timestamp
Navigate to the queue, open the oldest unassigned ticket in priority order. Log the receipt time in the SLA tracking field. This starts the response clock.
Do not open a ticket and then leave it unassigned. Once opened, you own it until resolved or formally transferred.
2
Read the full ticket description before classifying
Read the complete customer-submitted description and any attached screenshots or logs. Do not classify based on the subject line alone. Subject lines are frequently inaccurate or incomplete.
3
Apply the classification matrix to assign a category and priority
Use the Issue Classification Matrix (REF-OPS-002) to assign both a category code and a priority level. Enter both in the ticket fields before proceeding.
Category codes: AUTH / PERF / DATA / INTG / UI / BILLING / OTHER
Priority levels: P1 (Critical) / P2 (High) / P3 (Standard) / P4 (Low)
If the issue does not clearly match any category, assign OTHER and escalate to Tier 2 for classification. Do not guess.
4
Send the acknowledgment response within SLA window
Using the approved acknowledgment template for the assigned priority level, send the initial response to the customer. Acknowledge receipt, confirm the category as you understand it, and provide the expected response time for that priority.
Do not promise a resolution time. Only a response time. Resolution time commitments require Team Lead authorization.
Phase B | Standard Resolution Attempt
5
Locate the applicable Standard Fix in the resolution playbook
Open the Tier 1 Resolution Playbook and navigate to the section for the assigned category. Identify all Standard Fixes marked as applicable to the customer's reported symptom.
6
Apply Standard Fixes in documented order. Do not skip or reorder.
Apply each applicable Standard Fix in the sequence documented in the playbook. The sequence reflects known dependency relationships between fixes. Reordering may produce unpredictable results or mask the underlying issue.
Never apply Standard Fix 7 (Force Session Reset) or Standard Fix 11 (Cache Purge, Account-Wide) without first confirming the customer is not in an active transaction. These fixes are non-reversible.
7
Verify resolution before closing or communicating resolution to the customer
After applying the fix, independently verify that the reported symptom is resolved using the verification steps documented alongside each Standard Fix. Do not rely on the customer's confirmation alone as the verification step.
8
Document the applied fix and close the ticket with the correct resolution code
Record which Standard Fix was applied, the verification method used, and the outcome. Select the appropriate resolution code. Close the ticket. Do not leave resolved tickets in an open state.
Resolution codes feed the telemetry system. Accurate coding is what enables pattern detection that prevents future escalations.
Phase A | Escalation Receipt and Context Capture
1
Accept the escalated ticket and review the full Tier 1 record
Read all notes added by the Tier 1 agent, including the classification, all Standard Fixes applied, the verification steps performed, and the reason for escalation. Do not repeat diagnostic steps already documented as completed.
2
Contact the Tier 1 agent for verbal context handoff if the ticket is less than 30 minutes old
For recently escalated tickets, a brief verbal handoff from the Tier 1 agent frequently surfaces context that was not captured in the ticket notes. This step is strongly recommended but not required if the Tier 1 agent is unavailable.
3
Update the customer with a Tier 2 acknowledgment and revised response window
Send the Tier 2 acknowledgment template, indicating that the issue has been escalated and is under active investigation. Provide the response time appropriate to the assigned priority. Do not speculate on cause or resolution approach in this communication.
Phase B | Root Cause Investigation
4
Pull the diagnostic data package for the affected account
Using the diagnostic tooling dashboard, generate the standard data package for the account: session logs (last 48 hours), error log extract, configuration snapshot, and recent change history. Record the package generation timestamp in the ticket.
Dashboard path: Ops Tools > Diagnostics > Account Package > [Account ID]
5
Identify the proximate cause using the Tier 2 Investigation Framework
Work through the applicable investigation pathway in the Tier 2 Investigation Framework (REF-OPS-008) for the ticket category. Document your findings at each decision point, not just the final conclusion. Undocumented investigation steps cannot be peer-reviewed or referenced in future cases.
Proximate cause (what caused the symptom) and root cause (why the proximate cause occurred) are distinct. Document both if identifiable. A ticket closed with only proximate cause addressed is likely to recur.
6
Apply the Extended Fix corresponding to the identified root cause
Select the Extended Fix from the Tier 2 resolution library that addresses the identified root cause, not just the symptom. If no Extended Fix matches the identified cause, do not improvise a resolution. Escalate to Team Lead with your investigation findings documented.
Extended Fix 5 (Account Permission Rebuild) and Extended Fix 8 (Integration Token Revocation) require a second-agent confirmation before execution. These actions affect live customer environments and are not reversible within the same session.
7
Verify resolution, document findings, and close with full root cause record
Complete the Tier 2 resolution record: root cause code, Extended Fix applied, verification method, and any recommended follow-up actions (configuration review, knowledge update, pattern monitoring flag). This record feeds the knowledge improvement loop.
Priority Override Procedure
1
Review the escalated ticket and the escalating agent's documentation in full
Do not accept the escalation verbally without reviewing the written ticket record. The written record is the authoritative account. Verbal context supplements but does not replace it.
2
Assess whether a priority adjustment is warranted
Apply the Priority Adjustment Criteria (PAC) documented in SEC. 03 to determine if the ticket's current priority correctly reflects its business impact. Priority adjustments must be based on documented criteria, not on customer pressure or relationship considerations.
Upward priority adjustments affect the entire queue and displace work for other customers. Document the business impact justification before applying the adjustment.
3
Apply the priority override and notify all affected parties
Update the ticket priority, log the adjustment reason in the override field, and notify the assigned Tier 2 agent and the Operations Manager if the adjustment is to P1. For P1 escalations, initiate the P1 Communication Protocol immediately.
4
Monitor the ticket at 15-minute intervals until resolved or re-escalated
Active Team Lead oversight continues until the ticket is resolved, escalated to the Operations Manager, or explicitly handed off to the incoming shift lead through the Shift Handoff Protocol (SEC. 07).
The shift handoff is the single highest-risk moment in continuous operations. More issues are lost, misclassified, or allowed to breach SLA during shift transitions than at any other point in the operational cycle. This protocol is non-optional for all roles and applies at every shift boundary, including partial-day coverage changes.
Outgoing Agent / Lead | Handoff Steps
1
Begin handoff preparation 20 minutes before shift end, not at shift end
Do not accept new tickets in the final 20 minutes of your shift unless the queue is empty and no incoming agent is available. Use this time to update all open ticket notes to current status.
2
Complete the Shift Handoff Record for all open tickets
For each open ticket, document current status, last action taken, next action required, any waiting dependencies, and the SLA clock status. The Shift Handoff Record is the incoming agent's primary context source.
Handoff Record location: Ops Dashboard > Shift Tools > Handoff Record > [Your Name]
3
Deliver a verbal briefing to the incoming agent or lead
Verbally walk through active tickets, emphasizing any items approaching SLA thresholds, any known patterns or suspected incidents, and any tickets where context was not fully captured in writing. The verbal briefing is a supplement to the written record, not a substitute for it.
If the incoming agent is not available for verbal handoff, escalate to the Team Lead before leaving. Do not leave the shift without confirming the incoming agent has received and acknowledged the Handoff Record.
Incoming Agent / Lead | Receipt Steps
4
Review the Shift Handoff Record before accepting the queue
Read the complete Shift Handoff Record before opening the queue. Flag any tickets whose status is unclear and clarify with the outgoing agent before they leave. You own the queue from the moment you acknowledge receipt of the Handoff Record.
5
Prioritize your first 10 minutes on SLA-at-risk items
Sort the open queue by SLA time remaining. Immediately action any ticket within 15 minutes of SLA breach. Notify the Team Lead of any ticket already in breach that was not flagged in the Handoff Record.
These checklists are minimum required actions at shift boundaries for each role. They are not exhaustive operational guides. Full procedures are in the sections above. They exist so that no critical operational action is missed in the context-switching pressure of shift start or end.
- Review Shift Handoff Record from outgoing agent
- Confirm acknowledgment in the Handoff Record system
- Check queue for any items at or near SLA breach
- Verify access to the Tier 1 Resolution Playbook (current version)
- Confirm classification matrix version in use matches the current published version
- Review any system status alerts posted since last shift
- Stop accepting new tickets 20 minutes before shift end
- Update all open ticket notes to current status
- Complete Shift Handoff Record for all open tickets
- Verbally brief incoming agent on active and at-risk items
- Confirm incoming agent has acknowledged the Handoff Record
- Log any observed patterns or anomalies in the shift notes field
- Review Team Lead Handoff Record from outgoing lead
- Confirm coverage for all Tier 1 and Tier 2 positions for the shift
- Review any open priority overrides and confirm current status
- Check for any active incidents or monitoring flags from the previous shift
- Confirm escalation paths are staffed (Operations Manager reachable)
- Brief the shift team on any known risks or elevated monitoring requirements
No SOP covers every situation. When a practitioner encounters a scenario that the documented procedures do not address, or where following the documented procedure would clearly produce a worse outcome, they are in an exception situation. The purpose of this section is not to discourage judgment. It is to ensure that judgment exercised outside the documented procedure is captured, reviewed, and used to improve the SOP.
What Is an Exception
An exception is any case where a practitioner takes an action that is not documented in this SOP or that deviates from a documented step. This includes both situations where the SOP is silent (the scenario is not covered) and situations where the practitioner chose not to follow a documented step.
Exception Logging Procedure | All Roles
1
Notify your tier lead before taking the exception action, if time permits
For non-time-critical exceptions, contact your tier lead before proceeding. For time-critical situations where prior notification is not possible, notify immediately after.
2
Log the exception in the ticket and in the Exception Register
Document in the ticket what the documented procedure required, what you did instead, and why. Then log the same information in the Exception Register within 30 minutes of shift end.
Exception Register: Ops Dashboard > Quality > Exception Register > New Entry
3
Flag the exception for SOP review if it reveals a gap in the procedure
If the exception arose because the SOP did not cover the scenario, not because you chose to deviate, mark the Exception Register entry for SOP Review. These flagged entries are the primary input to the quarterly SOP review cycle.
SOPs improve because practitioners flag gaps. Logging an exception that reveals a real gap is a contribution to the team's operational quality, not a report of a failure.
A procedure that is followed until it fails, and then abandoned silently, teaches the organization nothing. A procedure that is followed, found wanting, and then improved, that is how operational knowledge compounds.
Operations Quality Framework · Core Principle
The following documents govern, supplement, or are referenced by this SOP. All referenced documents are active at the time of this version's publication. Version currency should be confirmed before use in any exception or audit context.
| Document ID |
Title |
Relationship |
Owner |
| POL00001 |
Customer Support Operations Policy |
Governing policy, this SOP implements its requirements |
VP Operations |
| PCS00004 |
Support Escalation Process |
Parent process, this SOP documents procedures for stages 2 to 4 |
Operations Lead |
| REF-OPS-002 |
Issue Classification Matrix |
Referenced in Section 04, Step 3 |
Tier 2 Lead |
| REF-OPS-008 |
Tier 2 Investigation Framework |
Referenced in Section 05, Step 5 |
Tier 2 Lead |
| PCD00011 |
P1 Communication Protocol |
Invoked in Section 06 for P1 escalations |
Operations Lead |
| SEC-PCD-001 |
Security Incident Response Procedure |
Out of scope for this SOP, referenced in Section 03 |
Security Operations |
| PRI-PCD-012 |
Privacy Request Handling Procedure |
Out of scope for this SOP, referenced in Section 01 |
Privacy & Compliance |