Escalating to Vendors and Other Teams You Do Not Manage

Tuesday, 09:30. Marta is on hold with the accounting system's support line for the third time this week. The recorded voice has just asked her, for the third time, to have her case number ready. She does not have it. The case was opened last Wednesday by Sean, who is on leave until Monday. He opened it from his own mailbox. The confirmation e-mail with the number in it is in his inbox, which nobody else can read. The supplier's portal, when she finally gets in, shows the case as "Awaiting customer" for six days. That is because the supplier asked a question on Thursday that nobody saw. The desk's own ticket for the fault breached its resolution target on Friday. The finance manager has asked for an update at 10:00. Marta has twenty-eight minutes, no case number, and a ticket whose last entry reads "with the vendor".

An external escalation is the point at which the fix for a ticket depends on someone outside your desk's control. That could be a software vendor's support line, a hardware supplier's warranty desk, a telecoms provider, or a landlord's electrician. It could be the network team at head office or a development team in another building. You keep the requester, the ticket and the clock. You lose control of the pace. This article is part of our Escalation Done Right series. It is about the escalation where the person you hand the work to does not work for you. They will not read your ticket, and they have a queue of their own that you cannot see.

It starts with what changes when the fix leaves the building. Then it explains why the vendor's case number lives in your ticket and nowhere else. It also shows how to open a case so the vendor can act on it. From there, it covers the follow-up cadence, matched to priority, that keeps a case from going quiet. It turns to honest status updates to the requester when the fix is out of your hands. Then it explains the SLA clock that keeps running whatever the vendor does. The article also covers other internal teams, which are vendors in all but name. It explains how to escalate inside the vendor when their first line is not moving. A short war story leads into the vendor escalation log, which is the template.

When the Fix Leaves the Building

Three things change the moment a ticket's next step belongs to an outside party. The desk should name all three in the ticket at that moment. You lose control of the pace. The vendor works to their own queue, their own hours and their own idea of what "high" means. No amount of urgency on your side alters that except through the channels they provide. You keep the requester, who does not know the vendor exists and should not have to. And you keep the clock, because your SLA was a promise from the desk to the requester and the vendor was never party to it.

What does not change is who owns the ticket. The ticket stays assigned to a named person on your desk. They are the requester-facing owner in the sense described in Who Owns the Ticket After Escalation. For an external escalation, they are also the working owner on your side. They are the one who chases, reads the vendor's replies, answers their questions and tests their fix. A ticket "with the vendor" that is assigned to nobody is a ticket with no one to chase or answer the vendor's question. There is no one to receive the warning when it breaches. It will be found when the requester complains, which is the most expensive way to find anything.

The vendor is a specialist you do not manage. Most of what applies to an internal specialist applies here. The difference is that nothing you write in your ticket reaches them. Your handoff note, the one described in The Handoff That Does Not Dump, has to be written twice. One copy is an internal note for your own desk. The other is in the vendor's form, in the vendor's words, with the vendor's severity scale. The second copy is the one that decides how fast the vendor moves. It is the one desks most often rush, because the form is tedious and the hold music is long.

A desk that escalates to vendors often should know, before the first case, what each vendor's path looks like. The desk should know which address or portal opens a case, what the severity levels are called and what each one promises. It should know what the contract says about response times, if anything, and who the account manager is. It should know what information the vendor always asks for, such as serial numbers, version strings or log files. All of that belongs in the "where the path ends" column of the escalation path table from Escalation Paths and Criteria, one row per vendor. The hour it takes to fill in saves half a day on the first bad Tuesday.

The Case Number Lives in Your Ticket

The vendor's case number goes in the first internal note after the case is opened, on its own line. Include the vendor's name, the date, the channel it was opened by, and the severity it was opened at. "Vendor case: accounting system support, case 4471-A, opened Wed 14:20 by Sean via portal, severity 2 (their scale), contact: support portal plus their case e-mail address." That note is the address of the external work. It belongs in the one place every person on the desk can read, which is the ticket. Not in Sean's mailbox. Not in a chat thread. Not on the whiteboard. Not in Sean's head, however good Sean's head is.

