Pending User vs Pending Vendor vs On Hold

It is Wednesday, 11:00, and time for the weekly queue review. The operations manager has one question for the desk: "Fifty-eight tickets are marked Pending. Pending on whom?" Sam, who runs the desk, opens the filter and starts reading. Ticket 2210, waiting for the requester to say which laptop. Ticket 2214, waiting for the supplier to ship a dock. Ticket 2219, waiting for the finance director to approve a licence. Ticket 2231, waiting for the fourth of next month, when the new starter arrives. Ticket 2240, waiting for nothing anyone can identify. Eleven tickets in, the manager says "so the answer is: we do not know", and the meeting moves on. The fifty-eight stay Pending.

A waiting state is any status that means the desk's next action is blocked on something it does not control. There are three kinds, and they are different enough that treating them as one makes both follow-up and reporting impossible. Pending user means the desk is waiting on the requester. Pending vendor means the desk is waiting on an outside party: a supplier, a courier, another company's support line. On hold means the desk is waiting on a date or a decision inside its own organisation: a change window, an approval, a start date. Three parties, three nudges, three very different conversations when the wait runs long. This article is part of our Ticket Workflow & Status Design series. This article is about keeping the three apart.

This article covers what each of the three waits is and is not, then why separating them matters for follow-up and then for reporting. Next come the nudge rule for a waiting requester, the chase rule for a waiting vendor, and the parking rule for a date. We cover what to do when the tool has only one or two waiting labels. Then we cover what to do when the tool's SLA clock keeps running through all three, which is more tools than you would think. A one-page set of waiting-state rules comes at the end. The general case of what a status is for is in What a Status Is For. The shape of a definition is in Statuses That Mean Something. This article takes both as read and goes deep on the states where tickets spend most of their lives.

Three Kinds of Waiting

The three waits differ in who can end them, and that is the only distinction that matters. A pending-user ticket ends when the requester replies. The requester is somebody the desk can write to directly, in plain words, with a question they can answer in a minute. A pending-vendor ticket ends when an outside organisation does something. That organisation has its own queue, its own reference number and its own idea of urgency. An on-hold ticket ends when a date arrives or a decision is made. Neither a nudge nor a chase moves a calendar. Same status icon, three completely different levers.

Pending user is the most common and the most misused. It is correct when the desk has asked a specific question that it cannot proceed without. Examples are "which of the two laptops", "what does the error say", and "when can we have the machine for an hour". It is incorrect when the desk has not asked anything, which happens more often than anyone admits. A technician reads a ticket, thinks "I need more detail", sets the waiting status and does not send the question. The requester is now blocking a ticket they do not know about. Ask them in six months how the desk performed and you will find out how that felt from their side.

Pending vendor is correct when a named outside party owes the desk a thing. That could be a delivery, a replacement under warranty, an answer from a software company's support line, or a line installation from a carrier. It has a reference number from the other side, or it should, and it has a date the other side promised, or it should. The two things that make it a real state rather than a hope are the reference and the promised date, both written in a note. The article on escalating to vendors and other teams is about what to do when the promised date passes. This article is about recording it so you notice.

On hold is correct when the ticket is parked on purpose, until a date or a decision that belongs inside the organisation. The new starter arrives on the fourth; the change window is Thursday night; the finance director approves licences on the last Friday of the month. The requester is not blocking it. No vendor is blocking it. The organisation has decided, reasonably, that this ticket waits. The desk's job is to make sure it waits until the date and not a day past it. On hold is also where tickets go to be forgotten, which is why it needs the strictest rules of the three.

Why Separating Them Matters for Follow-up

Each wait has a different follow-up, and a status that blends them makes every follow-up wrong for two thirds of the tickets. The follow-up for a waiting requester is a short, friendly nudge after a few working days, repeated once, then a closing warning. The follow-up for a waiting vendor is a chase on the promised date, with the reference number, escalated through their account contact if it slips. The follow-up for a date is a check on the date, and nothing before it, because nudging a calendar is a waste of a reply. Send the requester nudge to the vendor and you look odd. Send the vendor chase to the requester and you look rude. Send either to a date and you have written to nobody.

The practical cost is that follow-up only happens by filter. On a desk of three with ninety open tickets, nobody re-reads the waiting tickets daily. They filter for "waiting on requester, untouched for three days" on Monday and Thursday, and for "waiting on vendor, chase date passed" every morning. If the three waits share a status, neither filter exists. In that case, follow-up becomes a thing a conscientious technician does from memory until the week they are busy. Follow-up Cadences That Keep Tickets Moving builds the rhythm; the separate states are what the rhythm runs on.

