Anticipating the Pushback: Four Objections and the Data

Thursday, 10:20, in the finance director's office at Bluewater Bank. Imogen has just finished the headcount case, one page, in hours, with the six-month picture and the sample list behind it. Robert has read it properly, which she can tell because he has drawn a small line under one number. He looks up. "This is good. Two things. Can't most of this be automated? And the operations team is the same size as yours with twice the staff to look after, and they seem to manage." Imogen has an answer to the first and not to the second. The answer to the first comes out faster and louder than she meant it to. The case does not fail in that meeting. It stalls, which is what cases do when the person presenting them starts defending instead of answering.

Pushback is the set of objections a reasonable decision-maker raises to a resource request. The four this article covers are the ones that arrive at nearly every desk. They are "can't you automate it", "other teams manage", "we will revisit next year" and "just prioritise better". None of them is hostile. Each is the question a careful person asks before spending money. And each has an answer in the ticket data. That means each can be answered before it is asked, in a calm sentence, with a number in it. This article is part of our Using Ticket Data to Justify Resources series. The article assumes the case itself has been built the way The Headcount Case and its neighbours describe. This is the article about the twenty minutes after the case has been read.

It covers why pushback is good news and the shape of a good answer. Then we take each of the four objections in turn, with the data that answers it and a worked example from one fictional desk. Next come two more you will hear, preparing the answers before the meeting, and the pushback table to copy. We finish with a short war story, in that order.

Why Pushback Is Good News

An objection means the case is being read. A case that is nodded through has usually been filed. And a case that is argued with has reached the part of the reader that decides. Robert drew a line under a number because he was checking it. A finance director checking a desk's arithmetic is the best thing that can happen to the arithmetic. The objections are not a sign the case is weak. They are the sign it has been taken seriously enough to test. And a desk that resents the test has misunderstood what the meeting was for.

The four objections are also, each of them, a fair question. Automation does remove some tickets. Some teams do manage with less. Next year is a real option with a real cost. Prioritisation does matter. The desk that treats these as attacks will answer them as attacks, and a defended number persuades nobody. The desk that treats them as the four questions it would ask in Robert's chair will have the answers ready. The answers will be short, because they will be numbers.

The single rule is never to answer an objection with a feeling. "We've tried automating and it doesn't work" is a feeling. "Automation removes about twenty-five hours a month of the ninety-hour gap, and here is the list of what it covers" is an answer. The first invites a debate about trying harder. The second invites a look at the list. And a look at the list is a conversation the desk wins, because the desk wrote it.

The Shape of a Good Answer

A good answer to pushback has three sentences and then stops. The first grants what is true in the objection, because something always is. A person who has just been agreed with listens to what comes next. The second gives the number, from the case or its appendix, that bounds the objection. That might be how much automation could remove, how the desk's volume per person has changed, or what the gap will be in a year. The third says what the number means for the ask: that it shrinks it by so much, or does not change it, or changes its timing. Then silence, which is the hardest part, because the silence is where the reviewer looks at the number.

Tone matters as much as content. The tone is the one that serves a technician declining a director's request: level, brief, about the problem and not about the person. The reviewer is not wrong to ask. The reviewer is doing exactly what the desk would want a reviewer to do with somebody else's case. (If the desk would not want that, the desk should look at its own case again.) The same calm applies when the number does not help the desk. A true answer that weakens the ask by ten hours is worth more than an evasive one that protects it. The next ask will be read by the same person.

Prepare the three sentences in writing before the meeting, one set per objection, and read them aloud once. The version that comes out unrehearsed is the version Imogen gave, which was correct and sounded like a defence. The pushback table at the end of this article is the preparation sheet. And the four sections that follow are what goes in it for the four objections every desk hears.

"Can't you automate it?"

The objection is fair because some tickets can be automated and every desk has some it has not. The answer is the automation ceiling: the share of the desk's hours, not its tickets, that automation could plausibly remove. It is worked out ticket type by ticket type from the volume breakdown. The distinction between tickets and hours is the whole answer. The ticket types that can be automated are almost always the short ones. So a desk can automate a third of its tickets and recover a tenth of its hours. A reviewer who hears "a third of tickets" and does not hear "a tenth of hours" will size the ask wrong by a factor of three.

Imogen's breakdown at Bluewater, the fictional desk this article uses for its arithmetic, is the table below. There were four hundred and thirty tickets a month, with about two hundred and ninety hours needed at the sampled median. Against about two hundred hours available, that meant a gap of ninety. Password resets were the largest type and were already the subject of a self-service reset project. Standard software installs could be scripted and offered as a one-click fix. Access requests could have their routing and approval chase automated but not the approval itself. The remaining two hundred and sixty tickets were conversations. A thing is broken in a way nobody has seen, a person needs something explained, or a laptop needs hands.

