Notes for owners · Industry playbooks
How buyers choose between IT, software and SaaS vendors
Technology buyers take a name from a peer, test it against an engineer and sign after a finance check. This post follows the choice in four stages and shows where vendors drop out.
The GullySales team · Updated 6 Oct 2026 · 5 min read
On this page
Technology buyers choose in four stages, and most vendors lose at the second or third. Someone gives them a name. They check the name against a website and an engineer. They test it with a pilot, a demo or an assessment. Then a finance head or owner signs. Marketing is mostly noticed in stage two, sales is mostly lost in stage three, and the second order is won or lost long after stage four.
Stage one: who gives the buyer a name?
A CTO whose cloud bill jumped asks two other CTOs. A finance head with a regulator's circular on her desk asks the internal auditor. A founder who needs an app built asks other founders. By the time any of them reaches your website, a shortlist of two or three names exists.
This is why search, review sites and LinkedIn behave as checks, not discovery. A buyer types your firm's name, or the problem plus a city, to see whether the name holds up. A page that matches the exact problem, such as a GST-linked ERP migration or an AWS cost review, makes that check come out well. A generic services page does not.
Stage two: what does the check look for?
The buyer is trying to learn two things in a few minutes about a firm in the IT, software and SaaS group. Does this firm work on my kind of problem, and are real people behind it? Both answers come from specifics.
| Group | What the buyer looks for | What loses the check |
|---|---|---|
| SaaS companies | Who it is built for, what a trial shows | A trial signup nobody replies to |
| ERP providers | Closing entries and reports in the buyer's own trade | A demo that skips the accountant's questions |
| Software development | Named engineers, what happens after launch | Rates and logos with no detail |
| IT services and networking | A local firm that picks up after a move | No sign of support afterwards |
| Cybersecurity | Credentials, an auditor's comfort | Vague claims about "protection" |
| Managed IT | What the agreement covers, in plain words | A quiet year that looks expensive |
| Cloud and DevOps | A fixed-scope assessment | An open-ended proposal |
| Automation and RPA | A pilot with a pass mark | A bot that broke at the last vendor |
The best work in the group often sits under an NDA, so the case study cannot name the client. Describe the problem, the systems and what was done in terms an engineer can test, and say plainly that the client is under NDA. Offer a reference call once the client agrees. Never invent a logo or a figure.
Stage three: where do free demos and assessments go wrong?
The buyer asks for a customised demo, a free assessment or a proof of concept, and many vendors say yes to everything. Then the buyer carries the plan to a cheaper partner. It happens often.
For example, a Pune cloud partner is asked for a free assessment by a manufacturer whose bill has jumped. The partner spends days on it and sends a long document. The manufacturer's finance head forwards it to a cheaper firm and the partner hears nothing. Had the partner agreed the scope, what the buyer would provide, and what decision the assessment would lead to, the assessment would have been a step, not a gift.
Before any free effort, agree three things in writing: what you will look at, what the buyer will supply, and what happens next if the result is good. For pilots, agree the pass mark before the pilot starts. A buyer who will not agree to that is usually collecting a plan.
Stage four: who signs, and what do they fear?
The person who felt the pain is rarely the person who signs. The CTO or IT head fears a risky architecture. The accountant or finance head fears an audit trail that does not hold and a renewal that arrives without warning. The owner fears paying for something that nobody uses.
A sales process that talks only to the person who filled the form loses to one that has answered the others. Ask early who else has to be comfortable. Send the engineer the technical note. Send the finance head the terms, the renewal and what is covered in plain words. The sales enablement page for cybersecurity firms shows how those documents are prepared.
What happens after the first project?
Maintenance, retainers, the second bot, the next phase of the product and the annual retest all follow the first delivery. They are rarely proposed. A client who has heard nothing since go-live calls whoever is nearest, and that is not always you.
Put the next offer in the handover document, with a date for the first review. Keep a renewal calendar with a named person for each account. The buyer persona page for cloud and DevOps firms is a good place to start writing down who each account's three people are.
What to do next
Pick your last five lost deals and mark the stage where each one stopped answering. If three stopped after the demo, the problem is stage three, not your advertising. Never reached a call? Then the check in stage two is failing. A free audit goes through how your enquiries arrive and where they go quiet, and ranks what to fix first.
Related services