Alfred AnyanInsights
← All insights

Enterprise AI buying path: What Kwame Learned Before a Pilot Could Be Paid

Team of three people collaborating on a laptop in an office setting.

Christina Morillo

Investor interest can validate that enterprise AI is worth discussing, but it does not identify the person who can approve access, deploy the product and release a budget before runway ends. Founders need to map that buying path before treating a promising meeting as demand.

At 6:40 p.m. on a Thursday in Accra, Kwame was still in a borrowed meeting room, watching a procurement manager close her laptop while the building’s security lights came on outside. His product turned support calls and field reports into a searchable internal assistant. Two investors had asked for a second meeting that week. Neither had asked the question now sitting between Kwame and a surviving company: who inside this customer could say yes?

The operations lead liked the demo. The IT manager wanted a security review. Procurement needed a vendor record. Finance had not seen the product. Kwame had enough cash for the next stretch of building, selling and paying a small team. A long approval cycle could leave him with a respected pilot and no paid deployment. The bad ending was plain: the product would become another promising AI demo that everyone praised and nobody owned.

Interest created momentum, not a route to revenue

The investor conversations mattered. They made Kwame look again at a market he had spent months treating as difficult because it was outside fintech. Enterprise AI had become easier to explain than it had been a year earlier. Buyers had seen enough tools to understand the category. Investors had started asking where AI could reduce repeated internal work, improve retrieval and give teams a faster way to act on documents they already had.

But category interest creates a dangerous kind of confidence. It can make a founder assume that curiosity will travel through the customer organisation on its own.

Kwame’s contact had a real problem. Her team spent too much time asking the same questions across calls, documents and handovers. She could champion the product because she felt that pain every week. She could not approve access to internal material. She could not decide where the product would run. She could not create a budget line without someone above her agreeing that the problem was worth paying to solve.

Those are separate decisions, often made by separate people with separate incentives. The person who feels the pain wants relief. The person responsible for risk wants control. The person holding the budget wants a clear reason to spend. A founder who calls all three “the customer” can spend months moving a deal forward while never moving it toward payment.

The buyer map had four names, not one

The next morning, Kwame opened the notes from the meeting and replaced “strong enterprise lead” with four blank columns.

The champion was the operations lead. She could describe the work that was breaking down and introduce the people around it.

The approver was the executive who could decide that this work deserved priority over other projects already competing for attention.

The deployer was the person who would decide what data could be used, where the product could sit and what had to happen before a team could rely on it.

The payer was the person who could commit money, either from an existing budget or through a process that would take longer than Kwame’s runway allowed.

A single person can hold more than one of these roles. Small companies often make that possible. Larger organisations rarely do. The useful question is not whether the demo went well. It is whether each role has a name, a reason to act and a next step that fits the time left to the company.

This is where founders can protect themselves from building around the loudest request in the room. In Enterprise AI deployment requirements: How Tunde Kept One Roadmap, the harder problem is keeping deployment needs from turning every buyer conversation into a different product.

A pilot needs a paid ending before it starts

Kwame returned to the operations lead with a smaller proposal. He did not offer a broad transformation project. He asked her to help define one workflow, the people who would use it, the data needed for that workflow and the person who would judge whether it was useful enough to fund.

He also asked a question founders often delay because it makes a friendly conversation less comfortable: if this pilot works, whose budget pays for the next phase?

The answer was incomplete. Finance had to be involved, and the IT manager wanted to see a narrower deployment plan. That was still progress, because uncertainty now had an owner. Kwame could decide whether to spend more time on the deal with the actual path visible, rather than mistaking a successful demo for a signed contract.

A pilot without a defined paid decision can become free product development under another company’s priorities. The team gives feedback, asks for changes and praises the founder’s speed. Then the internal sponsor changes roles, the budget closes or the security review expands. The founder is left with work that looked like traction from a distance.

The better pilot begins with a constraint: what must be true for this customer to pay? That question shapes scope. It also shapes what the founder should refuse to build.

Runway turns every unknown into a product decision

By Monday, Kwame’s investor interest had not disappeared. He still planned to take the meetings. But he stopped treating fundraising attention as evidence that the enterprise motion would work on its own.

He had a more useful test. Could this buyer identify the champion, approver, deployer and payer while there was still enough runway to act on the answer?

If the answer was no, he could keep the relationship warm without assigning his next month of engineering to it. If the answer was yes, he could build the smallest version that made deployment and payment possible, then ask for the next commitment before adding more.

That afternoon, the operations lead sent Kwame a calendar invite with the IT manager and a finance colleague included. It was not a contract. The product still had to earn its place. But the meeting had finally changed shape: three people who could each block the deal were now in the room, and Kwame knew what he needed from each of them before his team wrote another custom request.

Comments

No comments yet.