Every small team eventually meets the vendor whose support ticket is a black hole: critical system degraded, four exchanges of "our engineers are investigating," and the invoice was paid on time. The failure is not the vendor being bad — it is escalating like a person instead of like a contract. The fix is a ladder: rungs you climb in order, each with a defined ask, a defined owner, and a defined wait — written down before you need it, when nobody is angry.
The ladder, one sentence per rung
- Rung 1 — the ticket, written to be escalated. Not a complaint: a case file. Precise subject, impact in the vendor's own product terms, timestamps, ticket IDs, what you already tried.
- Rung 2 — the named human. "Please assign a named engineer or manager and confirm their name." Queues move tickets; people move problems. No name in one business cycle? Climb.
- Rung 3 — the commercial lever. Email the account contact: ticket open N days past the tier you pay for; need a resolution owner by Friday. Renewal conversations get answered faster than bug reports.
- Rung 4 — the executive office. One paragraph, factual, with the ask and the deadline. It sounds dramatic and usually works.
- Rung 5 — the exit trigger. A written line, set on a calm day: no named owner and a dated remediation plan by [date] → we begin offboarding. This rung is what makes the other four work.
Rung zero: read what you already bought
Before any incident, once, calmly: your support tier's response times by severity, the escalation path, business hours — and the escalation clause in the contract (contracts above a few thousand dollars a year almost always have one: named account manager within 24 hours, or the office of the CTO). It is leverage you paid for and never used. "P1 per our support agreement" moves; "urgent!!!" does not.
One mismatch the ladder cannot fix: a support desk that answers in business hours while you promise customers 24/7. The ladder fixes slow; it cannot fix closed on weekends. If the gap is real, the answer is a DR plan that names which vendors you ride without for a day — not an angrier ticket.
A ticket written to be escalated
The subject is the only line a routing human reads. Make it carry severity, symptom, and money: "Checkout API 5xx — 40% of orders failing since 09:40 UTC — opened per P1 terms." Impact in their units ("order volume down 40%"), your ruled-out-ours attached up front, one ticket per distinct failure — and a local log of ticket IDs, dates, and promises. The incident timeline you keep for your own incidents doubles as your evidence folder.
The named human, then the clock
Ask for a name, then use it — and summarize state in every reply, because reply fifteen is read by someone new. Set the clock politely, once, on the record: "no substantive update by Thursday 17:00 UTC and I escalate to your management." That is not a threat; it is a schedule. Vendors respect customers with calendars. And time-zone the rungs: if the vendor is 12 hours ahead, land each escalation at their start of day.
The commercial lever and the executive letter
The account-manager email is five lines: what you pay, what broke, how long the ticket has been open versus your tier, the ask (named owner, dated plan, by when), and the fact of renewal — "we are 90 days from renewal with this unresolved" is a fact, and facts move managers.
The executive letter is one paragraph, three sentences, no adjectives: what you run, what you pay, ticket # open N days against a tier of X hours, last substantive update [date], named resolution owner and dated remediation plan by [date], escalation clause quoted below. Executive escalation buys attention and a named owner within a day. It does not buy engineering hours that do not exist. It moves you to the front of the queue — which is exactly what the ladder promises.
While the ladder climbs: parallel work, not parallel yelling
Work around, don't wait around — implement the workaround, tell the vendor you did ("we degraded to manual processing; every hour costs N staff hours" sharpens the severity claim), and stabilize first, escalate in parallel. Alternative channels — status page (screenshot either way: your status-page discipline works in reverse as evidence), community forum, GitHub tracker, reseller — get the same case-file summary, never a new angrier version. Every climb gets one dated log line: ticket IDs, promised vs delivered, outage minutes against the contractual SLA. A vendor that made you climb to Rung 4 twice in a year is a vendor carrying a named open item at your quarterly review.
The exit trigger
One bad week is weather; a pattern is a contract problem. Judge the ladder's outcome: did Rungs 2–3 consistently produce a named human within a day? Vendor is slow but real — patience plus plan B. Are Rungs 3–4 now routine for the same failure class? The ladder has told you what it exists to tell you: the relationship is the outage. When the written trigger fires, follow the offboarding playbook: data export, deletion confirmation, credential rotation, cutover window. An exit you designed on a calm day beats an exit you rage-quit on a bad one.
Counterintuitive closer: tell the vendor the ladder exists. In a good month, in writing — "here is how we escalate, and here is the line that starts offboarding." The best vendor relationships are the ones where nobody ever climbs past Rung 2, because everyone knows the stairs are there.
Small-team honesty note: at five people this ladder *is the procurement department — five rungs, one template email, one log line per climb. The cheapest rung is Rung 2: most "vendor ignores us" stories end the day someone politely asks for a name.*
Related reading: the vendor outage runbook · the vendor security review checklist · the vendor offboarding & data deletion checklist · the incident timeline template
If you want the full playbook set: the Ops Starter Kit ($14) bundles the checklists behind these playbooks, and The First 30 Minutes is free.
Top comments (0)