The other cost is to the requester, who is told different things in each case and is entitled to all of them. A requester whose ticket waits on them should have been told "we need X from you and the ticket waits until we have it". A requester whose ticket waits on a vendor should have been told "we are waiting on the supplier, reference 7781, promised Friday; we will chase them Monday if not". A requester whose ticket is on hold should have been told "this is parked until the fourth, when the equipment arrives; you will hear from us that day". Three sentences, three facts. A single Pending status with no reply tells them one thing, which is that the desk has stopped talking.

Why Separating Them Matters for Reporting

Time spent waiting means something different in each state, and a report that adds the three together reports nothing. Time waiting on the requester is time the desk does not own; a desk cannot be faster than the slowest reply it is waiting for. Time waiting on a vendor is supplier performance, and it is the number you take to the renewal meeting. Time on hold is the organisation's own decision-making speed, and it is the number you show the finance director when they ask why laptops take six weeks. Blend them into "time pending" and all three parties can point at the other two.

I learned this on a desk whose monthly report showed "average time pending: nineteen days", a number that was true and that nobody could act on. Split three ways the following month, it was four days waiting on requesters and twenty-six waiting on one supplier. There were thirty-one days on hold for licence approvals that happened once a month. The supplier got a conversation. The approval got moved to weekly. The requesters, who had been quietly blamed for all nineteen days, turned out to be the fastest party in the building.

Tools that record every status change can give you the split for free. Many can report how long a ticket spent at each status. That gives you time waiting on the requester and time on hold as separate numbers. Where the vendor wait and the date wait share one label, the split between them comes from the note line or a custom field. Whatever tool you use, look for the time-in-status report. If it does not exist, export the status change log and build it in a spreadsheet once a month. It takes twenty minutes, and it ends the argument about whose fault the nineteen days are.

Pending User: The Nudge Rules

A pending-user ticket gets two nudges and a closing warning, on a fixed cadence, and then it resolves. The cadence that works on most desks is three working days. The question goes out on day zero with the status change. The first nudge goes on day three, and the second on day six. The closing warning on day nine says the ticket will be marked resolved on day twelve unless the desk hears back. On day twelve it is. Every step is a public reply the requester receives. None of it is silent, and none of it is a status change on its own, because a status change on its own tells the requester nothing.

The nudge is short and assumes good faith. "Still need the error text from you to go further on this; whenever you have a minute." It does not say "as per my previous e-mail". It does not count the days. People go on leave, change roles, and sometimes fix the thing themselves and forget to say. A nudge that reads like a summons gets a reply that reads like one too. The closing warning is equally plain: "We have not heard back, so we will mark this resolved on Friday; just reply if it is still a problem and it reopens." That last clause is the important one, and it should be true. In many tools a reply from the requester to a resolved or closed ticket reopens it automatically. In some the technician has to reopen it by hand when the reply lands. Find out which yours is, and make the promise true either way.

The one exception to the cadence is a ticket that blocks something real for other people. The missing answer may be holding up a shared system, a new starter's first day, or a purchase with a deadline. In that case, the nudge goes to the requester's manager on day three rather than to the requester on day six, with the ticket's history attached. That is not an escalation of blame; it is routing the question to someone who can answer it. The rule on the one-page sheet says when, so that nobody has to decide it under pressure.

Pending Vendor: The Chase Rules

A pending-vendor ticket is only in that state if the note carries three things: who the vendor is, their reference number, and the date they promised. Without the reference, the next chase starts from nothing. Without the date, the chase has no trigger and happens when somebody remembers, which on a busy desk is after the requester complains. The note is written at the moment the ticket enters the state. It is written again every time the vendor promises a new date. That way, the ticket's history is the history of the vendor's promises. That history is also a useful document at renewal time, and vendors know it.

The chase runs on the promised date, not after it. On the morning the delivery was promised, the technician checks. If it has not arrived, the chase goes out that day, quoting the reference and the promise, asking for a new date. The new date goes into a new note. The second missed date goes to the vendor's account contact rather than their support queue. The third goes to whoever on your side owns the vendor relationship, with the three notes attached. Each step is cheap because the note made it cheap.

The requester hears about every missed date, in one sentence, before they ask. "The supplier promised Friday and missed it; we have chased and they now say Wednesday; we will update you then." The requester cannot make the supplier faster, but they can plan around an honest date. They will forgive a slow vendor much faster than a silent desk. The ticket's status stays pending vendor throughout; the notes and the replies carry the movement. If your tool's only waiting label for outside parties is something like On Hold, the first line of the note says "VENDOR:". In that case, the filter is a search for that word.

