# Sample pilot delivery plan
XP Solutions · AI & operations consultancy

Illustrative working document for a supplier-invoice pilot. This is an example of delivery planning, not a client engagement, contract, quote, or achieved outcome. Scope, fees, permissions, ownership, and support are agreed in the actual proposal.

## 1. The decision to support
Determine whether controlled invoice intake and validation can reduce total handling effort while meeting agreed quality, control, and reliability thresholds. A useful outcome may be to proceed, revise the scope, or stop.

## 2. Scope
One agreed invoice intake channel, one supplier group, and one finance-system boundary. Prepare a reviewable draft and its source evidence. Validate required fields, purchase-order matching, currency, amount, and duplicate references. Route incomplete or conflicting records to a named owner.

Human approval remains required for consequential actions. Start with representative test data and read access. Enable production writes only through a separately accepted release gate.

### Exclusions to confirm
Payment execution, changes to supplier bank details, expansion to other document types or teams, and unscoped data cleanup. A new integration, action, or use case follows the agreed change process.

## 3. Inputs and responsibilities

| Work item | Consulting delivery | Client contribution or decision |
|---|---|---|
| Baseline | Define measures and analyze representative work | Process owner, workload records, current handling and review effort |
| System boundary | Propose record ownership, field mapping, and event flow | Authoritative systems, technical contacts, API and environment constraints |
| Data and access | Specify minimum access and data requirements | Approve access, hosting, provider, retention, and confidentiality conditions |
| Evaluation | Prepare test cases and evidence collection | Representative examples and agreed acceptance thresholds |
| Release | Document checks, fallback, and proposed rollout | Named release approver and production-change authorization |
| Handover | Prepare architecture notes, runbook, and training material | Operating owner, support arrangement, and handover acceptance |

Roles are agreed for the actual project. Third-party vendors and internal technical teams may hold additional responsibilities.

## 4. Delivery gates

### Gate A — Understand
Capture the current workflow, systems, exception paths, handling time, and decision ownership. Identify assumptions and missing evidence. Agree the bounded pilot and its exclusions.

Decision: is the workflow sufficiently understood and feasible to prototype?

### Gate B — Evaluate
Test representative normal and exception cases. Include missing purchase orders, amount and currency mismatches, duplicate events, denied permissions, and unavailable systems. Evaluate extraction separately from deterministic validation if AI extraction is part of the real scope.

Decision: do the proposed workflow and controls meet the agreed acceptance criteria?

### Gate C — Release deliberately
Review the evidence, permissions, failure handling, reconciliation, and manual fallback. Confirm the named operating and release owners. Agree a controlled rollout and an observation period appropriate to the business.

Decision: approve the release, request changes, or retain the manual path.

### Gate D — Hand over
Review the architecture, configuration, account access, operating runbook, monitoring, recovery procedure, and training. Record what support is included and how changes are requested.

Decision: can the agreed operating owner run and maintain the delivered scope?

## 5. Measures to agree
- Quality: field-level accuracy against representative examples, including difficult formats.
- Control: required approvals cannot be bypassed; prohibited actions remain unavailable.
- Reliability: duplicate handling, retries, partial failures, reconciliation, and recovery work as specified.
- Value: total handling and review effort measured against the original baseline.
- Cost: delivery, software, model usage, hosting, support, and ongoing review included in the business case.

Targets and sample size depend on the actual process and its consequences. The planning estimate of recovered capacity is not a guarantee of cash savings.

## 6. Handover inventory
- Current and proposed process maps.
- System boundaries, record ownership, and field mappings.
- Evaluation cases and results, including unresolved limitations.
- Access inventory and credential ownership procedure.
- Exception queue, recovery steps, reconciliation, and manual fallback.
- Configuration and deployment documentation for the agreed scope.
- Monitoring responsibilities, usage limits, and review cadence.
- Team training and separately agreed support coverage.

## 7. Items to resolve before commissioning
Delivery fee and payment arrangements; third-party running costs; deliverable and account ownership; confidentiality and data processing; change approvals; dependencies; acceptance decision rights; operating support; and any client procurement requirements.

These items need an actual engagement agreement. This example does not establish commercial or contractual terms.

Inspect the demonstration: https://xpsolutions.ai/resources/workflow-sandbox
Review the diagnostic: https://xpsolutions.ai/resources/sample-workflow-audit
Discuss your workflow: hello@xpsolutions.org