The reason is the one the opening scene shows. The person who opened the case is not always the person who has to chase it. The reason could be leave, sickness, a shift change, a resignation, or simply a Tuesday when Sean is on another incident. In any of those cases, the case number has to be found by somebody else in under a minute. If it is in the ticket, they have it. If it is anywhere else, they are on hold being asked to have it ready. Most tools have a full-text search across tickets, so a case number in a note can also be found from the other direction. That helps when the vendor e-mails about "case 4471-A" and nobody remembers which ticket that was.

Where your tool lets you, make the case number visible without opening the ticket. Some tools have a field for an external reference. Some let you edit the ticket's subject so the number sits in it. Some have tags. If yours has none of those, the first-note convention is enough. That is provided everyone on the desk knows that the vendor note is always the one that starts with "Vendor case:". The convention matters more than the field. A field nobody fills in is a blank with a label, and a note everyone writes the same way is a field.

The same rule covers the vendor's own channel. Every e-mail from the vendor about the case is pasted or forwarded into the ticket. One option is an internal note. Another is sending it into the ticket's address if your tool threads e-mail on the ticket number. Every call is summarised in a note within ten minutes of hanging up, with the time, the person's name and what they said. The vendor's view of the case and your ticket's view of it should match at any moment. The day they do not match is the day the vendor says "we asked you for the log on Thursday" and your ticket has no Thursday in it.

Opening the Case Properly

A vendor case opened well is answered in one round. A case opened badly is answered with the question you could have pre-empted. Every question costs a day, because the vendor's reply goes into a queue and your answer goes into another one. The vendor needs the same five things an internal specialist needs: a summary, what was tried, the ask, the deadline and the user's situation. They also need the things only an outside party needs. Those are your account or contract identifier, the serial number or version of the thing that is broken, and the exact wording of any error. Collect all of it before you open the form, because most vendor forms do not let you go back.

Set the severity in the vendor's terms, honestly, and write down what that severity promises. Every vendor has a scale. The names differ, and the top level is almost always reserved for "production down for everyone", with a real response commitment attached. Opening a one-user fault at the top level gets it downgraded by the vendor's first-line engineer, with a note that the desk will not enjoy reading. Opening it at that level also burns a little credibility for the day you need the top level honestly. Opening a whole-site outage at the bottom level because the form defaulted there puts it in a queue that is answered in days. Read their scale once, match your priority to it in your path table, and choose by the table rather than by mood.

Say what you want. "Please tell us whether this error is a known issue in our version and, if so, the fix or workaround" is an ask the vendor's first line can answer from their knowledge base in an hour. "The system is broken, please help" is an ask that produces the standard reply asking you to describe the problem, restart the service, and send the logs. The desk already restarted the service and already has the logs, and should say so and attach them. Otherwise, the vendor will ask, and the vendor's ask costs a day.

The checklist below is the pre-flight for opening any vendor case. It takes ten minutes, most of which is gathering. It turns a case that would have gone three rounds into one that goes one.

• Account, contract or customer number for the vendor, and the product and version or model and serial number.
• A two-sentence summary: what is broken, for whom, since when, how it shows.
• The exact text of any error message, pasted, not retyped.
• What was tried, with results, including the restart they will ask about.
• The log or screenshot they always want, attached at opening.
• The severity in their scale, chosen from your path table, with what it promises noted.
• The specific ask: known issue, fix, workaround, replacement part, engineer visit.
• Your deadline in plain words, and the business reason, in one sentence.
• The named contact on your desk, with a phone number and hours, and a second name.
• The case number, written into your ticket's first vendor note before you do anything else.

The Follow-Up Cadence

A vendor case that nobody chases goes quiet. Quiet cases are closed by vendors for "no response from customer" with a regularity that suggests the closing is automated. The follow-up cadence is the fixed rhythm at which the desk's owner checks the case, answers anything the vendor has asked, and prompts the vendor if they have gone silent. The rhythm is set by the ticket's priority on your side, not by the vendor's severity, because it is your requester waiting. The table below is a sensible default for a small desk. Tighten it if your contract gives you faster commitments to hold the vendor to.

Every check, whether or not anything has changed, produces a one-line note in your ticket. It includes the time, the channel, what the vendor said or did not say, and when the next check is due. A ticket with a chase note each day is a ticket whose history proves the desk did its part. That matters on the day the requester, the manager or the vendor asks what happened. A ticket whose last note is "with the vendor" from eleven days ago proves the opposite, whatever the owner actually did.

