# Support Escalation Policy: [Organization or product]

> A customer support escalation policy: support tiers, severity levels,
> response and update targets, the functional and management
> escalation paths, and the hand-off to the complaints process.
> Structure aligned with the complaints-handling guidance of ISO
> 10002:2018 and informed by the contact centre requirements of ISO
> 18295-1:2017 (both current as checked in October 2026). Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Sections 1 to 5 are the internal policy. Section 6 is a short public
  version for customers; publish it on your help centre.
- Response targets in this policy must not promise more than the
  contracts and service level agreements
  (`ops/service-level-agreement`). Where a contract is stricter, the
  contract wins.
- Keep severity definitions consistent with the operations severity
  matrix (`ops/incident-severity-matrix`) so that support and
  engineering mean the same thing by "P1".
- Common pitfall: treating every escalation as a complaint, or every
  complaint as a technical escalation. Section 5 keeps the two apart
  and links them.
- Sector rules can set mandatory complaint deadlines and referral
  rights (for example in financial services, telecoms and utilities).
  Check the rules for your sector and country; this policy is a
  documentation format, not legal advice.
-->

## Document control

<!-- Guidance: Review at least yearly and after any major incident that showed a gap in the escalation path. -->

| Field | Value |
|---|---|
| Document ID | [CS-POL-ESC-001] |
| Version | [1.0] |
| Status | [Draft / Approved] |
| Owner | [@head-of-support] |
| Approved by | [@vp-customer-success] |
| Applies to | [Products, regions, customer plans] |
| Last updated | YYYY-MM-DD |
| Next review | YYYY-MM-DD |
| Classification | [Internal; section 6 is public] |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 *(Example)* | 2026-10-30 | Head of support | First issue |

## 1. Purpose and principles

<!-- Guidance: Short principles that staff can apply when the table does not fit the case. ISO 10002 clause 4 lists guiding principles for complaints handling such as transparency, accessibility, responsiveness, objectivity and confidentiality; reflect them in your own words. -->

This policy makes sure that a customer problem reaches the person who
can solve it, in time, and that the customer always knows who owns it.

- **Easy to reach:** customers can raise and escalate an issue through
  published channels at no charge.
- **One owner:** every case has one named owner at all times, even when
  others work on it.
- **Severity drives speed:** targets depend on business impact, not on
  who shouts loudest.
- **Keep the customer informed:** updates arrive before the customer has
  to chase.
- **Fair and confidential:** cases are handled objectively; personal
  data is used only to solve the case.
- **Learn:** escalations are reviewed for causes, not only closed.

## 2. Support tiers

<!-- Guidance: Describe who does what at each tier and the entry criteria. A tier is a capability level, not a queue name. -->

| Tier | Who | Handles | Hands up when |
|---|---|---|---|
| Tier 0 | Self-service: help centre, status page, community | Known questions, status | Customer opens a case |
| Tier 1 | Support agents | Intake, triage, known fixes, how-to | No known fix within [60] minutes, or severity P1 or P2 |
| Tier 2 | Senior support engineers | Diagnosis, configuration, reproduction | Product defect or infrastructure fault suspected |
| Tier 3 | Engineering on-call, product specialists | Defects, outages, data repair | n/a (owns fix, support keeps customer owner role) |

## 3. Severity and targets

<!-- Guidance: Define severity by impact and urgency with examples from your product. The figures below are illustrative examples, not benchmarks. -->

| Severity | Definition | Example | First response | Update interval | Target to restore or workaround |
|---|---|---|---|---|---|
| P1 *(Example)* | Service down or data at risk for many users, no workaround | Customers cannot log in | 30 min, 24x7 | Every 60 min | 4 h |
| P2 *(Example)* | Major function impaired, workaround hard | Reports fail for one region | 2 h, business hours | Every 4 h | 1 business day |
| P3 *(Example)* | Minor function impaired, workaround exists | Export slow | 1 business day | Every 2 business days | Next planned release |
| P4 *(Example)* | Question or request | How to set up a rule | 2 business days | On change | n/a |

Rules:

- Tier 1 sets the severity at intake; any tier may raise it. Lowering it
  needs the customer's agreement or a team lead's note.
- Response times are measured from case creation to first human
  response, not an automatic acknowledgement.
- Contact centre performance indicators (answer times, abandonment,
  resolution) follow the organization's own targets. ISO 18295-1
  covers performance indicators for contact centres; set and monitor
  values that fit your customers and contracts.

## 4. Escalation paths

<!-- Guidance: Separate functional escalation (to more expertise) from hierarchical escalation (to more authority). Name roles, not people, and give the trigger for each step. -->

