# A working prototype. And the evidence to decide what comes next. An illustrative report for a support-routing prototype. All records and outcomes below are fictional; they show how a delivery decision is documented. Explore a sample handover for a support-routing PoC, from the agreed workflow to the checks, open issues and final recommendation. This is the level of detail to agree before a sprint starts. **Acceptance report** · SUPPORT-POC / DEMO-01 Example recommendation: hold rollout until the two open items have evidence. ## 01. The agreed workflow The example team receives support messages and manually assigns each one to a queue. Its first question is whether a small tool can suggest the right queue while keeping the original message visible to a reviewer. Automatic replies and CRM updates are outside this PoC. The agreed slice starts with a synthetic message and ends with an accepted suggestion or an explicit manual-review state. The support lead owns the category rules. The engineer records the build and test inputs. A named buyer makes the acceptance decision against the written scope. Sample message → Category suggestion → Human review → Recorded decision ## 02. Inside the handover ### A working slice 01 / Prototype The agreed input, review queue and decision state, in the agreed demonstration environment. You should be able to follow one complete user journey and see where a person remains responsible. ### A repeatable demo 02 / Demo script Starting conditions, fixture IDs, steps to follow and the expected result. A colleague who missed the demo can repeat the same path instead of relying on a recording alone. ### The check record 03 / Acceptance report Each criterion connects an input to an expected result, an observed result and a status. The record identifies which build was reviewed and separates a failed check from an untested one. ### Open issues and decisions 04 / Risk register Known limitations, their effect on the next step, an owner and the evidence needed to close them. Unresolved issues remain visible even if the main demonstration looks successful. ### Code and operating notes 05 / Handover notes The agreed source handover, setup instructions, configuration names, dependencies and recovery steps. Ownership, licensing, access and deployment responsibilities follow the engagement agreement. ### A next-scope recommendation 06 / Decision memo A written recommendation to proceed, narrow the scope, gather more evidence or stop. Any proposed production work has its own estimate and acceptance conditions; the PoC does not silently become a rollout. ## 03. The acceptance record The four entries below are filled-in examples, not customer test results. A useful report preserves the difficult case and the missing evidence alongside the successful checks. Open each entry to inspect the input and reasoning. ### DEMO-01: A clear billing request **Matches expectation** - **Input:** “Please send me a copy of my last invoice.” The example category list contains Billing and Account access. - **Expected behavior:** Suggest Billing, show the original message and require the reviewer to confirm the result. - **Review notes:** The example record shows Billing with the message preserved and the decision still awaiting review. ### DEMO-02: A request with two possible owners **Revision needed** - **Input:** “I cannot sign in to download my invoice.” Both example categories could apply. - **Expected behavior:** Keep the category undecided and send the message to manual review, according to the agreed ambiguity rule. - **Review notes:** The example record selected Billing without flagging the ambiguity. The rule needs a revision and another check. ### DEMO-03: An empty submission **Matches expectation** - **Input:** A message containing spaces only, submitted through the same input surface. - **Expected behavior:** Show a useful validation message and make no categorization request. Let the user correct the input. - **Review notes:** The example record shows validation beside the field and no new item in the review queue. ### DEMO-04: The provider is unavailable **Not checked** - **Input:** A valid message while the categorization provider is unreachable. - **Expected behavior:** Preserve the input, show the failure and offer the agreed retry or manual-review path without duplicating work. - **Review notes:** No evidence is attached in this example. An untested recovery path cannot be counted as a successful check. ## 04. Two weeks, four checkpoints This is an illustrative sequence for a narrow two-week PoC. Actual dates depend on an agreed scope, available inputs and review access. Each checkpoint produces something the buyer can inspect. ### Before day 1: Agree the question Confirm the workflow, category rules, synthetic or approved data, exclusions and acceptance checks. Name the reviewer and agree the demo environment before implementation. ### End of week 1: Review the first path Walk through input, suggestion and human review. Record feedback against the scope and identify missing data or access while there is time to respond. ### Week 2: Exercise the edges Review ambiguous and invalid inputs and the agreed failure cases. Record observations against a build, then repeat affected checks after changes. ### Final review: Make the decision Repeat the demo, review open items and confirm the handover. Record acceptance or remaining conditions and decide whether another scoped step is justified. ## 05. The decision and open items ### Example decision: hold rollout The happy path is visible, but this example has an incorrect ambiguity decision and an untested recovery path. The report recommends a bounded follow-up review. It does not establish production readiness, business savings or accuracy on real customer traffic. ### Resolve category overlap Agree which overlapping requests need manual review, revise the behavior and repeat DEMO-02 on the next identified build before acceptance. **Action owner:** Support lead + engineer ### Attach recovery evidence Exercise the unavailable-provider case in the agreed test environment. Record the retained input, visible failure and recovery result before considering rollout. **Action owner:** Engineer + buyer reviewer ## 06. Review it with your team 1. Ask a colleague to run the demo using only the setup notes and fixture IDs. Missing steps become handover actions while the people who built it are still available. 2. Check that every accepted criterion points to a result for the same build. Keep revisions and untested cases visible; a polished walkthrough is only one part of the review. 3. Confirm repository access, configuration ownership and the person responsible for operating the next environment. Keep credentials out of the report and transfer access through the agreed channel. 4. Record the decision in your own approval process. The example Markdown is a reusable report format, not source code, a hosted prototype or a complete production handover. ## Questions ### Is this a real customer delivery? No. The support workflow, fixture messages and observations are fictional and demonstrate the report format. The linked owned-product case study is a separate kind of evidence. ### Does a two-week PoC include production rollout? Only work explicitly included in the written scope is included. Production access, hardening, monitoring, deployment and ongoing support must have named responsibilities and agreed acceptance conditions. ### What happens if a criterion fails? Record the observation, its effect and the owner of the next action. The buyer decides acceptance against the agreement. A new request or changed scope is handled explicitly rather than disappearing into the issue list. ### Can we use our own review format? Yes. Bring your acceptance template, procurement requirements and review process before scoping. The useful contract is the connection between the criterion, the evidence and the decision. ## Your own acceptance record ### Build and environment [ ] ### Scope and criterion [ ] ### Fixture and steps [ ] ### Expected result [ ] ### Observed result and evidence location [ ] ### Status and unresolved issue [ ] ### Action owner and review date [ ] ### Buyer decision [ ] [Discuss the next scope](https://urbanodx.com/contact/?package=poc&from=service_details&utm_source=urbanodx&utm_medium=sample&utm_campaign=202609-deliverables)