IT services buyers agree to a first call when an approach establishes three things before asking for anything: that you understand their specific environment rather than their sector, that leaving the problem alone carries a named cost, and that something dated makes this month different from next quarter. An approach that establishes all three earns the time. One that establishes two earns a polite reply.
IT services buyers are not short of vendors. They are short of reasons to spend forty-five minutes with a new one. The approaches that earn a first call establish three things before asking for anything.
One: that you understand their environment, specifically
Not their sector. Their environment - the migration they are midway through, the platform they are consolidating, the compliance date on their calendar. Sector-level relevance reads as research; environment-level relevance reads as understanding.
Two: what doing nothing costs
Every technical buyer has a backlog of things that would be good to fix. The item that gets scheduled is the one with a cost attached to leaving it alone - downtime, audit exposure, engineering hours burned on maintenance rather than delivery.
The proposal that describes the architecture competes on rate card. The one that describes the consequence competes on outcome.
Three: why this conversation, now
A first call needs a reason to happen this month rather than next quarter. Absent a trigger - a contract end, a project start, a regulatory date - the meeting will be agreed politely and rescheduled indefinitely.
The three tests compound
They are not a menu. An approach that passes one and fails the others fails in a predictable way, and the failure tells you which test was missed.
Environment and consequence without a trigger earns a warm reply and no date. The buyer agrees the problem is real, thanks you for the detail, and suggests picking it up once the current programme lands. Nothing is wrong with the argument. There is simply no reason for it to be this week.
Environment and trigger without a consequence gets the meeting and loses it afterwards. The call happens, the scope is discussed, and what comes back is a request for a rate card. Without a named cost of inaction there is nothing to weigh the price against, so price becomes the only thing left to weigh.
Consequence and trigger without the environment does not get read at all. A well-argued cost attached to a generic situation reads as a template that happens to be well written. Technical buyers recognise the shape of it immediately.
The person who takes the call is rarely the person who decides
In IT services the first call is usually granted by one person and justified to several. A technical owner judges whether the approach is credible. A budget owner asks what it displaces. On anything touching data or access, security has a view, and procurement arrives later with its own.
That changes what an approach has to survive. It has to be forwardable: legible to someone who did not receive it, has no context for who you are, and will spend under a minute on it. Internal jargon, a reference to a previous exchange, or an argument that only works in sequence all break at the point of forwarding.
The test is blunt. Could the recipient forward your note to a colleague with no covering explanation and have it still make sense? If it needs the covering note, it will not travel, and what does not travel does not get decided.
Triggers are observable, which is what makes them useful
A trigger is not a mood. It is a dated event with consequences attached, and most of the ones that matter in IT services are visible from outside the account: a contract approaching its end date, a platform reaching end of support, a migration with a published milestone, an audit or certification cycle, a change in technical leadership.
Building a target list around observable timing is a different exercise from building one around firmographics. Firmographics tell you who could buy. Timing tells you who has a reason to decide this quarter. A list scored on both is shorter, and it is the version sales will actually work rather than file.
The constraint is honesty about what you can see. Inferring a trigger from a job advert and presenting it as knowledge reads worse than not mentioning timing at all, because it fails the first test while trying to pass the third.
How to test this against your own pipeline
This needs no new tooling. Take the last fifty approaches that went out and mark each against the three tests: does it name the environment, does it name a cost of inaction, does it name a reason for now. Then mark which ones produced a call.
Two patterns tend to appear. The approaches that passed all three are a small share of the total and account for a disproportionate share of the meetings. And the failures cluster. A team is rarely weak on all three at once; it is usually weak on one, the same one, every time.
That is a more useful finding than a conclusion about volume, because each version has a different fix. A missing trigger is a targeting and timing problem. A missing consequence is an offer and proof problem. A missing environment is a research problem, and it is the cheapest of the three to correct.
Frequently asked questions
What do IT services buyers want before agreeing to a first call?
Three things, established before anything is asked of them: evidence that you understand their specific environment rather than their sector, a named cost of leaving the problem alone, and a reason the conversation needs to happen now rather than next quarter. An approach that establishes all three earns the time.
Why does sector-level relevance not work on IT services buyers?
Because every vendor has it. Naming a buyer's sector demonstrates research, which is cheap and widely done. Naming the migration they are midway through, the platform they are consolidating or the compliance date on their calendar demonstrates understanding, which is not.
What counts as a buying trigger in IT services?
A dated event with consequences attached: a contract approaching its end date, a platform reaching end of support, a migration milestone, an audit or certification cycle, a change in technical leadership. Most are observable from outside the account, which is what makes them usable for targeting.
Who else decides whether a first call happens?
Rarely just the person who received the approach. A technical owner judges whether it is credible, a budget owner asks what it displaces, and on anything touching data or access security has a view. The approach therefore has to make sense to someone who did not receive it and has no covering explanation.
Should an approach lead with the technical solution or the business consequence?
The consequence. A proposal that describes the architecture invites comparison on rate card, because the architecture becomes the only variable on the table. A proposal that describes what the current situation costs invites comparison on outcome. The technical detail still matters, but it belongs after the reason to care.
How can you tell which of the three tests an approach is failing?
The failure pattern says so. Warm replies that never produce a date mean no trigger was established. Meetings that convert straight into a procurement conversation mean no cost of inaction was established. Approaches that draw no reply at all usually failed on the environment, because they read as a template.