### 4.1 Functional escalation

| Trigger | From | To | Within |
|---|---|---|---|
| No known fix, or P1 or P2 | Tier 1 | Tier 2 | 15 min for P1, 60 min for P2 |
| Defect or outage suspected | Tier 2 | Tier 3 on-call | 15 min for P1 |
| Data loss or security concern | Any tier | Security incident process | Immediately |

### 4.2 Hierarchical escalation

| Trigger | Escalate to | Within |
|---|---|---|
| P1 open | Support duty manager | At once |
| P1 open over [2] h, or more than [5] customers affected | Head of support, incident commander | 2 h |
| Target missed for P2 | Support team lead | When missed |
| Customer asks to escalate | Support team lead, then head of support | 1 business day |
| Strategic account at renewal risk | CSM and account executive | 1 business day |

```mermaid
flowchart TD
  A["Case raised by customer"] --> B["Tier 1 triage and severity"]
  B -->|"Known fix"| C["Resolve and confirm with customer"]
  B -->|"P1 or P2 or no known fix"| D["Tier 2 diagnosis"]
  D -->|"Defect or outage"| E["Tier 3 engineering"]
  E --> C
  D --> C
  B -->|"P1"| F["Duty manager informed"]
  C --> G{"Customer satisfied?"}
  G -->|"Yes"| H["Close case"]
  G -->|"No, dissatisfied with handling"| I["Complaints process"]
```

### 4.3 Customer-initiated escalation

Customers may escalate any case by [replying "escalate", using the
escalation form or calling the number in section 6]. The escalation is
acknowledged within [1] business day, a team lead takes ownership and
the customer is told the name of the new owner.

## 5. Link to the complaints process

<!-- Guidance: ISO 10002 treats a complaint as an expression of dissatisfaction where a response or resolution is expected. A technical escalation becomes a complaint when the customer is unhappy with the product, the service or the handling itself. -->

| Situation | Route |
|---|---|
| Customer wants a faster or better fix | Escalation under this policy |
| Customer expresses dissatisfaction with the organization, product or handling and expects a response | Log a complaint in the complaints register (`compliance/iso-10002-complaints`) and keep the support case linked |
| Customer asks for compensation or service credit | Complaint, plus the contract's service credit clause |
| Customer still dissatisfied after the final complaint response | Tell them the external dispute resolution route that applies to your sector, if any |

## 6. Customer-facing summary

<!-- Guidance: Plain language, no internal names. Publish on the help centre and link it from the contract or order form. -->

**How to get help:** [help centre link], [email], [phone and hours].

**How fast we respond:** urgent outages within [30 minutes, 24 hours a
day]; other issues within [1 to 2] business days. Your contract may
give you shorter times.

**How to escalate:** if you are not happy with progress, reply
"escalate" to your case or call [number]. A team lead will contact you
within one business day.

**How to complain:** if you are dissatisfied with our service, see
[complaints page]. We will acknowledge your complaint within [2]
working days.

## 7. Monitoring and review

<!-- Guidance: ISO 10002 clause 8 covers analysis, monitoring and improvement of the process. Track a few measures monthly and review causes quarterly. -->

| Measure | Target *(Example)* | Reported to |
|---|---|---|
| First response within target, by severity | 95% | Head of support, monthly |
| Escalations per 100 cases | Trend down | Support leadership, monthly |
| Customer-initiated escalations | Trend down | Support leadership, monthly |
| Escalations that became complaints | Reviewed case by case | Complaints owner, quarterly |
| Satisfaction with escalated cases | [Target] | Customer satisfaction programme (`customer-success/customer-satisfaction-programme`) |

## Standard and licence note

Structure aligned with ISO 10002:2018, Quality management, Customer
satisfaction, Guidelines for complaints handling in organizations
(guiding principles in clause 4, framework in clause 5, operation of
the process in clause 7, maintenance and improvement in clause 8), and
informed by ISO 18295-1:2017, Customer contact centres, Part 1,
Requirements for customer contact centres. All explanations, tables
and targets are original wording and reproduce no text from the
standards; the targets are examples, not values set by either
standard. Both editions were current when checked in October 2026; ISO has
registered a revision of ISO 18295-1 as a new work item (ISO/AWI
18295-1), so check for newer editions and for sector rules before use. This is a
documentation format, not legal advice.

Official text: ISO, purchase or licensed access:
https://www.iso.org/standard/71580.html (ISO 10002) and
https://www.iso.org/standard/64739.html (ISO 18295-1), also available
from national standards bodies.

Template licence: MIT.