From PoC to Impact: the PoC implementation playbook

Implementation is decided long before go-live

Across thousands of PoCs in the GlassDollar database, 59% of completed PoCs go on to be implemented. Those odds are better than most innovation teams expect, and they aren't evenly spread. The PoCs that make it into daily operations were prepared for implementation at every stage of the process, starting with the moment the pain point was first written down.

A PoC answers one question: does this solution solve our problem? Implementation answers a harder one: can we make it part of how we work, at scale, with real data and real users? Only the second answer shows up in the P&L. Across Venture Clienting programs, an implemented solution delivers around €2M in measured business impact on average, which is why the share of PoCs that reach implementation is the number that decides whether a program pays off. The ROI model in Venture Clienting Explained shows the full calculation.

This playbook is written for Venture Client Unit (VCU) leads, the people who own the process from the first pain point to the rollout. It's equally useful for the people they work with: pain point owners, who own the problem and the budget; IT, security and procurement, who decide how fast a solution can go live; and startups, who want their PoC to turn into a customer.

Five findings

1. Implementation is where the value is. A successful PoC is a cost until the solution runs in daily operations. Programs that report PoC counts instead of implementations struggle to defend their budget.
2. Implementation is decided before the PoC starts. The strongest predictors are in place early: a stakeholder who holds the budget, a senior sponsor, a clear path to rollout and post-PoC pricing agreed upfront.
3. The best candidates are process improvements the business asked for. 67% of implemented solutions improve an internal process, and 85% started with a business unit's own request.
4. Delays after the PoC are predictable. IT security reviews, competing IT priorities, production data and change management cause most of them. All four can be prepared for during the PoC.
5. Scaling needs its own plan and budget. A successful first rollout doesn't automatically reach the rest of the organization. The most avoidable reason a proven solution stops growing is that nobody funded the next phase.

The full process at a glance

Venture Clienting runs in eight stages, from activating demand in the business to scaling a proven solution across the organization. Implementation is the seventh. The first six stages are where its odds are set, which is why the rest of this playbook follows the process in order rather than starting at the go/no-go meeting.

Read the exhibit from left to right, but notice the time scale: the stages before the PoC take weeks, the PoC itself 8–12 weeks, and implementation 6–12 months. Most of the effort sits on the right, while most of the leverage sits on the left. A missing budget owner costs a phone call to fix in the Scope stage and a stalled rollout to fix in the Implement stage.

What implemented solutions have in common

Two patterns stand out when you look at the PoCs that made it into daily operations. Most of them improve how the company works rather than what it sells, and most of them started with a request from a business unit rather than an idea from the innovation team.

The reasons are practical. An internal process has an owner, a baseline that is already measured and a short path to rollout: the team that feels the pain is usually the team that will use the tool. Product innovation involves more stakeholders, longer development cycles and customer-facing risk. It's worth pursuing, and when it works the return is often higher, but it needs more preparation and a longer runway. A pain point that the business brings to the VCU comes with urgency and ownership built in. An idea pushed by the VCU has to find both first.

The strongest programs are also selective. Roughly one in five accepted pain points goes on to a PoC. That filter isn't a loss: it concentrates the VCU's time, the business unit's attention and the PoC budget on the cases most likely to make it into daily operations. The practical rule that follows: put process pain points requested by the business first, and pursue product ideas and push topics knowingly, with the extra preparation they need.

Each implementation makes the next one easier. Every rollout proves value to the business units, which brings in more requests and better pain points.

Implementations are also the VCU's best internal marketing. Boards increasingly want results rather than experiments, and purely exploratory tests get less room in tight budgets. An implemented solution with measured impact is the strongest answer to both. BSH Startup Kitchen, for example, has run more than 60 PoCs, implemented 40% of them and measured more than €15M in net cost savings. Numbers of that kind are what secure the next budget.

Implementation starts at Activate

By the time a startup starts testing, three things that decide implementation are already fixed: who owns the problem, which problem it is, and on what terms the company will buy if the PoC succeeds. Each of the five stages before the PoC has one implementation job.

Qualify the pain point before you source

Sourcing is expensive in time and attention, for the VCU and for the startups it contacts. Before it starts, every pain point should pass four questions, and all four need a clear yes:

• Real need. Is there a clearly defined problem, not a symptom? "We need a better analytics tool" is a symptom; "we can't see customer churn early enough to act" is a need.
• Urgency. Is there a deadline or a consequence if nothing happens? Nice-to-haves don't get rolled out.
• Authority. Can the person behind it approve a PoC and commit their team's time, or do they need someone else's sign-off?
• Budget. Is there money for the PoC, and a realistic path to money for implementation?

