Offering an Alternative Instead of a Wall: Four Kinds of Yes

Wednesday, 14:10, at Bellweather Logistics. Femi, a dispatcher, has raised ticket 7733: "Can I have a second monitor like the planners have? I'm switching between the route map and the driver messages all day and I keep missing messages." Aisha checks. Monitors are allocated by role, and dispatchers get one. The spares cupboard has none, and the hardware budget is frozen until the new quarter. The correct reply is no. Aisha types "Second monitors are allocated to planning roles only", reads it back, and recognises it for what it is: a wall. Femi will read it, say nothing, and keep missing messages. In a month a driver will sit at a depot for an hour because a message went unseen. The no was right. The wall was not.

An alternative is a different way of meeting the need behind a request, offered in the same message as the no. A wall is a no with nothing after it. The difference is not politeness; walls can be perfectly polite. The difference is whether the requester leaves with something to do. This article is part of our Saying No Professionally series. And it is about the fourth part of a good no, the one that turns a refusal into help.

It covers finding the need behind the request, which is where every alternative starts. Then come the four kinds of alternative: the workaround, the partial yes, the later yes and the who-else. The article explains when each fits and how to say it. Next come choosing between them, with Femi's monitor as the worked example, and the fake alternative and how to spot one in your own reply. The article finishes with what to say when there is genuinely none, a short war story, and the alternatives table to copy, in that order.

The Need Behind the Request

Every request is a need wearing the requester's best guess at a solution. The alternative has to meet the need, not the guess. Femi asked for a monitor. Femi needs to see the route map and the driver messages at the same time. Those are different sentences, and only the second one has more than one answer. A technician who hears "monitor" has a yes-or-no question. A technician who hears "see two things at once" has a design problem with half a dozen solutions, several of which cost nothing.

Finding the need takes one question, asked before the no is written: "What would having this let you do?" Sometimes the ticket already says, as Femi's did. Often it does not, and the request arrives as a bare noun: "a second monitor", "admin rights", "access to the shared drive". Ask, and listen for the verb. "Install the plug-in", "open the old project files", "stop missing messages". The verb is the need. The noun was a proposal, and proposals can be declined without declining the need.

Naming the need in the reply also does something for the requester: it proves the no was about the method and not about them. "You need to see the map and the messages together. A second monitor isn't something we can allocate to dispatch roles. Here is what will do the same job" is a message about Femi's problem. "Monitors are for planners" is a message about Femi's rank. The first gets a thank-you. The second gets a quiet decision never to ask the desk for anything again, which is a kind of feedback the desk never receives.

The Workaround

A workaround meets the need with what the requester already has. Femi's one monitor can show two windows side by side. The chat tool can be set to pop a notification over the map. The messages can be made to sound an alert. None of these is a second monitor. Any of them stops Femi missing messages, today, with no budget and no policy change. That makes the workaround the first alternative to look for and the one most often skipped. It is skipped because it requires the technician to think about the need for a minute rather than about the stock cupboard.

A workaround is an alternative only when it is specific and tested. "You could arrange the windows differently" is a suggestion. "Press the key that snaps the map to the left half and the messages to the right. I can come and set it up in five minutes" is a workaround. If the technician has not tried it, it is a guess. A guess offered as an alternative fails in the requester's hands with the no still attached. Where the workaround exists because of a problem the desk already knows about, it should already be written down. That is the subject of Known Errors and Workarounds. For that known problem, the alternative in the reply is then a link and a sentence.

Say what the workaround does not do. Snapped windows are smaller than two screens. A sound alert will annoy the desk next to Femi's. A workaround with its limits stated is a thing the requester can decide about. A workaround sold as equivalent to the request is a small lie that comes back as a second ticket reading "the thing you suggested doesn't really work". Honesty about the limits is also what makes the requester believe the no. A technician who admits the workaround is second-best is plainly not just getting rid of them.

The Partial Yes

A partial yes grants the safe or possible part of the request now and declines the rest. The requester wants admin rights to install one program; the desk installs the program. The requester wants access to a whole shared drive; the desk grants the one folder their manager confirms they need. The requester wants a new laptop because the current one is slow; the desk replaces the drive, which was the slow part. In each case the need is met, or mostly met, and the thing the desk was right to refuse stays refused.

The partial yes is the most satisfying alternative to deliver. And it is the one most likely to be misread as a full yes, so the reply has to draw the line clearly. "I've installed the plug-in for you. Admin rights themselves stay with the desk. So if the plug-in needs updating, raise a ticket and we'll do it the same day" is a partial yes with its edge marked. "I've installed the plug-in" alone is a full yes in the requester's mind. The next request for admin rights will begin "but last time you...". Draw the line in the sentence, every time, even when it feels pedantic.

