What you'll learn: how to design a proof of concept (POC) that can end cleanly, with written success and exit criteria and a timebox, how to answer four objections with evidence, and how to settle a stakeholder conflict.
At a glance
Figure 1. A three-week POC with a gate at the end
How to read this: criteria are written before any build starts, and the numbers decide the gate.
- One question, the riskiest part.
- Criteria are signed first.
- The timebox ends it.
Scenario
Composite scenario, not a real company. Lumen Industrial Supply, a fictional distributor of industrial equipment, has approved a three-week POC of its Order and Policy Assistant, tested by six of its 24 customer-operations agents (all numbers illustrative). A team lead wants real orders from the live order management system (OMS). The IT security lead wants test data only until a review ends.
What you will be able to do
- Write a one-page POC plan with criteria and a timebox.
- Choose go, stop or one extension from measured results.
- Answer four objections with evidence.
Prerequisites
- The solution architect cycle, where the POC is stage 3.
- RFP and SOW and MVP scope and acceptance criteria, which set the thresholds.
Core ideas
What a POC plan contains
| Element | Order and Policy Assistant (illustrative) |
|---|---|
| Question | Does it give correct, cited order and policy answers on Lumen's 62 documents and a test copy of the OMS? |
| Success | The acceptance criteria (AC) of the minimum viable product (MVP), run on the same 40-question test set (30 answerable, 10 unsupported): at least 27 of 30 answerable questions right, citing policy id and version, with 0 high-severity errors (a superseded or invented rule) (AC-1); all 9 version traps from the current version (AC-2); all 10 unsupported questions declined (AC-3); a held order reported as held (AC-4, P-HLD-05); the address rule applied (AC-5); 0 OMS write calls (AC-6). Also: no customer personal data in logs; median at or below 7 minutes against 9; model cost per contact at or below 0.0064 (placeholder EUR: 0.00495 times 1.3) |
| Exit | Stop if a superseded-version answer survives one fix round. Pause if OMS test access is late after week 1 |
| Timebox | Three weeks; one extension at most |
| Data and users | 62 documents; policy owner as data owner; six agents timing 4 contacts each (24 timings, like the baseline) |
The POC allows 7 minutes, not the pilot's 6: six agents are new to the tool and 24 timings show direction only.
Four objections
| Objection | Evidence-based response |
|---|---|
| "It will leak data." | Each agent's own sign-in through the gateway; logs without personal data. Where the hosted model processes data is open with the IT security lead (threat modelling) |
| "It will give wrong answers." | Test-set results, refusal rate, the old 14-day return rule tested, a citation to check |
| "We will be locked in." | The model gateway keeps the provider swappable; Lumen owns the policy text and the 40-question test set |
| "Agents will not use it." | Six agents' timings, how often they overrode an answer, visible sources |
At the customer: "How do you know it works?" is an objection in disguise: name the test set, the pass rate and the failures found.
Figure 2. A mid-POC request becomes a change request
How to read this: the sponsor decides from options that show the effects.
Worked example
Decision exercise. In week 2 the team lead asks for live orders; the IT security lead says test data only. Choose: (A) switch quietly; (B) refuse both; (C) log a change request with the effects and let the Head of Customer Operations decide.