Think of the matrix as a lookup table for a shared-channel thread. The agent checks it, finds the level, and learns who takes the thread next, how quickly that person must respond, and what the handoff has to include. Matrices usually break in one of two places. Some use adjectives such as “major” that nobody can count. Others hand over a one-line Slack message that makes the engineer ask the customer everything again. The sections below fix both.
Three levels and the triggers that move a thread
Triggers must be countable. Count distinct accounts, not messages: one customer posting 40 times in a thread is one account. The numbers below are starting values. Tune them after a month of real tickets.
| Level | Owner | Triggers (any one is enough) | Acknowledged within | Customer update |
|---|---|---|---|---|
| L1 | Support agent on the shared channel | Default. Anything not listed below. | Your normal first-response target | As your SLA says |
| L2 | Support lead, with the product owner or engineering on-call for that area | Support reproduces a product defect, not a setup or permissions problem. Or 3 or more distinct accounts report the same problem within 24 hours. Or one account is blocked with no workaround for more than 2 hours. | 4 business hours | Every 1 business day |
| L3 | Engineering manager on call, plus the support lead | Production outage or data problem affecting 10 or more distinct accounts. Or a production outage longer than 30 minutes for a VIP account. Or any suspected security issue or data exposure, whatever the count. | 30 minutes, around the clock if you run on-call | Every 60 minutes until mitigated, then daily |
The VIP list is a named list the support lead keeps, usually the largest contracts plus any account with a contractual uptime commitment. Cap it at about twenty accounts, because a longer list stops singling anyone out.
Decision rule: find every trigger that fires, and route the thread to the highest level among them.
Worked example. Acme, a VIP account, tells you at 14:05 on Tuesday that checkout fails for their own customers. Support reproduces the error in a sandbox at 14:16. That is a product defect, so the thread moves to L2 at 14:16. At 14:36 the outage has lasted longer than 30 minutes for a VIP account, which is the L3 trigger. The thread moves to L3 at 14:36 without waiting for a second account to report it. The L3 acknowledgement is due by 15:06.
If you run help-desk SLA timers, alert on time left, not on breach. Zendesk’s SLA help article says that a breach or a fulfilment produces no event of its own. A breached timer alerts nobody unless you build a rule for it, and a warning at 30 minutes remaining gives the lead time to act.
What every handoff must contain
Require these fields, in this order. A handoff missing one goes back to the sender before anyone starts work on it.
- Account, level and trigger. “L2, trigger: reproduced defect in checkout.” The receiver checks the trigger first.
- The customer’s words. Verbatim, with the timestamp and the speaker’s name. Your paraphrase is not allowed. “They say it’s slow” makes an engineer ask again. The exact words usually contain the error text.
- Reproduction steps. Start from the account’s state and client version, and end with “Expected: … Actual: …”. If you could not reproduce it, write “Not reproduced” and list the steps you tried.
- What has been tried. Each action with its result, including what you ruled out. “Checked the API key, valid” is useful. “Checked login” is not.
- The promise the customer has seen. The exact sentence they read, and the due time with its time zone.
- Links. The shared-channel thread, the account record and the internal ticket if you have one. Slack’s API reference describes a message’s
tsas “the unique (per-channel) timestamp”, so the channel ID plus that timestamp identifies the thread precisely. - Next update due, and who sends it.
Failure mode: the handoff says “customer is upset” and contains no quote. The engineer spends forty minutes rebuilding context the customer already typed. The fix is field 2 as a hard requirement, enforced by the receiver, who returns any handoff without it.
Write to the customer without internal words
Keep the following out of anything a customer reads: “L2”, “P1”, “on-call”, “incident”, “backlog”, and your bug tracker’s ticket IDs. Swap in plain language before you press send:
- Instead of “I’ve escalated this to L2”: “I’ve passed this to our engineering team with the steps you sent.”
- Instead of “This is a P1 incident”: “We’re treating this as urgent.”
- Instead of “ENG-4412 is in review”: “The fix is being reviewed now.”
- Instead of “waiting on on-call”: “I’ve passed this to our engineering team and you’ll hear from me by [time] with an update.” Say “looking at it now” only when an engineer is actually working on it.
When you hand off, send this, adjusting the time and zone:
“I’ve passed this to our engineering team with the steps you sent. You’ll hear from me by 16:00 UTC+8 on Wednesday with an update on where this stands, and a workaround if we have one. If you haven’t heard by then, reply here and I’ll chase it.”
Promise the next update time only. A fix time you do not control is a promise you will break.
Keep the customer thread readable and the argument internal
A Slack Connect channel is shared. Slack’s developer documentation says every connected workspace can read and send messages, share files and access the channel’s history. Whatever you post in the customer’s thread, their people can read, and it stays in the history.
Working rules that follow from that:
- The customer thread carries customer-facing messages only.
- The handoff card, root-cause discussion and engineer mentions go to an internal channel in your own workspace, one you never connect to the customer. Link the shared thread from the card.
- Do not paste internal ticket links, dashboard screenshots or internal channel names into the shared channel. The customer cannot open them, and they reveal your tooling.
- Before you start a shared collaboration, confirm the customer’s organization is on a paid plan. Slack’s Slack Connect guide states, as of 2026, that working in channels together requires a paid Slack plan on each side.
Failure mode: an engineer replies in the shared thread with “this is the flaky cache again”, and the customer reads it. The fix is a correction in the same thread within one hour, plus a rule that engineers never reply in customer threads. The correction should say what was wrong and when the next update is due, not repeat the speculation.
Plan for Do Not Disturb
A Slack message alone is a weak L3 page. Slack’s help article on default Do Not Disturb hours says that during those hours Slack stops desktop and mobile notifications for members, who can still change their own schedule. An L3 page posted at 17:30 to someone whose schedule starts at 17:01 can sit until morning.
Rule: page L3 through something that does not depend on Slack notifications, such as your paging tool or a phone call. Test it once a month at an hour when the person is off, and confirm it wakes them. Treat an emoji reaction in the internal channel as no acknowledgement. Require a written reply.
Step back down to the normal queue
Return a thread to L1 in three stages.
- Fix confirmed by the customer. The trigger is the customer’s reply in the thread, such as “Checkout works now.” “Fix deployed” in the internal channel does not count until they confirm.
- Send the closure message. For example: “Your checkout issue was fixed at 11:20 on Thursday. I’m keeping this thread open for two business days in case it returns. Reply here if anything looks off.”
- Watch, then return. The escalation owner stays tagged in the internal channel for two business days. Then the thread goes back to L1 with an internal note such as “Escalation closed Friday, watch ends Tuesday.” A regression inside the watch window reopens the escalation at its original level.
Move down one level at a time. L3 drops to L2 once service is back and the customer has confirmed. L2 drops to L1 under the rule above. Skipping from L3 straight to L1 on the day of an outage hands an angry customer to a first responder who has no context.
Measure one thing each month: the share of escalations reopened within two business days of returning to L1. If that share is above 1 in 10, your confirmation step is too loose, and you should wait for the customer’s explicit confirmation before stepping down.