The "awaiting customer" trap deserves its own warning, because it is where most vendor cases die. When the vendor asks you a question, their clock stops and yours does not. The case then sits in a status that says the delay is yours. Answer vendor questions the same day, even if the answer is "we will have the log by tomorrow 10:00". An answered question moves the case back into their queue. Check the case's status at every scheduled check, not just your inbox. That is because the question may have gone to the person who opened the case, who may be on leave. That is the opening scene again.

Cadence is a discipline the whole desk shares, not a personal habit. The simplest way to keep it is a standing view in your tool of tickets that are waiting on an outside party. That view is sorted by last update and read at a fixed time each morning. Most tools can produce that view with a status filter and a sort, or with a saved search. If yours cannot, a tag or a subject prefix such as "[VENDOR]" and a daily search for it does the same job. The point is that "waiting on vendor" tickets are looked at every day by someone whose job that morning is to look at them. They are not just remembered by whoever happens to think of them.

Honest Status to the Requester

The requester does not know the vendor exists and should not need to. But they do need to know that the fix is now on a timetable the desk does not control. That changes what they should expect and what they should plan around. The honest update has three parts, like every good update: where the ticket is, what the desk is doing about it, and when the requester will hear next. "This fault is in the supplier's software and we have a case open with them, reference 4471-A, at their second-highest severity. I am checking it every morning and chasing them when it stalls. I will update you every day by 16:00 until it is fixed, and sooner if they give us a date."

"It's with the vendor" is not an update. It is the absence of one dressed as a fact, and requesters hear it exactly that way. They hear the desk saying the delay is somebody else's fault and the requester should take it up with the weather. Give them the case reference, so they can see that something concrete exists. Give them your cadence, so they know the desk is doing work rather than waiting. Give them a time for the next word. The requester cannot hurry the vendor and neither can you. But a requester who knows the desk is chasing daily behaves very differently from one who suspects the desk has forgotten.

Never promise the vendor's time as your own. If the vendor says "we expect a fix in the next release", you say "the supplier says a fix is expected in their next release; they have not given a date, and I have asked for one", not "it will be fixed in the next release". If the vendor gives a date, you pass it on as the vendor's date with the vendor's name on it. The desk's own promise is only ever about the desk's own actions: when it will chase, when it will update, when it will test. The distinction between promising what you control and naming what you depend on is the subject of What to Promise and What Never to Promise. That article was written for exactly this conversation.

When there is a workaround, lead with it. Most vendor faults have one, even if it is "use the other printer" or "export to a spreadsheet and sort it there". A requester with a workaround and a daily update is a requester who can work. A requester with no workaround and a promise that "the vendor is looking into it" is a requester who will go to your manager by Thursday. They will be right to. The workaround is the desk's own work and the desk can promise it. That makes it the one honest thing the desk can offer on day one.

The SLA That Keeps Running

Your SLA clock does not know about the vendor. The resolution target on the ticket started when the requester raised it and it will expire when it expires. That is true whether the fix is in your hands or in a queue three time zones away. The desk's owner will get the breach warning. This is correct behaviour, not a fault in the tool. The SLA was a promise to the requester about when they would be working again. From where the requester sits, the vendor is part of the desk. Whether the tool pauses the clock in a waiting status is a separate question, and the answer varies. Some tools pause on hold, some do not, some pause on one waiting status and not another. Test yours: put a test ticket into your waiting status over a weekend and read the due time on Monday. Then write into your SLA document only the exclusions the tool actually applies.

Expect the breach and handle it rather than hide it. If the target is four business hours and the vendor's committed response is two business days, the ticket will breach. In that case, the right response is to tell the requester before the due time, in the three-part form. In that situation, let the breach stand in the record with a note that names the vendor dependency. A breach with a cause attached is information. A breach dodged by a status trick is a lie the desk tells itself, and the monthly breach review cannot learn from it. How breaches are read and what a vendor-dependency breach teaches is in the SLA series. The escalation rule is simply that the ticket's owner writes the cause into the ticket at the time, so the review has it.

The honest long-term fix is to split the promise, which the SLA series covers. There is a target on the desk's own step, such as "case opened with the vendor within one business hour and chased daily". The vendor's part is named in words rather than measured against your clock. Until the SLA is rewritten that way, the ticket keeps its target and breaches it. Meanwhile, the desk keeps a note of how many breaches last month were vendor-bound. Three months of that number is the evidence for the rewrite. It is also, quietly, the evidence for a conversation with the vendor about their response times, which goes better with numbers than without.