Where the partial yes leaves a remainder that may be granted later, give the remainder its own ticket rather than leaving it to live in the closed one. The installed plug-in is done. The question of whether the design team should have a managed way to install their own tools is open. And it belongs to someone other than the technician. If you run QuerySolv, link the two tickets so that the remainder carries the history of the request that spawned it. In any tool, the point is that the open question is somewhere a person will see it. It should not be in a resolution note nobody reads twice.

The Later Yes

A later yes is the request granted on a date, and it is an alternative only if the date is real. "We can order a second monitor in the new quarter's budget, which opens on the first of next month. I've added you to the list" is a later yes. "We'll look at it when budget allows" is a wall with a window painted on it. Requesters have been told "when budget allows" before, and they know it is the sound a request makes when it is being filed under never.

The later yes carries the same obligation as any promised time. The date is written in the ticket. The ticket stays open or sits in a waiting status with a follow-up date. And the desk comes back on the date whether or not the news is good. The discipline of promising a time and keeping it, including what to say when the date slips, is in Honest ETAs. For the alternative itself, two things matter. There is a date or a trigger. The requester is told what to do in the meantime, which is usually one of the other three alternatives. A later yes paired with a workaround is the strongest reply in this article. The need is met badly today and properly next month, and the requester knows both.

Be careful not to offer a later yes you do not control. "The new budget opens next month" is only an alternative if the desk lead has confirmed that monitors for dispatchers will be in it. If that is not yet decided, the honest version is "I've put the request to the lead for the new quarter's list. I will tell you by the end of the month whether it's in". That is a later answer rather than a later yes, and is still better than a wall. The later yes that turns out to be a later no is the most damaging failure in this article. The requester stopped looking for other answers on the strength of that yes.

The Who-Else

A who-else names the person or team who can grant what the desk cannot, and makes the introduction. Dispatch monitors are allocated by role, and the role allocation is owned by the operations manager. The desk cannot change it, and the operations manager can. "Monitors are allocated by role, and that list is owned by Grace in operations. If you'd like dispatch added to it, she's the person to ask. I'm happy to give her the technical side if it helps" turns a wall into a route. The need is still unmet. It is now unmet in the right office.

The who-else has a weak form and a strong form, and the strong form is a handover rather than a direction. A direction is "ask your manager". A handover is "I've sent this to Grace with the ticket number and what you need, and copied you in, so she has the context". The strong form costs a forwarded message or a transferred ticket. It saves the requester from pleading their case from scratch to someone who has never heard of them. When the who-else is a different department working in the same help desk, the handover is a transfer. In that case, the requester keeps the ticket and its history. That is the neatest version of this alternative. It is also one of the better reasons for putting several departments in one queue, as QuerySolv does.

The who-else is also the alternative for every policy no, because every policy has an owner and most policies have an exception route. "We don't give admin rights to user accounts" ends with "and if your role genuinely needs them, the exception is approved by the security lead, who is Tomas" or it ends as a wall. The route may be heavy, and it may usually say no. But a route exists and the requester has a right to know where it is. The who-else may be a manager or a director asking for the exception themselves. That upward version is the subject of Saying No Upward.

Choosing Between Them

Run the four in order, and offer the first one that fits plus, where it helps, one more. Workaround first, because it meets the need today with nothing spent. Partial yes second, because it meets most of the need with the risk removed. Later yes third, because it meets the whole need on a date. Who-else last, because it meets nothing today and sends the requester to another queue. Offering two is often right: a workaround for now and a later yes for the real fix. Or a partial yes now can go with a who-else for the remainder. Offering all four is a menu, and a menu makes the requester do the technician's job.

Femi's monitor, run through the order, comes out like this. Workaround: snapped windows and a message alert, which Aisha can set up in five minutes and which stops the missed messages today. Partial yes: the spares cupboard is empty, so none, though a leaver's larger single monitor due back on Friday would have been one. Later yes: the new quarter's order, if the lead confirms dispatch monitors are on it, which Aisha can find out by tomorrow. Who-else: Grace in operations owns the role list, if dispatch wants to make the case permanently. The reply offers the workaround now and the later answer by tomorrow, with Grace's name as the route if the answer is no. Femi gets three sentences and a visit at half past two.

The choosing takes a minute once the need is known. It is a minute most desks do not spend, because the wall takes ten seconds and feels finished. Keep a short check in your head, or on the card beside the screen, before any no goes out:

• Have I named the need, in the requester's words, before the no?
• Is there a workaround with what they already have, and have I tested it?
• Is there a safe part of the request I can grant today, with the line drawn clearly?
• Is there a real date, confirmed by someone who controls it?
• Is there a named person who can grant what I cannot, and have I made the introduction?
• Have I offered one or two, not all four?