A lead that fails one of these rarely turns into an implementation, however well the PoC goes. Leads also don't stay qualified: stakeholders move, budgets disappear and urgency fades. Re-check open leads every six weeks and keep a short log of why a lead was dropped. Patterns in that log are useful. If leads keep dying for lack of authority, for example, that's a sign to source pain points from department heads rather than individual contributors. The full needs assessment and kill criteria are covered in Part 4 of Venture Clienting Explained.

The person who owns the PoC matters most

No single factor influences implementation as much as the stakeholder who owns the PoC. The VCU owns the process; the business owns the problem, the decision and the rollout. If that owner can't fund or drive implementation, a positive result has nowhere to go.

The last point deserves a sentence of its own. Long-horizon, exploratory topics have their place in a portfolio, but they shouldn't be measured against implementation. Judge them on what they teach the organization, and keep the implementation rate as the yardstick for core business problems.

Write the business case before you source

A high-level business case at the Scope stage doesn't need to be precise. Its job is to rank pain points and to make the owner say out loud what success would be worth. BSH Startup Kitchen calculates a simple business case for every incoming request, with high-level assumptions, before any startup is sourced, and then refines it as the project moves through sourcing, assessment, purchasing and the PoC. By the go/no-go meeting, the business case has been tested against four stages of reality instead of being written the night before.

A guided intake that asks for owner, budget, sponsor and expected impact with every pain point makes all of this visible from day one, and saves the VCU weeks of chasing information later.

Enterprise-ready beats impressive

A startup doesn't need to be large to be a good candidate for implementation. It needs completed PoCs with other corporate customers, references you can actually call, and a dedicated team that isn't juggling twenty other pilots. A four-person startup with three successful corporate PoCs is a safer bet than a thirty-person startup with none. During assessment, ask how the startup handles security reviews, integration and support at scale: the answers predict how smooth the rollout will be.

Ask for two prices, not one

Before the PoC starts, ask every startup for two numbers: the PoC price and the indicative annual subscription. A solution that costs €20k to test but €400k a year to run may not survive the business case, and it's far better to know that before the test than after a successful one. Agreeing post-PoC pricing and contract terms in the Purchase stage also means a positive result can be bought immediately, at a price the business case already reflects. Many corporates also agree that the PoC fee is credited against the first year's subscription if the PoC succeeds, which aligns incentives on both sides.

A PoC built for implementation, and a decision that hands over

A PoC built for implementation tests the solution under the conditions it will face in daily operations. That makes the result more convincing, and it moves the hardest questions into the PoC, where they're cheaper to answer than during rollout.

This goes further than the lean PoC many programs start with. Early on, keeping PoCs to four to eight weeks in a sandbox, without integration or personal data, is the right way to build credibility quickly (see PoC scoping in Venture Clienting Explained). Once the goal is implementation rather than proof, the trade-off shifts: a few extra weeks of testing under real conditions save months of surprises after the decision.

Six design choices that matter most

1. Success KPIs agreed with the budget owner. The person who pays for implementation defines what success means, so a positive result leads straight to a decision instead of a second round of persuasion.
2. 8–12 weeks, with a fixed go/no-go date. The date goes into the calendar at kickoff. It prevents the open-ended pilot that quietly fades away, and it gives the sponsor a moment to plan around.
3. IT, security and procurement involved from day one. The security review, architecture questions and contract terms run in parallel with the test rather than after it.
4. Real data, real environment, real users. The result shows how the solution performs in production, and data and integration issues surface while there is still time to fix them.
5. Post-PoC pricing and contract terms agreed upfront. A positive result can be bought immediately.
6. Regular sponsor check-ins and a pre-agreed implementation plan. The sponsor stays engaged, and the rollout can start the week after the decision.

Real data has a consequence that's easy to miss: data protection, legal and, where employee data is involved, the works council need to be in from the start. Clarify their requirements in the Purchase stage so they don't delay the start of the test. The internal partners you need from day one are covered in Part 3 of Venture Clienting Explained.

Three jobs during the test

The VCU doesn't run the PoC day to day; the startup and the business unit do. The VCU's role is to keep three things on track:

• Manage the pilot. Validate the agreed hypotheses. Hold short check-ins every two weeks with the startup and the business unit, handle issues the moment they surface, and collect success-metric data from week three onward rather than saving it for the end.
• Prove the business impact. Keep the business case current with real numbers as they come in, so that by the end it rests on measured results rather than the startup's claims.
• Prepare implementation. Agree a long-term plan with a clear use case: who will use the solution, how it connects to existing systems, what the first rollout phase looks like and who owns each workstream.

When startup, business unit and VCU work from one shared view of milestones, success metrics and open issues, check-ins stay short and nothing gets lost between meetings. Programs like MAHLE Piloting run this coordination across several business units from one structured PoC flow.

Define success metrics precisely

Each success metric needs four parts: what is measured, how it is measured, the target and the timing. Vague goals such as "improved efficiency" turn the go/no-go decision into a matter of opinion, and opinions favor the status quo.

