> ## Content Index
> Fetch the complete content index at: https://blog.jestor.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# How to structure support tiers and escalation
- URL: https://blog.jestor.com/structure-support-tiers-and-escalation/
- Published: 2026-09-16T18:54:25.000Z
- Updated: 2026-09-16T18:54:25.000Z
- Author: Bruno Bannach

Designing **support tiers and escalation** well means defining escalation by what the case requires, not by how the customer sounds. In **Jestor**, each tier is a stage with its own owner and deadline, and the escalation reason is recorded, which is what lets level one improve.

## Why tiering fails without clear criteria

Most support teams have levels. Few have written criteria, so escalation happens when an agent feels stuck or a customer becomes insistent.

Level two then absorbs cases level one could have handled, and the queue everyone actually needs gets slower.

What explicit criteria fix:

- Escalation triggered by frustration rather than complexity
- Level two doing work level one could do
- No feedback loop to improve first line capability
- Customers repeating their situation at every level
- No data about what genuinely requires specialists

## Defining each tier

| Tier               | Handles                              | Escalates when                    |
| ------------------ | ------------------------------------ | --------------------------------- |
| Level one          | Known issues with documented answers | No documented answer exists       |
| Level two          | Diagnosis requiring system access    | A change to the product is needed |
| Level three        | Defects and engineering work         | Rarely, upward                    |
| Account escalation | Relationship, not technical          | Commercial risk                   |

## Step by step to implement it

1. **Write the criteria per tier**, in terms of what the case needs.
2. **Separate technical escalation from account escalation**, since they are different problems.
3. **Require an escalation reason**, chosen from a short list.
4. **Carry the full context up**, so the customer never repeats themselves.
5. **Set a deadline per tier**, since escalation should not mean indefinite.
6. **Review escalation reasons monthly**, and document the recurring ones.
7. **Feed those answers back to level one**, which is the whole point of recording them.

## Why the escalation reason is the most valuable field

Each escalation marks a gap in first line capability or documentation. Recorded and grouped, those reasons become a prioritized list of what to document next, which steadily raises what level one can resolve. Without it, tiering just moves work around.

## Why choose Jestor

In **Jestor**, tiers are stages with owners and **SLA**, escalation reasons live in a controlled registry so grouping is reliable, the full history stays on the record as it moves, and documentation created from recurring reasons can serve both agents and an **AI** agent answering first line questions.

## Frequently Asked Questions

### What should trigger an escalation?

What the case requires, defined in writing, rather than how the customer sounds. See [jestor.com](https://www.jestor.com/?ref=blog.jestor.com).

### Why record the escalation reason?

Because grouped reasons show exactly what level one needs documented next.

### Should account escalation be separate?

Yes. Commercial risk is a different problem from technical complexity.

## Video Tutorial: Step by Step

With **Jestor**, you can automate workflows, connect teams, and build internal systems your way, all without code and powered by **AI**. Discover Jestor at [jestor.com](https://www.jestor.com/?ref=blog.jestor.com) and see how to take your company's operations to a new level of efficiency and control.