Two kinds of SoD buyer, and why one of them never answers your email again

Article 3 of Field Notes, a series on what we learned selling an offline SAP access-risk tool.

There is a specific silence that follows a good demo. The call went well, the questions were sharp, someone said "this is exactly what we have been looking for", and then nothing. You follow up twice. You get a polite one-liner or you get nothing at all.

It happened to us enough times that I stopped treating it as a sales failure and started treating it as data. The pattern turned out to be readable, and it is readable early. Here is what separates the deals that closed from the ones that evaporated.

The compliance-driven buyer

This buyer has a deadline and an auditor. Usually one of:

• An external audit finding on segregation of duties that needs a documented response
• A carve-out, merger, or S/4HANA go-live where someone asked for an SoD report as a gate
• A first-year SOX or ISAE 3402 scope where the control owner has never produced this evidence before

What they need is a document. A defensible, dated, reasonably rigorous document that says these are the conflicts, here is the analysis, here is what we are doing about it. Once they have it, the need is gone. Not reduced. Gone, until the next audit cycle, and by then the person may have changed roles.

These buyers are wonderful during a trial. They are engaged, they run real data, they ask good questions, and they get value fast, because a tool that produces a clean risk report in an afternoon is exactly what solves their problem. We extended trials for several of them, happily, because the engagement looked like the strongest signal we had.

Then the report was produced, the finding was closed, and the conversation ended. In some cases with a straight answer, which I appreciated. In others with silence.

I want to be fair to these buyers. Nobody misled us. They needed a thing, they used the tool to get the thing, and the tool worked. The mistake was ours: we read intensity of use as intent to buy, and those are different variables.

The efficiency-driven buyer

This buyer already produces SoD reports. That is the point. They produce them repeatedly and it hurts.

Typical shapes:

• A security team running a role redesign across multiple countries who needs to simulate the impact of a role change before it goes to PFCG
• A consulting firm doing the same analysis for a different client every month
• An internal audit function that has to re-run analysis every quarter and reconcile it against last quarter
• Anyone whose current process involves exporting to Excel and doing lookups by hand

Their problem is not "I need a report". It is "I need this report forty times and each one currently costs me two days". The value is recurring, so the licence is recurring, so the renewal conversation is easy because the pain would come straight back.

Every multi-year relationship we have is with this second type. Without exception.

How to tell them apart in the first call

You can usually diagnose this in fifteen minutes with three questions.

"When did you last run an SoD analysis, and how?" Never, or years ago, or "we have a spreadsheet from the auditors": compliance-driven. Last month, using some combination of tooling and manual work, with an opinion about what was wrong with it: efficiency-driven.

"What happens after you have the report?" "We close the finding" is one answer. "We hand it to the role owners and then argue about it for six weeks" is a completely different answer, and the second one is a buyer whose pain lives in remediation, not detection.

"Who asked for this, and what is their deadline?" A named date tied to an audit milestone is a warning. A named date tied to a project go-live can go either way. No date at all, driven by the team's own frustration, is the best signal in the set.

None of this means you should refuse to work with compliance-driven buyers. It means you should price and resource them differently. A short licence, a fixed-scope engagement, or a one-off assessment fits their actual need much better than a trial that you keep extending in the hope of a renewal that was never going to come.

The thing I got wrong

For about six months I treated trial extension as a relationship-building move. Someone would ask for two more weeks, I would give six, on the reasoning that generosity now buys goodwill later.

It did not. In the compliance-driven cases, extending the trial simply let them finish the project for free, and I had removed my own deadline in the process. In the efficiency-driven cases, the extension was not needed, because those buyers had already decided by week two.

What I do now is ask what the extension is for and what happens at the end of it. If the answer is a specific next step with a specific person, the extension is fine. If the answer is vague, the extension will not change the outcome, and saying so politely tends to produce an honest reply. Several times that honest reply was "we only needed this for the audit", which is a perfectly good answer and one I would rather have in week three than in month four.

The yes is not the end, it is the start of a different process

Everything above is about the technical evaluation, which is the fast part. What comes after it took me longer to understand and takes considerably longer to survive.

Once the sponsor and the security team say yes, the file leaves the people who tested the tool and moves to procurement or vendor management. The person who picks it up has no SAP background, has not seen a demo, and has no way to judge whether the analysis is any good. That is not a criticism of them. Assessing the tool is not their job. Their job is to assess the supplier and reduce commercial and legal exposure, which is a legitimate objective and a completely different one.

What that produces, repeatedly:

• A supplier onboarding portal with a registration flow built for a company with a hundred employees and an ISO certificate
• A security questionnaire written for hosted services, which for offline software generates a long conversation covered in article five
• A requirement for three comparable quotes in a category where the products are not comparable and two of the three would be answering a different question
• Requests for audited financial statements, insurance certificates, and a credit rating, which for a small vendor is a genuine hurdle and not an unreasonable one
• A master services agreement drafted for contractors and body-shop suppliers, being applied to a software licence
• Data processing agreement negotiation for a product that processes no personal data on our side, which takes weeks to establish

Timescales stretch accordingly. At large organisations the gap between "we want this" and a purchase order has run from three weeks to two quarters in my experience. Public sector adds procurement thresholds and tendering rules on top, which are there for good reasons and are not optional. If a budget year rolls over in the middle, the whole thing can restart with a new approver.

The part I would flag to anyone selling into this is that the last person to touch the decision is often the person furthest from the problem. They read a form. If the internal champion stops carrying the file, the evaluation quietly gets re-decided on price and supplier attributes by someone who has never seen the product run, and the answer to "why this one" has to survive being retold second-hand by a non-specialist. Writing the justification in language a category manager can reuse turns out to matter more than anything in the demo.

It also interacts badly with the compliance-driven buyer above. An audit deadline in eight weeks and a procurement cycle of twelve does not resolve in the buyer's favour. Several times the honest outcome was that they could not buy the tool in time and were better served by a scoped assessment delivered as a service, which goes through a different and much shorter approval path.

What actually helps, on both sides, is asking about the process on the first or second call. Who signs, at what value, is there an existing supplier framework we could be added to, what is the threshold above which a tender is required, and what does the security review need. None of those questions are awkward and the answers change how the deal should be run. I did not ask them for the first year and it cost me two deals that were technically won.

For the buyer side

If you recognise yourself as the compliance-driven type, say so. Vendors are not offended by it. You will get a scoped commercial proposal instead of an unwanted courtship, and you will probably get it cheaper, because a defined short engagement is easier to price than an open-ended trial.

The worst outcome for everyone is the one where both sides pretend the evaluation is about a long-term platform decision when it is actually about closing one finding by the end of the quarter.

The second worst is a technically won evaluation that dies in an onboarding portal in November because nobody mentioned in September that the budget had to be committed by then.

Next in this series: why organisations that already own SAP GRC Access Control keep evaluating additional tools.