A good PoC in a mid-sized company ends in go or no-go

A good PoC in a mid-sized company does not say "AI can do this."It says: "We know whether we build or stop."

This is where consultants and mid-sized companies usually break apart.

Consultants see a PoC as proof of technology.Managing directors, CFOs and IT leads need a decision tool.

A consultant PoC usually means:

• clean test data
• a short prototype in 2–6 weeks
• usable results on demo data
• a pretty demo that sparks internal enthusiasm

Looks good. Works in the meeting.But not in live operation.

No legacy ERP integration.No operational data from live systems.No works council discussion.No clear process responsibility.No ownership for running it afterwards.

In the end the consultant says: "It works."The owner of the business is left alone with the questions that count.

Why does this happen? Consultants earn on the next phase. An honest NO-GO costs them revenue. So nobody defines the PoC in a way that allows it to fail.

For a mid-sized company a PoC is something else.

It is a small, honest stress test:

• Does this work with our own data, dirty parts included?
• Does it run in the live process, not only in a sandbox?
• How much accuracy or relief is realistic before go-live?
• Which hurdles come from IT, data protection, works council, department?
• Who leads the project, and who runs it afterwards?
• Is the next step clear: stop, adjust or build for production?

A concrete example:

Invoice reconciliation. 150 delivery notes per week.Legacy ERP, unstructured data, works council involved, IT staffed with one person.

After 10 days: clear GO.€41,000 savings per year, calculated conservatively.Deployment option settled. Project owner named. Kick-off two weeks later.

Consultant PoC: "The technology works in principle."Mid-sized PoC: "We have enough clarity for a go/no-go decision."

In a mid-sized company, time, trust and internal attention are scarce.

A weak PoC burns political capital.Worst case the verdict is: "AI does not work here."

The problem, though, was that the PoC had been defined wrongly.

This is how I frame PoCs today:

• clear problem statement, measurable goal
• operational data from live systems, exceptions and dirt included
• test in the running process, not in a sandbox
• technical feasibility: ERP, data quality, infrastructure
• organisational hurdles: IT, data protection, works council
• quantified business case: savings, payback
• who builds, who runs it, what it costs

And if the result is NO-GO?The client keeps the technical solution architecture, the ROI model, the risk assessment. No empty sale. No "come back next month."

That turns the PoC from a technical experiment into a steering instrument for decision makers.

That is where serious AI integration in mid-sized companies begins.

Just been through a PoC?What was the moment when it became clear whether it holds or not?