Who decides and who pays

A demo that delights the person in front of you can still go nowhere, because in most sales several people play different roles:

• the user feels the problem and would work with the product every day;
• the decision maker says yes or no;
• the economic buyer actually pays.

At Greg's six-bay shop, Martha the administrator is the user: she types reminders in Viber by hand, about five hours a month. Greg the owner is both the decision maker and the economic buyer. He can spend the money, but he doesn't feel the problem and has never counted those five hours.

Others touch the product too. The mechanics would type in the mileage and repair history, so they're users who can make or break the data. Car owners get the reminders and benefit, but they pay nothing to GarageDesk.

So when someone loves the demo, the first question isn't "will they buy?" but "which role do they play?" Only the person with the money can say yes with money.

"I'll mention it to the owner" is one of the most common ways a promising sale dies quietly. The user means it, but a second-hand retelling loses everything that made the demo work: the numbers, the examples, the answers to the owner's questions. And the user has a full day of their own work.

What helps is to bring the decision maker into the conversation, with the user's real figures:

1. ask the user for their own numbers: hours a month on the problem, calls, customers lost;
2. ask when the owner is in and whether the user can be there too;
3. meet the owner with the user present and talk about those numbers.

For Greg's shop: Martha's five hours a month on reminders and the regulars who don't come back, presented on Saturday morning with Martha in the room.

What doesn't help: waiting a second week, sending a longer feature list to forward, or offering the user a discount. The user can't spend the owner's money, however cheap the offer.

It's tempting to ignore everyone who neither decides nor pays. That's a mistake, because users can block a product without saying a word.

At GarageDesk the reminders depend on data the mechanics type in: mileage and the work done on each car. If a mechanic finds that annoying and skips it, the reminders have nothing to go on. Nobody refused anything; the product simply stops working, and three months later the owner cancels because "it didn't help".

So users matter in two ways:

• before the sale, as the people who feel the problem and bring the numbers;
• after the sale, as the people whose daily habits decide whether the product delivers what the owner paid for.

For a small business that means asking early: "Who would need to do something new every day for this to work? What would make that easy for them?" A setup that takes the mechanics ten extra seconds per car is a different product from one that takes two minutes.

The owner signs, but the users decide whether the owner renews.

The roles don't always belong to different people. In Paul's two-bay garage, Paul is the owner and the mechanic at once: he feels the problem, decides and pays. All three roles sit in one person.

That changes the sale in two directions:

• faster: there's nobody to persuade second-hand and no "I'll mention it to the owner". If Paul is convinced, the decision can happen in the same conversation;
• harder to get attention: Paul is under a car all day with the phone ringing. He has the least time of anyone to listen to a demo, so the conversation must be short and about his own numbers.

In bigger shops the roles split. Greg's six-bay shop has an owner who decides and pays, an administrator who feels the problem and mechanics who enter the data. There, meeting one person is rarely enough.

A useful habit is to note, for every shop you visit, who holds which role. The same product needs a different conversation in a two-bay garage than in a six-bay one, and confusing the two wastes visits.

The same product has different reasons to exist for different roles, and each person listens for their own.

The owner who pays thinks in cars, visits and money. A feature list ("online booking, reminders, repair history in one dashboard") makes him do the translation himself, and he usually won't. What he hears is a cost he can see or revenue he can count:

• Martha's five hours a month on reminders: a cost he's never looked at;
• regulars who forget their next service and go elsewhere: revenue walking out of the door.

The user cares about her day: her evenings back, fewer awkward calls, fewer angry customers at the desk.

So a good conversation with Greg starts from his numbers, not the product's features: "Martha spends about five hours a month on reminders, and some regulars still don't come back. How many came in last spring and returned this autumn?" The product appears at the end, briefly, as a way to get that number up.

The user makes the problem real; the decision maker turns it into a yes or no.

"Regulars go elsewhere" becomes persuasive only when it's the owner's own number, counted from his own records. The calculation is short:

1. Lost regulars = regulars last period − those who came back. Use two comparable seasons, such as last spring and this autumn.
2. Revenue per regular per year = average bill per visit × visits per year.
3. Revenue walking away = lost regulars × revenue per regular per year.

Example: 120 regulars came in last spring and 84 came back this autumn, so 36 didn't. A regular spends about 2,500 UAH per visit and comes twice a year: 36 × 2 × 2,500 = 180,000 UAH a year.

Two things make it honest. First, the figures come from the owner, so the result is "his number, not yours". Second, not every lost regular is recoverable: some moved away or sold their car. A reminder service won't bring back all 36, but even a few of them would cover a 600 UAH monthly fee many times over.

The common slip is dropping one factor, usually visits per year, which halves the answer.

Knowing the roles changes which problem is worth starting with. A problem can be real and still hard to sell, if the person who pays never feels it.

Sort candidate problems by who feels them and in what currency:

• felt only by staff, invisible to the owner: mechanics dislike paper job cards, Martha's desk is too small. Real, but the owner doesn't see them as his cost, so he won't pay to remove them;
• felt by people who don't pay at all: car owners would like an app with their repair history. Nice for them, but they aren't GarageDesk's customers;
• felt by the owner in money he can count: regulars who forget their next service and go to another shop. That hits the owner's revenue directly, in visits he can count.

The last kind is the easiest to sell, because the owner can see the gain on his own books.

Problems felt by users still matter: they make the case real and decide whether the product gets used. But the first problem to build for should be one the economic buyer can put a number on.

Selling to a small business has a simple order, and most people start it from the wrong end: they pitch to the first person they meet and ask for a commitment straight away.

The order that works:

1. Find the person who feels the problem every day. In Greg's shop, that's Martha at the desk.
2. Collect their numbers: hours spent, calls made, visits lost. These make the problem real and specific.
3. Bring those numbers to the person who decides, ideally with the user in the room, in the owner's language of cars and money.
4. Ask the decision maker for a concrete commitment: a payment, a prepayment or at least a date for the next step.

Each step needs the one before. Asking for a commitment before the owner has seen the numbers usually ends with "I'll think about it". Bringing numbers you guessed yourself, instead of the user's, invites "that's not how it is here".

The first person you meet is useful: they often feel the problem and know the numbers. They're just rarely the one who signs.