What corporates actually want in a proof of concept

A corporate wants a proof of concept to move one number it already tracks, in its own environment, with its own data, measured in a way its own finance and operations people will accept. Everything else you show is evidence for that, and a sponsor who can't state the number won't get a pilot funded.

Most founders prepare for the wrong meeting. They rehearse the product and turn up with a demo, a roadmap, and a competitor comparison, while the sponsor across the table is assembling an internal case that has to survive colleagues who'll never meet you and will judge it on its weakest sentence.

The five questions a sponsor has to answer internally

Before a pilot gets approved, someone inside the company writes a short internal case and defends it. That case answers five questions. If your material does not answer all five, the sponsor invents the missing answers, and sponsors under time pressure drop the request instead.

1. What problem. Which problem inside this company does this address, named the way the company names it. The internal one, attached to a process, a cost line, or a risk someone already reports on.
2. Who owns it. Which team's number moves. A problem that belongs to nobody in particular can't be funded, because no cost center carries it. It's the fastest way to find out whether your champion is the right champion.
3. What does success look like in numbers. A named metric, a baseline, a target, and a test period, agreed by both sides before the work starts. That document decides more pilots than the product does.
4. What does it cost us to run this. Not your price. The buyer's internal cost: engineering hours, security review time, data preparation, legal review, and the attention of the people who use it. Sponsors who can't estimate this will defer rather than guess in front of a manager.
5. What happens if it works. The path from a successful test to a funded deployment, including which budget pays and when it gets set. A pilot with no named next step is an experiment, and experiments end when the quarter does.

How screening actually works

The champion finds you first. That person owns a problem, heard about you from a program or a colleague, and wants the problem gone, but a champion controls access and internal energy rather than money. The budget owner sits above or beside them, holds a cost center, and set the year's plan before you turned up. A request that wasn't in that plan competes against things that were, which is why a pilot everyone likes can still wait for the next planning cycle.

Then come the gatekeepers, and each one adds calendar time rather than opinion. Security reviews how you handle data and what happens if you're breached. Legal reviews liability, indemnification, and the terms your contract assumes. Privacy reviews what personal data touches the system. IT reviews how you connect to systems built before your category existed, and holds a veto over anything needing engineering it hasn't staffed. And procurement runs vendor onboarding: entity details, tax documentation, banking, insurance, and financial checks.

Those reviews run in sequence more often than in parallel, and most sponsors don't know to push them into parallel. Answer the security questionnaire before it arrives, hand legal a contract that matches the buyer's standard terms, and you remove weeks without changing the product at all. Put a better product carrying unfamiliar paperwork next to an adequate one that already clears every review, and the second wins more often. Being better is necessary, but it isn't what closes.

What this looks like in practice

Consider a mid-size industrial company with plants in several locations and a maintenance operation that runs on scheduled inspections. An outside company turns up with software that predicts equipment failures earlier than the schedule does. The plant manager who takes the first meeting is enthusiastic, because unplanned downtime ruins their month. They're the champion, and they can't fund it.

The budget sits with the operations director, whose plan was set before the meeting happened and who is measured on downtime hours and maintenance spend. The predicted failure rate the software reports is useless to them, because it appears in no report they file. What changes the outcome is the translation. The test gets defined against downtime hours on one production line, with a baseline from the last comparable period, a fixed window, and a threshold both sides agree in writing means success. Now they can defend the request, in the units they're accountable for.

The reviews still happen. IT has to say how the data leaves an old plant network, security asks where it lands, legal asks who's liable if a prediction is wrong and a machine runs to failure, and procurement asks for insurance and tax documentation. A company that expects those questions answers each of them in advance. No figures appear here on purpose.

Where pilots go wrong

The most common failure is a pilot nobody scored. It ran, the users liked it, and when the operations director asked what it proved there was no document to point at. The criteria were never written down, so the result couldn't be read.

The second is the unpaid pilot that eats a quarter. Free removes the procurement conversation temporarily and the buyer's commitment permanently. Some early tests should be free, but know what you're trading when you offer one.

The third is scope that grows during the test. A second team asks for a variation, the champion says yes because internal enthusiasm feels like progress, and the test now carries two success definitions.

The fourth is the demo treadmill: demos across several departments with no budget owner attached, which is a company being educated at your expense. And the fifth is meeting the paperwork at the end, when the security review starts from zero and carries a successful test past the budget cycle it was meant to land in.

When to get help

Most of this is learnable, and plenty of companies work it out on their own with one patient champion and a lost year. If your sponsor can already name the budget owner and you can write the success criteria yourself, run it yourself.

Getting help is worth it once the pattern repeats. Two or three corporate conversations that started warm and then stopped moving usually means something structural, and it's rarely the product. It's the buying process, the pricing frame, or the absence of a defensible internal case. That's easier to diagnose from outside, because the people inside the corporate will be polite about it and your own people are too close to it. We work these situations across multiple verticals, and keep an advisory network across business sectors for when a problem needs a domain specialist.