Different responsibilities. One decision to make.

You need to know which process improves, who is responsible for it and how the result will be measured. A successful demo answers only part of that question.

The 30-day proof tests one candidate against an agreed measure. Its decision pack shows what worked, what remains unresolved and whether a production build is worth pursuing.

Your team needs a reliable way to choose the next action. More segments and another dashboard are useful only if they change what happens for the customer.

Start with one decision, such as prioritising contact or changing a lifecycle message. Test it against your own data and connect the result to a measure the team can use.

You need to know where the data moves, which dependencies are being added and who will support the work after handover.

The scope should make the architecture, access and deliverables explicit. The handover should include the agreed code or configuration, definitions, tests and documentation. The proof’s environment and any transfer work must be clear from the start.

The build cost is only part of the decision. Your team also needs to understand hosting, software licences, model usage, maintenance and the people required to run the result.

The proof provides a bounded first step. Its recommendation should set out the evidence for continuing and the costs or uncertainties still to resolve. Buying a product, changing the process or stopping remain valid outcomes.

You need a clear account of the information used, the actions taken and the people responsible. Keeping a system in the company’s environment is one part of that picture.

Check the purpose, permissions and review points before a live workflow is introduced. The documentation should distinguish what the system does from what a person approves, and record the dependencies that remain outside the business.