The three-day quotation — what resistance is really about

There is a particular quiet in a training room in the first twenty minutes, before anyone has understood enough to object. It is not agreement. It is people working out what the new system is going to cost them personally.

The objection, when it comes, does not arrive as a question.

She stood up. Face flushed, voice somewhere between despair and threat: this is a disaster. To produce one order this way I need three days of solid work. Are you here to make our jobs easier, or to take them away?

What she was actually describing

Two complaints, both specific, both accurate.

One: the quotation. Her clients expected a designed document — product images laid out, formatted by hand, something closer to a brochure than a price list. She had been building those in a word processor for years, by copying and pasting.

Two: the item list. Clients sent her a spreadsheet with a hundred lines. She changed the prices and sent it back. Now she was being asked to enter a hundred items, one at a time, into a form.

Neither of these is an unreasonable objection. If the system genuinely worked the way she had just been shown it working, three days was not an exaggeration. It was an estimate, and it was roughly right.

That is the part most consultants get wrong in the moment. The instinct is to treat the outburst as resistance to change. Half of it was, and half of it was a correct report of a badly configured demo.

The two answers

The quotation was the easy one. The system generates a designed document — the product images pull in automatically, from the item record, in a layout that does not have to be assembled by hand. What she had been doing manually for years was a feature she had not been shown.

The hundred items were the real answer. Her hundred line items were not a hundred products. They were roughly ten products in a set of sizes and colours — which is what product variants are for.

Enter ten items once, with their attributes, and the hundred combinations exist. The order becomes a selection rather than a typing exercise.

I told her the truth about the shape of it: the first pass is heavy, because the data has to be entered properly one time. After that, the work is multiple choice.

What actually changed her mind

It was not the demo.

Somewhere in the middle of it she worked out the second-order effect, and it had nothing to do with the quotation. The invoices would now match the stock. Which meant they would stop coming back from the accountant marked in red. Which meant the standing argument she had been losing every month for years was over.

And the warehouse — the black hole she had been quoting against blindly, promising delivery dates on stock she could not see — would be visible to her.

The system was not offering to save her time. It was offering to end a fight. That was the argument that landed, and I had not planned it.

The three things worth keeping

The loud objection is usually two objections. One is real and configurable; one is territorial. Answering only the first leaves the resentment intact. Answering only the second insults somebody who was telling the truth.

Show the feature before you defend the system. She had been given a system walkthrough and not a walkthrough of her own job. The three-day estimate was a fair reading of what she had been shown.

Find the second-order benefit, and it will not be the one in the proposal. Nobody adopts a system for the efficiency figure on slide four. They adopt it because it settles something that has been costing them dignity.

And the note I wrote afterwards

We survived that session. It was a truce rather than a conversion, and it is worth saying plainly:

Never assume a client’s goodwill, and never underestimate the anger of an employee you have just woken out of a spreadsheet. Both of those will decide your project long after the configuration is finished.

The general version of this — what resistance is, and how it is handled before it takes a project down — is in the soft skills article and in why implementations fail. What variants and the rest of the sales cycle actually do is in order to cash.