The status you choose while waiting matters less than the definition behind it. Many tools ship a fixed set of statuses and do not let you add a "Pending Vendor" one. In that case the waiting status you have, usually something like On Hold, does the job. The vendor note makes the reason plain. The team's written definition of that status says "a ticket in this status with a vendor note is waiting on an outside party and is checked daily". The meaning lives in the definition, not in the label. The choice between waiting statuses, and what each should mean, is the subject of Pending User vs Pending Vendor vs On Hold.

Internal Departments Are Vendors Too

Consider the development team on the second floor, facilities, the network team at head office, the parent company's own service desk, and a managed service provider on contract. Each of these is a vendor for the purposes of this article. That is because the desk does not manage them, cannot see their queue, and depends on them for the fix. The rules are identical. Their ticket number goes in your ticket. Your ticket stays assigned to a person on your desk. You chase on a cadence set by your priority. You tell the requester honestly that the fix is with another team, and when you will hear. Internal teams are often slower to chase than external ones, because it feels rude, and the rudeness is imaginary. Their queue is as full as yours, and a daily, polite "any movement on your 2291?" is how tickets in full queues get moved.

The one real difference is that an internal team may be in the same tool, and then the transfer is a transfer, not a case. If the other team has its own department or queue in your ticketing tool, the ticket can move to them with its history intact. In that case, the desk's question becomes the one in Who Owns the Ticket After Escalation: who talks to the requester while they work. Most desks keep that role, because the requester knows the desk, and the other team's technician writes progress in notes the desk translates. The mechanics of moving a ticket between departments, and what travels with it, belong to Transferring a Ticket Between People or Departments. Here the rule is only that the move does not end the desk's ownership of the requester.

An internal team that is not in your tool is a vendor without a contract, which is the hardest kind. There is no severity scale, no account manager and no clause to point at, only goodwill and a relationship. So build the relationship before you need it. Know the name of the person who triages their queue. Agree, informally and in writing, what "urgent" means between you and how they would like to be chased. Send them your handoff note in their preferred form, whether that is an e-mail, a form or a message. Ask for their reference number back. Treat their reference exactly as you would a vendor's: first note, own line, searchable.

Managed service providers sit in between, with a contract and a portal but often with a shared responsibility for the same requester. The ownership question has to be settled in the contract rather than per ticket. Whichever side owns the requester-facing role for a given kind of ticket, the other side's reference lives in the first side's ticket. Both sides chase to a cadence. A provider relationship where each side believes the other is talking to the requester produces the Ashgrove Housing story from the previous article, with two organisations' letterheads on it.

Escalating Inside the Vendor

Vendors have escalation paths too, and the desk should know them before it needs them. Most support organisations have a first line that works tickets in order and a second line of engineers that the first line hands to. Those organisations have a duty manager or escalation manager who can reprioritise a case. They also have an account manager whose job is the relationship rather than the fault. Asking the first line to "escalate this" is a legitimate request. It is the hierarchical kind, and a vendor that respects its customers will do it when asked with a reason. The reason is the impact in your terms and the time the case has been open against their own commitment.

Escalate inside the vendor when two chases on the cadence have produced no movement, or when the vendor has missed a time they gave you. Also escalate when the impact on your side has grown past the severity the case was opened at. Do it in writing, on the case, so it is on their record and yours. Say what you are asking for: a named engineer, a call-back time, a severity change, or a management review. Then, if the case has been open past the contract's response commitment, say so, quoting the clause. Vendors move for clauses in a way they do not move for frustration, and a desk that knows its contract is a desk that gets called back.

The account manager is the lever of last resort. It is best pulled by the lead rather than the technician, which makes it a hierarchical escalation on your side first. The lead phones the account manager, with the case number, the opening date, the chases, the missed commitment and the business impact. All of those are in the ticket because the owner wrote them there each day. That call is short when the ticket is good and impossible when it is not. The vendor escalation log, below, is built so that the call is short.

Keep the tone even throughout, because the first-line engineer at the vendor is a person in a queue, like you. They are not the reason the case is slow. The target of a vendor escalation is the vendor's process, not the person who answered the phone. A desk that is remembered by a vendor's support team as polite and precise gets its cases read more carefully than one remembered for shouting. I have been on the vendor's side of that phone, and I can tell you which cases got worked first. It was not the loudest.