On Hold for a Date: The Parking Rules

An on-hold ticket has a date, and the date is the entire definition. "On hold until the fourth, new starter arrival." "On hold until Thursday's change window." "On hold until the licence review on the last Friday." A ticket on hold with no date is not on hold; it is abandoned with a polite label. The date goes in the note and in whatever due or reminder field the tool offers. The requester is told the date in a reply at the moment the ticket is parked. That way, the silence between now and the date is a silence they agreed to.

On the date, the ticket comes off hold whether or not the thing it was waiting for has happened. If the equipment arrived, the ticket goes to In Progress and the work starts. If it did not, the ticket goes to pending vendor with the supplier chased, or stays on hold with a new date and a new reply to the requester explaining why. What it never does is sit past its date in the same state with the same note. The daily filter is "on hold, date passed", and on a well-run desk that filter is empty by 09:30 every morning.

Set a maximum hold. Thirty days is a reasonable ceiling for most desks. Anything parked longer is probably a project wearing a ticket. The article What to Promise and What Never to Promise has the argument for giving projects a date instead of a clock. When a hold reaches the ceiling, the ticket gets a decision. One option is to resolve it with a note saying the request will be raised again when the date is near. The others are to split it into a request with a due date, or escalate the decision to whoever is sitting on it. A hold without a ceiling is where the fifty-eight came from.

When the Tool Has Fewer Labels Than Waits

Most tools ship one or two waiting labels, not three, and the fix is a convention rather than a new status. A typical fixed list has one label for the requester's move, Awaiting Reply or Pending Customer or similar. It has one label, usually On Hold, that has to carry both the vendor wait and the date wait. The convention is the first line of the note: "VENDOR: Northgate Supplies, ref 7781, promised Fri" or "DATE: 4th, new starter". Full-text search finds either word, and a technician reading the ticket knows the kind of wait before the second line. It is not as neat as a third status. It is considerably neater than a third status nobody defined.

A custom field on the department's form can carry the same distinction where the tool allows one, and a field filters more cleanly than a search. The trade-off is that fields have to be set and notes have to be written anyway. So a desk that is already disciplined about the note gains little from the field. A desk that is not disciplined about the note will not set the field either. Start with the note. Add the field when the filter becomes something you run every day.

The table below puts the three waits side by side so the convention has something to hang on. Read across a row to see the whole rule for one kind of wait. Read down a column to see how the three differ on one point.

When the Clock Does Not Stop

Many tools keep the SLA clock running while a ticket waits. The right response is to design the targets with that in mind rather than to pretend otherwise. A service level agreement, or SLA, is the desk's written promise of how fast it responds and resolves, by priority. A clock-stop is a feature some tools have that pauses the resolution countdown while the ticket is in a waiting state. Some tools have it. Some have it for one state and not another. Some have none at all, and a ticket sitting in any waiting state keeps counting down, with only non-working hours and holidays excluded. Test yours by leaving a ticket in each waiting state over a weekend and reading the due time on Monday. If your tool is the third kind, a ticket that waits nine days for a requester will breach its resolution target. In that case, the breach will be real, recorded and e-mailed to the assignee.

The first design move is to promise response and update, not end-to-end resolution, on anything that routinely waits. A first-response target the desk controls completely. An update interval is a promise to write to the requester every so many hours while the ticket is open. The desk also controls that completely, and it is the promise requesters actually feel. A resolution target on a ticket that depends on a supplier is a promise about the supplier, made by the desk. The article Response vs Resolution Targets explains why that promise is the one to split. Most SLA engines let you set a first-response target, a resolution target and an update interval per priority. Some add a target for every subsequent reply. Set the update promise as the strict one and the resolution promise as the realistic one.

The second move is to set resolution targets that include the typical wait, per priority, from the desk's own history. If Medium tickets that wait on requesters typically wait four working days, a Medium resolution target of two days is a promise to breach, and a breach that teaches nothing. Pull last quarter's time-in-status numbers, add the typical wait to the typical work, and set the target where the desk already meets it nine times in ten. Tighten later, when the waits shrink. A target set to the work alone, on a desk whose tickets wait, is a monthly list of breaches with the same cause.

The third move is to read breaches on waiting tickets as their own category in the monthly review. A breach on a ticket that spent eight of its nine days in pending vendor is a supplier finding, not a desk finding. The review sheet in SLA Breaches and What They Teach has a cut for exactly that. The breach is still real. The requester still waited. But the change it calls for is a conversation with the supplier or a split promise, not a faster technician. Treat the clock as a measurement rather than a verdict, and a clock that does not stop becomes a feature. It never lets a waiting ticket pretend to be on time.