The three sentences, then: "Yes, and we are: the self-service reset project and the scripted installs between them should remove about twenty to twenty-five hours a month, and the table shows where. The gap is ninety hours, so automation brings it to about sixty-five to seventy, which is still more than half a person. The ask on the page already assumes the automation lands." That last sentence is the one that ends the objection. And it is only available to a desk that did the automation arithmetic before the meeting rather than after. Most tools automate the handling of a ticket rather than its content, QuerySolv among them. That means routing by department, service-level timers, or an API that lets a monitoring system open a ticket. None of it removes the conversation inside the ticket, and the conversation is where the hours are. What to automate first, and what never, is the subject of What to Automate First and What Never.

"Other teams manage"

This is the comparison objection, and it is the one Imogen had no answer to. The honest first reaction is that the other team's work is different, which is true and sounds like an excuse. The answer has two parts, and neither of them is about the other team. The first is to compare the desk with itself. Compare volume per technician over the last two years, hours per ticket then and now, and backlog slope then and now. A desk whose volume per head has risen by a third while its hours have not is not failing to manage. It is managing a third more, and the number says so without anyone having to say anything about operations.

The second part is to ask, genuinely, what "manage" looks like on the other team. In my experience it looks like one of three things. One is unlogged work, so the other team's volume is a sample of what it actually does. Another is unpaid evenings, which are invisible until the person doing them leaves. Or it is a backlog nobody has measured. The desk should not say any of that in the meeting. It should say: "Our tickets per technician have gone from about a hundred and forty a month to about two hundred and fifteen over two years, with the same hours per ticket; I would be glad to sit down with the operations lead and compare how we each count, because if they have a method we are missing I want it." That is both true and the end of the objection. Once in a while the operations lead does have a method, and the desk gets it for free.

Never compare with a team outside the organisation, and do not let the reviewer do it either, politely. A figure about how many users a technician supports elsewhere is a figure about a different mix of work, counted differently, in a place with a different everything. The desk's own history is the only comparison that controls for all of that. And a volume series counted the same way every month is how to make that history survive being checked.

"We will revisit next year"

Deferral is the most reasonable-sounding objection and the most expensive, and the answer is to put a number on the year. The capacity sum has a slope. The backlog grows by so many tickets a month, the first-response median lengthens by so much, and the gap widens as volume grows. Run it forward twelve months with the method in Forecasting Volume Simply, which is a ruler on a graph and nothing cleverer. Say what the desk will look like at the next budget round. At Bluewater the backlog was growing by about twenty-five tickets a month. In a year that is three hundred more, and a first-response median past a working day. Volume growth will have taken the gap from ninety hours to something over a hundred.

Then add the cost that is not on the slope, which is the person who leaves. A desk running a ninety-hour gap is a desk where someone is doing the gap in their evenings. And the usual way that ends is a resignation. Replacing a technician costs the desk, in its own hours, the recruitment, the handover, and a quarter at half capacity for the new person. At Bluewater's figures that is something like three hundred hours, which is more than three months of the gap. The desk does not threaten this. It states it as a risk with an hour figure beside it, which is what a risk is.

The move that turns a deferral into a decision is to propose a trigger. "If we revisit next year, could we agree now the number that would reopen it sooner? I would suggest the backlog passing two hundred and fifty or the first-response median passing six hours, and I will report both monthly." A deferral with an agreed trigger is a conditional yes with a date the data will set. A deferral without one is a refusal with better manners. And the desk that accepts it has agreed to make the same case again in a year with worse numbers and less credibility. Write the trigger into the decision record, as After the Decision describes, and then report against it every month whether anyone asks or not.

"Just prioritise better"

This objection is the only one that is also an instruction to keep doing what the desk is already doing. And the answer begins by agreeing that prioritisation matters and then explaining, without heat, what it does and does not change. Prioritisation decides which ticket is worked first; it does not change how many hours of tickets there are. A perfectly prioritised queue with a ninety-hour gap is a queue in which the right tickets wait instead of the wrong ones, and they still wait. The distinction between priority and the order of work, and why a desk cannot prioritise its way out of volume, is made at length in Priority Is Not the Order of Work.

