Inside a two-week delivery
A working prototype. And the evidence to decide what comes next.
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.
Markdown · editable · no signup
SUPPORT-POC / DEMO-01
Acceptance report
Ready for the next decision
Example recommendation: hold rollout until the two open items have evidence.
An illustrative report for a support-routing prototype. All records and outcomes below are fictional; they show how a delivery decision is documented.
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.
- 01Sample message
- 02Category suggestion
- 03Human review
- 04Recorded decision
Inside the handover
File labels below describe the example bundle. This download is the sample document, not a software repository.
01 / Prototype
A working slice
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.
02 / Demo script
A repeatable demo
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.
03 / Acceptance report
The check record
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.
04 / Risk register
Open issues and decisions
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.
05 / Handover notes
Code and operating notes
The agreed source handover, setup instructions, configuration names, dependencies and recovery steps. Ownership, licensing, access and deployment responsibilities follow the engagement agreement.
06 / Decision memo
A next-scope recommendation
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.
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-01A clear billing requestMatches 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-02A request with two possible ownersRevision 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-03An empty submissionMatches 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-04The provider is unavailableNot 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.
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.
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 ownerSupport 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 ownerEngineer + buyer reviewer
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.
FAQ
Before you use this sample
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.
Urbano DX
Bring the same clarity to your project.
Share the workflow, the evidence you already have and the decision you need to make. We can define a first scope around them.