Cookbook
Keep an escalation where the account team will see it
Support knows the account is angry. The person walking into the renewal does not. Closing that gap is not a process problem, it is one decision about where the thing lives.
The situation
An escalation exists somewhere: a ticket system, a channel, somebody's head. It is well tracked by the people handling it. The failure is never that support loses it. The failure is that six weeks later somebody opens a renewal conversation with a customer who has spent a fortnight furious, and finds out during the call.
What must be true when you are done
- An escalation is recorded against the account, with severity and what happened.
- You can list the open ones for one account, or all of them.
- It appears in the brief anybody reads before contacting the customer, which is the part that actually prevents the bad call.
- Resolving it removes it from both, because there is only one of it.
Hold the escalation properly
Describe it the same way you would any other thing your business runs on: a severity from a fixed list, what happened, when it opened, whether it is resolved, and the account it belongs to. Ask for severity, resolved and the account to be filterable, for the same reason as anything else you intend to count.
You
Agent
Now it is a record. Ask for the open ones on an account and you get them:
You
Agent
Where it has to show up
Recording it is the easy half. The half that decides whether any of this works is whether it reaches the person about to phone the customer, and nobody is going to remember to ask a second question about escalations before every call.
It does. The account brief, the thing an agent reads before it touches an account, carries your own types alongside the contacts, deals, tasks and recent conversations. You do not have to ask for them and you do not have to keep a copy anywhere else.
You
Agent
This is worth a note on why it reads that way. For a while it did not: the brief returned the built-in collections and nothing a customer had modelled themselves, so an escalation held as your own type was on the record and invisible at exactly the moment it mattered. The advice then was to also raise a task, so the fact appeared somewhere the brief looked.
That was a workaround, and a recipe containing one is a bug report with instructions attached. The brief carries your own types now, so there is nothing to duplicate and nothing to keep in step.
Resolve it once
Mark it resolved and it leaves the brief, because the brief reads the record rather than a copy of it. There is no second thing to remember and no way for the two to disagree, which is the practical difference between this and holding the same fact in two places.
Verify it
- Run the brief, not the escalation list. That is the test. If the escalation only appears when you go looking for it, this recipe has not done anything a ticket system was not already doing.
- Resolve one and run the brief again. It should be gone. If it is still there, the resolved flag is not the one the brief reads, and everybody will start ignoring the section within a fortnight.
- Ask for every open escalation across the book. If the list is longer than you expected, that is the finding, and it is the one worth taking to whoever owns renewals.
Run it again
Whenever one opens, and as a sweep before any renewal conversation. The renewal itself is its own motion, and an open escalation on an account inside its renewal window is the single most useful thing that pass can surface.