“Deal logging time falls from 40% of the sales team's week to 10%, measured by a time audit at the start and end of the PoC.”

The go/no-go decision is a handover

The go/no-go meeting is where the PoC ends and implementation begins. If the Test stage did its job, the meeting confirms a decision the evidence already supports and hands clear ownership to the business unit. Three checks belong before the meeting, not in it.

1. Scope completion. Did the startup deliver everything agreed, including documentation and a clear support model? A partial solution can't be properly validated.
2. Success metrics. Compare each result with its target, and understand why it landed where it did.
3. Implementation feasibility. Integration effort, data migration, training, timeline to value and a revised cost estimate, all reflected in the updated business case.

A small miss, such as 75% instead of 80% uptake, often just reflects real-world complexity and can still support implementation. A large miss on the metric that carries the business case, such as a 40% rather than 50% time reduction, is a more serious signal. Treat the decision as a real one with three possible outcomes:

A partial success isn't an automatic pass, and momentum shouldn't make the call. If you park a lead, give the startup specific feedback and leave the door open: founders talk to each other, and a fair "no" protects your reputation among startups.

Leave the meeting with four names and a budget

An implement decision should end with a named owner for each of the four workstreams, and with money attached:

• Business sponsorship and budget: usually the pain point owner, backed by their sponsor.
• IT coordination: one IT project lead for security clearance, integration and data.
• Startup relationship: usually the VCU, which knows the startup best.
• Change leadership: someone in the business unit who drives training and uptake.

Agree the budget for the first rollout phase and the path to budget for the phases after it. A first phase that succeeds without funding for the next one is one of the most common reasons a promising solution stops growing.

From decision to daily operations

Implementation is a different project from the PoC, not a longer version of it. Teams that expect it to run at PoC speed are almost always disappointed; teams that plan for six to twelve months, and say so at the go/no-go meeting, keep their credibility when it takes that long.

What changes after the PoC

Three shifts define implementation. Each brings new people, new requirements and new timelines into the project.

Four predictable delays, and how to get ahead of them

Implementation delays look different from company to company, but their causes are remarkably consistent. Almost all of them come back to four sources.

Make IT a partner, not a gate

In programs that struggle with speed, IT is cited as the blocker. In programs that move at startup speed, IT is a partner. The difference is almost always when the VCU involved IT, not how willing IT was. Brief IT during PoC planning rather than after signing, name one IT contact who attends the kickoff and the closeout, and if IT wasn't involved early, run a structured readiness workshop where the startup presents its security posture and integration plan directly.

It also helps to position the solution as part of IT's own technology scouting. IT teams are under pressure to find modern tools too, and a startup the business has already tested under real conditions is a ready-made answer rather than another request in the queue.

IT's questions are consistent and predictable, which means startups can prepare for them:

• Security: data storage, encryption, access controls and breach response, ideally backed by SOC 2 or ISO 27001.
• Integration: API stability, documentation and the authentication approach.
• Support and maintenance: defined SLAs and an incident process.
• Scalability: load testing and honesty about limits.
• Vendor reliability: funding history, references, roadmap and team.

Startups that prepare for this scrutiny move through implementation two to three times faster than those that don't.

Make the business case hard to deprioritize

A business case built on a startup's marketing claims is easy to push down the list. One built on measured PoC results, signed off by the business unit, is not. Payback period and net first-year benefit at the top of one page make the project hard to deprioritize when IT capacity gets tight.

Stay conservative when you scale PoC results up. If a startup claims a 60% improvement, model 25% company-wide, and apply an explicit risk adjustment: 70% confidence in the PoC result times 50% confidence in full-scale realization means planning with about 35% of the gross benefit. A business case that survives those haircuts is one a CFO can sign. The five-step business case method is described in Part 5 of Venture Clienting Explained.

Move the contract from PoC to production

The PoC agreement becomes a subscription or enterprise contract with a new purchase order, support SLAs and data and IP terms. If pricing was agreed upfront, this step confirms terms rather than reopening them. Budget four to eight weeks anyway, because finance approvals above the PoC threshold take their own time. The message to procurement is that selection is already done: their job is to turn the chosen startup's offer into a contract on good terms, not to re-run a competitive tender. Non-monetary value, such as a case study, a reference call or structured product feedback, is often worth a 10–20% discount and is something startups value more than a straight price cut.

Roll out in phases

Don't roll out to the whole organization at once. Each phase below is a decision point, not an automatic next step:

1. Initial team. The pain point owner's own team, typically 20–50 people. They're motivated, they already know the solution and they want the result, which makes them the fastest place to prove value in daily operations. Move on when the day-90 thresholds are met and open issues are known.
2. Adjacent teams. Teams with the same problem or a shared process. Move on when the rollout playbook works without the VCU in the room.
3. Wider organization. Other business units, locations and functions. Move on when budget for scaling is agreed and the support model is in place.