A Short War Story: Six Days of Awaiting Customer at Redbrook Engineering

Redbrook Engineering's drawing office ran a licence server for its design software. When it stopped issuing licences one Wednesday, Dana on the desk opened a case with the software vendor from her own mailbox. She got case number 88-6143 back by e-mail, and wrote "case open with vendor" in the ticket without the number. The vendor replied on Thursday asking for the server's licence log and a version string, to Dana's mailbox. Dana went off sick on Thursday afternoon for a week. The ticket sat in the queue in a waiting status with no chase. The vendor's portal showed the case as "Awaiting customer" from Thursday. The vendor's system closed it automatically after five working days with no response. The drawing office worked on the one machine that held a cached licence for seven working days, with eleven engineers taking turns. That lasted until the lead, Priyanka, phoned the vendor on the second Tuesday. Priyanka spent twenty minutes establishing which case had been Dana's, reopened it, and sent the log that had been sitting on the server the whole time. Priyanka had licences back within the hour. The cost was a week of a drawing office at a fraction of its capacity and a project milestone missed by four days. The lesson that went into Redbrook's path table was one line: the case number belongs to the ticket, not to a person, and a waiting ticket is checked every day by whoever is in.

The Vendor Escalation Log

The log below is kept as a running internal note in the ticket, or as the first note updated each day. That way anyone on the desk can pick up the case in under a minute, and the lead's call to the account manager has every fact to hand. Fill in the header when the case is opened and add one line to the entries table at every check, whether or not anything changed. The close-out section is filled in once, when the vendor's fix is tested on your side. That section is where the knowledge from the case is kept for the next time.

VENDOR ESCALATION LOG — KEEP IN THE TICKET
Our ticket: ________   Requester: ____________   Our priority: ________
Vendor: ____________________   Product / model / version: _______________
Account / contract no.: ___________   Contract response commitment: ______
Vendor case no.: ____________   Opened: ______ by ______ via [ ] portal [ ] e-mail [ ] phone
Vendor severity (their scale): ______   What that severity promises: __________
Vendor contacts: first line ____________   account manager ____________
Our owner: ____________   Second name: ____________
Our SLA due: __________   Requester's real deadline: __________
Workaround in place: [ ] yes: ____________________   [ ] no
Chase cadence: every ________   Next check due: __________

ENTRIES (one line per check, newest at the bottom)
Date / time   Who   Channel   What the vendor said or asked   Our action   Next check
__________    ____  _______   _____________________________   __________   __________
__________    ____  _______   _____________________________   __________   __________
__________    ____  _______   _____________________________   __________   __________
__________    ____  _______   _____________________________   __________   __________

ESCALATION INSIDE THE VENDOR
  Asked for escalation on: ______   To: ____________   Reason: ______________
  Commitment missed: ______   Clause quoted: ______   Account manager called: ______

REQUESTER UPDATES
  Promised interval: ________   Last update sent: ________   Next due: ________

CLOSE-OUT
  Vendor fix / answer: ______________________________________________
  Tested on our side by: ______   On: ______   Requester confirmed: ______
  Root cause in one line (for the knowledge base): ______________________
  Days open with vendor: ____   Our SLA breached: [ ] yes  [ ] no   Cause noted: [ ]

Keep the completed logs, because three months of them answer questions no single ticket can. Which vendor takes longest to first response. Which one closes cases for inactivity. Which kind of fault keeps going to the same vendor, which is a sign that the fault should be fixed rather than reported. How many of last quarter's breaches were vendor-bound, which is the number that rewrites the SLA. A log that is filled in daily costs two minutes a day; a vendor conversation without one costs the afternoon.

Marta's ticket, from the opening, would have had "Vendor case: accounting system support, 4471-A, opened Wed 14:20 by Sean via portal, severity 2" as its first vendor note. It would have had a chase entry each morning including Thursday's, when the vendor's question would have been seen and answered the same day. It would have had an update to the finance manager every afternoon at 16:00 with the case reference in it. The target would still have breached on Friday, because the vendor's commitment was longer than the desk's promise. The finance manager would have known on Thursday that it was going to. At 10:00 on Tuesday Marta would have had a case number and a case in the vendor's queue rather than hers. She would have had eleven words to say instead of twenty-eight minutes on hold.

Frequently Asked Questions