Decision Maker

Deals that collapse at the end usually collapse for one reason: the person the rep spent weeks talking to wasn't the person who decides.

The scene is familiar. Three meetings with the team that would use the product, a demo that landed well, enthusiasm every time, an explicit "we want this." Then the contract goes out and two weeks pass with no reply. A follow-up produces the answer: "I passed it up, but there's no budget for it this quarter." The person who said yes never had the authority to spend.

After that happens a few times it becomes clear the problem isn't persuasion technique. The wrong person was being persuaded from the start. So sales began separating two questions that look like one: does this person like it, and can this person approve it. Decision maker is the answer to the second.

Small organizations don't need the distinction. In a ten-person company, whoever takes the meeting is whoever decides, and the same person will be the one entering a card number that afternoon. Past fifty people the person who uses the tool and the person who pays for it separate, and that's when the term starts earning its place.

Who the decision maker is depends on the amount, not the title. A tool at $4,000 a year ends at a team lead; above $40,000 a year an executive or the founder appears. Inside one company, doubling the contract value moves approval up a level. Estimating the likely amount during first contact therefore also settles who to aim at.

Authority splits into three parts, and someone is the decision maker only when all three sit with the same person.

1. Budget authority — whether this person can spend this money. Whether it comes out of a budget already allocated for the year or needs a fresh request changes the timeline substantially, often by a full quarter.
2. Veto — some roles can't approve alone but can stop things alone. Security is the standard example. That person isn't the decision maker, and the deal still ends if they object.
3. Signature — whoever actually puts their name on the contract. In plenty of companies the approver and the signer are different people, and skipping this check leaves a finished deal parked for two weeks.

Finding out is a matter of asking, not guessing. "Who's the decision maker?" tends to make people defensive, so the question gets reshaped into one about process: "What does the approval process usually look like for a tool this size?" or "When you brought in something similar last time, who gave final sign-off?" The first asks about a person, the second about a precedent, and the second gets far more accurate answers.

At larger companies a buying committee moves instead of one person — the users, their manager, security, procurement. There is still one final approver, but any of the others can stall things for their own reasons before that approver is reached. This is why authority stands as its own item in a qualification framework like BANT, which weighs budget, authority, need, and timing.

The term appears mostly where someone is deciding whether a deal moves forward.

The first place is the condition for advancing a stage. Many teams make "the decision maker is identified" a requirement for reaching the proposal stage. A proposal sent before that gets forwarded and never read. Since the document travels to people who weren't in any meeting, knowing who those people are is what determines what goes in it.

The second is the discovery call, the first conversation about the customer's situation and problem. Approval process is one of the things asked there. Skip it on the first call and the bill usually arrives two months later.

The third is judging how much to trust a forecast. A deal marked to close this month rests on thin evidence if nobody has met the approver yet. Splitting the list by that one fact — approver met or not — visibly sharpens the forecast, usually more than any adjustment to the stage probabilities does.

"We haven't met the decision maker on this one yet. I don't think it lands this month."

Talking down an optimistic date, which keeps the record matched to reality.

"Sending a proposal before we know who approves it doesn't accomplish anything."

The content of the document depends on who receives it.

"Is this an amount you can approve, or does it go further up?"

Checking where the limit of authority sits, asking about the amount and the approval level in one question.

When Sofia takes on an enterprise account at Pagedeck, the first thing she draws is a map of people: who will use it, who holds the budget, who could object. However enthusiastic the users are, the deal stops if approval doesn't come, so the approval process gets confirmed on the first call.

Whether Grace joins a meeting is decided from that same map. If an executive is coming from the customer's side, Sofia brings Grace in — not because founder-to-founder conversations move faster, but because that executive asks which company numbers this tool changes rather than which features it has. The same product needs different sentences depending on who is listening.

The most common mistake is hunting for the most senior person available. Higher on the org chart does mean more authority, so the logic holds up at a glance. But founders don't approve every purchase. Bring a $4,000-a-year tool to a founder and the answer is usually to go talk to the team lead, and the relationship built with the users gets awkward in the meantime. The right question isn't who ranks highest but who approves this amount.

The second mistake is treating it as a search for one person. There is one final approver, which makes it tempting to concentrate everything on them. In practice that person asks around before deciding, and one objection is enough to postpone it. A deal where only the approver was convinced stalls quietly in security review or procurement, and the rep spends weeks without knowing why.