Make the change stick

A deployed solution nobody uses delivers no return. Implementations fail more often for organizational reasons than technical ones.

Stalled implementations typically plateau at 30–40% usage, well short of the 80% or more needed for real impact. Five things decide whether the change sticks:

• Hands-on training close to go-live, in small groups, with recordings for later.
• Process documentation that shows the old and new workflow side by side, where users will actually look for it.
• Communication that increases rather than fades at go-live and continues for 90 days.
• Two to four champions per team, ideally people who took part in the PoC, given visibility and a role in shaping the rollout.
• A senior leader who visibly uses the tool. When that happens, uptake runs 20–30% higher.

The day-90 check

Day 90 is the clearest early signal of whether an implementation is on track. Measure three thresholds for the target users of each phase:

Implementations that reach these thresholds usually keep climbing towards 75–85% usage. Those that fall clearly short need active intervention: refresher training, a fix to a workflow that still favors the old way, or a visible push from the sponsor. Monitoring business impact against the PoC baseline then turns usage into the number that matters: the value in euros, reported to the sponsor.

Scaling, and four implementation stories

A solution that works for one team has proven its value once. Scaling multiplies that value, but it rarely happens on its own. It needs its own owner, its own budget and a deliberate plan for where the solution goes next.

Six directions to scale

Pick the next direction based on where the same pain point exists, where a willing owner is ready, and where budget can be found. Every scaling step should be a decision with its own business case, built on the measured results of the step before. The Brainbox AI story below shows what happens when that budget question is left open.

Measure the program by implementations

Scaling individual solutions and scaling the program go together, and both depend on reporting the right numbers. The PoC-to-implementation rate is the core indicator: across mature programs the benchmark is 50–60%. Below 40% usually points to weak qualification or scoping; above 70% often means PoCs are scoped too conservatively. Business impact per implementation, calculated conservatively against company data, turns that rate into money. Reported quarterly to the sponsor, these two numbers make the case for the next budget far better than a count of PoCs. The full KPI set and reporting cadence are in Part 5 of Venture Clienting Explained, and the benchmark data behind them in the Impact of Venture Clienting study.

From central queue to self-service

As programs mature, the way they scale changes. In many VCUs today, every request passes through a small central team, which becomes a bottleneck as demand grows. Leading programs are moving towards a model where business units submit, search and refine pain points themselves through a guided intake with clear quality gates. Business units then scout and reach out to startups directly for tactical needs, while the VCU orchestrates strategic, cross-business-unit projects and keeps implementation standards high.

Mature programs also tend to cut the number of active scoutings and PoCs, keeping only those with the highest odds and the highest impact. Fewer, better-prepared PoCs lead to more implementations.

Four implementation stories

Three of these cases were implemented, and one stopped after a successful PoC. Each shows one of the patterns described in this playbook.

Pactum: AI-driven supplier negotiations

Implemented · Procurement

A large number of small-volume purchases, each under €20,000, weren't being negotiated efficiently. Pactum's negotiation bot negotiates and closes these smaller supplier contracts on its own. The project was owned by the Head of Procurement.

$0.5Msavings in the first 12 months

80%of deals negotiated successfully

5%average discount

Pattern: a process innovation with one clear owner and a baseline that was easy to measure.

remberg: smart maintenance in production

Implemented · Production

Unplanned machine downtime and inefficient maintenance processes caused production losses, high maintenance costs and strain on staff. remberg's asset platform and AI copilot plan maintenance work automatically, digitize operating processes and reduce downtime.

−34%unplanned downtime

−23%maintenance costs

+18%asset availability

Pattern: impact shown in operational KPIs that production already steers by.

RIIICO: faster planning of new production lines

Implemented · Manufacturing

Factories have to adapt quickly to new requirements, but planning new line set-ups and automation is slow and expensive. RIIICO uses AI to turn real factories into usable 3D models for simulating conversions, testing layouts and planning automation.

−80%3D modeling time

+30%faster robot programming

−15%project costs

Pattern: a clear before-and-after on time and cost.

Brainbox AI: a successful PoC that didn't scale

Not scaled · Energy

Rising energy costs and inefficient HVAC systems in manufacturing sites led to higher emissions and missed sustainability goals. Brainbox AI adjusts heating, ventilation and air conditioning in real time to cut energy use, and integrates with existing building infrastructure. At the initial plant it delivered 15% energy savings in the first twelve months. It went no further: there was no budget for scaling to the company's other buildings.

−15%energy use at the first plant

Lesson: proven value isn't enough on its own. Agree who will fund the next phases before the first one succeeds.

More customer stories, including how BSH measured more than €15M in impact and how Infineon launched its program in four months, are in the case study library.

Summary: what decides implementation