The data that answers it is the bottom of the queue. Pull the twenty oldest tickets and show what they are. At Bluewater they were a shared mailbox for a new branch, a printer that worked but slowly, and four training requests. They also included a request to move a desk phone and a report that needed a new column. All legitimate work. None of it urgent. All of it waiting for lack of hours, exactly as a well-prioritised queue should leave it. Then the sentence that turns the objection into a choice: "This is what better prioritisation produces, and it is what we have; these are the things that wait. If the organisation would like some of them not to be done at all, I would welcome that decision, and here is the list with hours against each."

That offer is sincere and should be made sincerely, because it moves the conversation from "work harder" to "do less". That is the only conversation that changes the arithmetic without a hire. Sometimes the reviewer does pick things off the list. The desk stops supporting personal phones, or the report with the new column goes back to the team that owns it. That is a real win and should be written up as one. And the scope conversation it opens is worth having on its own terms. More often the reviewer looks at the list, finds nothing they want to stop, and the gap is suddenly their problem too, which is where it belonged.

Two More You Will Hear

"The numbers must be wrong" is not an insult; it is a request for the appendix, and the answer is to produce it. Open the ticket system with the reviewer in the room and recompute one of the counts together. That takes two minutes and ends the objection for good. A number the reviewer has watched being made is their number now. If you run QuerySolv the volume and backlog figures come from the standard reports. In that case, the recomputation is a report opened on a screen. In any tool, the saved searches that produce the counts should be ready to show. Never say "trust me". Say "let's look", and look.

"Could we get a contractor, or outsource it?" is a fair alternative and deserves a fair answer in hours. A contractor fills the gap quickly and leaves with everything they learned. The handover and ramp hours are paid twice, once in and once out. A six-month contract on a permanent gap buys six months. Outsourcing some or all of the desk is a real option with its own trade-offs, worked through in Working With an MSP. The desk should say so rather than dismiss it. The three sentences: "Yes, a contractor would close the gap faster than a hire; the ramp and handover cost about the same either way, and we pay it again when they leave; if the gap were temporary I would recommend one, and the six months of data say it is not."

Preparing the Answers Before the Meeting

The table at the end of this article is filled in before the case is presented, one row per objection. The desk's own numbers go in the third column and the three sentences in the fourth. It takes an hour, most of which is the automation ceiling, and it is the hour that separates Imogen's first meeting from her second. Read the fourth column aloud once. If a sentence sounds defensive in an empty room it will sound worse in a full one. Bring the appendix, physically or on a screen, and know where in it each number lives.

Then the things never to do, because each of them has lost a case that the numbers had already won. Never argue; answer, and if the answer is not accepted, say "I will leave the table with you" and leave it. Never mention anyone's salary, including your own. Never threaten resignation, yours or anyone's, even as a risk with a number on it. The exception is when the number is on the page and the sentence is about the desk rather than a person. Never say "I told you so" to a reviewer who deferred last year, even when you did. The data says it for you, and the data is allowed to. And when an objection lands that you have no answer to, say "I don't know; I will have it by Thursday", and have it by Thursday. A reviewer remembers Thursday for years.

The Pushback Table

The table below is the preparation sheet for the meeting. And the version here carries Bluewater's numbers in place of blanks so the shape is clear. Replace every figure with your own from the evidence list and the case. One row per objection, including the ones you think this particular reviewer will not raise, because they will. The third column is the number and where it lives in the appendix. The fourth is the three sentences, written out in full, because the version you improvise is never the version you wrote.

A Short War Story: The Revisit at Greyfield Timber

At Greyfield Timber, a desk lead called Hollie presented a sound headcount case, was told "let's revisit it next year", and said "that's fine". It sounded like a yes with a delay and she had not prepared an answer to it. She proposed no trigger and reported nothing in the months between. By the next budget round the backlog had passed four hundred. Her senior technician had resigned in the autumn after a run of evenings nobody had counted. The replacement, hired in a hurry, was at half capacity for a quarter. That cost the desk roughly three hundred hours on top of the gap it already had. The case was approved that year at twice the size, for two people, by the same director. He said he wished he had known how fast it would go. He could have known. The slope had been on the page the year before. And all it had needed was a sentence running it forward and a number to stop at.

Imogen's second meeting at Bluewater, a week after the first, took eleven minutes. Robert asked about automation and she handed him the ceiling table. He asked about operations and she offered to compare counting methods with their lead. He thought that was a good idea, and she did it the following week. He did not say "next year". He said "what happens if I say next year", and she showed him the slope and proposed the trigger. He approved the hire instead because, he said, he would rather decide now than be told by a number in six months. The data had been the same in both meetings. The difference was an hour with a table.

Frequently Asked Questions