The fourth move is the honest one: do not stop the clock by hand. On tools with a clock-stop, the temptation is to park tickets in a waiting state to protect the compliance number. The number improves while the queue does not. On tools without one, the temptation does not exist, which is a mercy. The compliance figure on a desk whose clock never stops is a slightly worse-looking, considerably more truthful number. The manager who understands the difference is worth keeping.

A Short War Story: The Fifty-Eight at Bellweather Logistics

Bellweather Logistics ran a three-person desk for a freight company. Sam finally sorted the fifty-eight Pending tickets from the Wednesday meeting. They turned out to be twenty-one waiting on requesters who had never been sent a question, and nineteen waiting on four suppliers with no reference numbers recorded. There were eleven on hold for a licence approval with no date, and seven waiting on nothing anyone could reconstruct. The sort took two technicians a full day. The worst find was a dock-station order that a supplier had cancelled six weeks earlier for a missing purchase order number. The ticket had sat in Pending the whole time, and the requester, a dispatcher, had been borrowing a colleague's dock since. Sam split Pending into three conventions with a note line each, set a thirty-day ceiling on holds, and put the chase date in every vendor note. The next Wednesday's question got an answer in one sentence per party. The lesson, which Sam wrote on the sheet below, was that a wait with no name on it is not waiting for anyone.

The Waiting-State Rules

The sheet below is the three waits on one page, written to be read by a technician setting a status, not by a committee. Fill in the cadence numbers to suit your desk and your requesters; the structure stays the same. Keep it beside the status definition cards, and put the note-line conventions in the first paragraph of whichever page your desk reads most.

WAITING-STATE RULES — ONE PAGE
Desk: ________________   Owner: ________________   Reviewed: ________________

PENDING USER  (tool label: ______________)
  Enter only with a public reply that asks the question and says we wait on them.
  Note line:  USER: asked for ______________ on ______
  Nudge 1 after ____ working days.   Nudge 2 after ____ more.
  Closing warning after ____ more; resolve ____ working days after that.
  If the missing answer blocks other people: ask the requester's manager at nudge 1.
  Never used for: waiting on anyone who is not the requester.

PENDING VENDOR  (tool label: ______________)
  Enter only with a note carrying: vendor, their reference, the promised date.
  Note line:  VENDOR: ______________  ref ________  promised ______
  Tell the requester who we wait on and the promised date, in a reply.
  Chase on the promised date (not after).  New promise = new note.
  Second missed date: vendor's account contact.  Third: our relationship owner.
  Tell the requester about every missed date before they ask.
  Never used for: waiting on the requester, or on our own calendar.

ON HOLD FOR A DATE  (tool label: ______________)
  Enter only with a date and what happens on it, in a note and a reply.
  Note line:  DATE: ______  for ______________
  Nothing until the date.  Off hold ON the date, every time.
  Maximum hold ____ days; at the ceiling, decide: resolve, split, or escalate.
  Never used for: tickets we have not got to, or waits with no date.

DAILY FILTERS (every morning, empty by ____:____)
  [ ] pending user, untouched ____ days      [ ] pending vendor, promised date passed
  [ ] on hold, date passed                    [ ] any waiting ticket with no note line

THE CLOCK
  Our SLA clock [ ] pauses on waiting states   [ ] keeps running (tested on ______)
  If it keeps running: resolution targets include typical wait; update interval is
  the strict promise; breaches on waiting tickets reviewed as their own cut.

Two of the lines are worth a moment. The "tested on" blank beside the clock exists for a reason. The only way to know what your tool does is to put a test ticket into each waiting state over a weekend and read the due time on Monday. The documentation is sometimes right. And the fourth daily filter, "any waiting ticket with no note line", is the one that catches the fifty-eight before they are fifty-eight. On a desk that runs it, the count is usually zero or one. The one is a ticket somebody set in a hurry on Friday at 16:55, which is forgivable and quickly fixed.

Sam ran the four filters every morning for a month. By the end of it the Wednesday meeting's question had a boring answer. There were twelve waiting on requesters, all nudged on schedule, and nine waiting on suppliers, each with a reference and a date. There were four on hold with the fourth of the month written on them, and none waiting on nothing. The operations manager asked whether the desk had got faster. It had not, particularly. It had just started saying who it was waiting for, and that turned out to be most of what anyone wanted to know.

Frequently Asked Questions