The Fake Alternative

A fake alternative is a sentence shaped like help that gives the requester nothing to do. "You could try asking around." "There may be other options." "Perhaps your team has a spare." "Have you considered a different approach?" Each sounds like the fourth part of a good no and each is a wall with better manners. Requesters recognise them faster than technicians do, because they are on the receiving end more often. The test is whether the sentence has a verb the requester can perform, with a who or a when attached. "Ask Grace in operations, who owns the list" passes. "Perhaps speak to someone in operations" does not.

The commonest fake alternative is the one the technician does not mean. Consider "I'll see what I can do" offered to end the conversation, with no intention of seeing anything. It is a later yes with no date and no plan. It fails in two weeks when the requester asks what was seen. The second commonest is the route that does not exist. Take "you can request an exception through your manager" at an organisation that has no exception process. That sends the requester and their manager into a corridor with no doors. Check the route before naming it. If you have never seen anyone walk down it, it may not be there.

The third is the alternative that answers a different need. The requester wants to read notes at home; the alternative offered is a bigger screen at work. The technician has solved something, and it is not the thing. This one usually comes from skipping the first step, naming the need, and going straight to the nearest thing the desk can give. Any alternative that does not contain the requester's verb is suspect. The way to catch it is to read the reply back and ask whether Femi can now see the map and the messages at once. If the answer is "well, sort of, if he buys a bigger desk", start again.

When There Is No Alternative

Sometimes there is none, and then the alternative is the truth. The need cannot be met another way, the safe part is too small to matter, there is no date, and nobody else owns it either. The honest reply is "I don't have another way to get you this, and I'd rather tell you that than send you round in circles." It is a wall, and it is the one kind of wall requesters accept, because it has been checked and it says so. A technician who says "there is no alternative" after visibly looking for one is believed. A technician who says it in the first reply is assumed not to have looked.

So look, and say that you looked. "I've checked whether the spares cupboard has anything, whether the lead can confirm a monitor in the new quarter, and whether there's a software setting that would do the job on one screen, and none of those gets you there." Three clauses, each naming a thing that was tried, each true. The requester now knows the no was not laziness. The desk has written down, in the ticket, what was considered. That is what the manager will ask for if the requester escalates. Checking takes ten minutes. Not checking costs the desk its credibility on every no that follows.

When there is no alternative and the ticket has to close, close it with the same care as any other ticket the desk cannot fix. Say what was asked, what was tried, why it cannot be done, and what would change the answer. The shape of that closing message, and how to close a ticket honestly when the answer is simply no, is in Closing the Ticket You Cannot Fix. The one sentence that always belongs is what would change the answer. "If a budget opens for dispatch hardware, this is first on the list" is a door even when there is no alternative today. A door is the difference between a no and a dismissal.

A Short War Story: The Handheld Scanner at Meridian Parts

At Meridian Parts, a warehouse supervisor called Grant asked the desk for a new handheld scanner. The one his team had could not read the longer barcodes a new supplier had started printing. A technician called Ola replied that the requested model was not in the hardware catalogue and closed the ticket. Grant's team of six spent the next four months typing fourteen-digit part numbers by hand for everything from that supplier. By then, that supplier accounted for a third of what came in. The typing errors eventually sent a pallet of the wrong brake assemblies to Meridian's largest customer. The customer sent it back with a complaint that reached the managing director. The review found two alternatives that had been available on the day of the ticket. The existing scanners accepted a firmware update from the manufacturer that read the longer codes. The update took ten minutes per device. Non-catalogue hardware could be bought through a procurement exception that the purchasing lead approved routinely for warehouse equipment. Ola had known about neither, had not asked what the scanner was needed for, and had answered the noun. The returned pallet, the overtime and the customer's goodwill cost many times what six firmware updates would have. A wall does not stop the need; it only stops the desk from seeing what the need does next.

The Alternatives Table

The table below is the four kinds of alternative as a reference to keep where replies are written. It covers when each fits, the sentence shape, what goes in the ticket, and the trap each kind sets. The last row is the honest no-alternative, which belongs on the table because it is the one most desks forget is available. Read down the first column in order when a no is forming. Stop at the first row that fits, and consider whether the row below it would strengthen the reply. Copy the sentences freely and change the words to the requester's own.

Aisha's reply to 7733 went out at 14:31 with two rows of the table in it. It offered the snapped-window workaround with its limit stated. It promised to confirm by Thursday whether dispatch monitors were on the new quarter's list, with Grace's name as the route if not. She set the windows up at half past two, and Femi stopped missing messages that afternoon. The lead confirmed on Thursday that two dispatch monitors were in the new order. The no, that a monitor could not be allocated that day, stood throughout. Nobody noticed it, which is roughly the aim.

Frequently Asked Questions