The 5-day Role Replication Sprint

The sprint follows work from input to decision to action. We look at what arrives, what the person checks, which systems they use and what happens when the request does not fit the usual pattern. That gives us a specific workflow to assess, instead of making a broad promise about what AI might do for the company.

A role is not just a list of clicks. It includes judgement, context and responsibility. We distinguish repeatable work from decisions that should remain with a person. The sprint may combine AI, RPA, Power Platform and an approval interface, but the technology follows the task. Five days describes the engagement, not a guaranteed time to automate every part of a job.

A suitable starting point might be invoice intake and exception routing, enquiry qualification and a draft reply, or approved order entry into a legacy system. These are examples, not fixed packages. We choose a bounded sequence with an owner, usable inputs and an outcome that can be checked. A whole finance function or support operation is not one first sprint.

Before starting, we need a process owner, agreed access and representative examples, preferably in a suitable test environment. Include difficult inputs as well as clean ones: duplicates, missing references and requests outside policy. We discuss data handling and permissions before using records. If those prerequisites are unavailable, we need to adjust the plan rather than pretend the calendar removes the constraint.

Day 1: map the workflow. We walk through how work actually gets done, including the spreadsheet, inbox or desktop screen that sits between formal systems. We agree the bounded scope, the expected outcome and the decisions reserved for a person. This is a working sequence, adapted to the access and process we agree before the sprint.

Day 2: define the rules and controls. We identify required fields, permitted actions, exception routes and what evidence a reviewer needs. We check the integration approach and agree test cases. A missing purchase order, uncertain extracted value or unavailable application should have an explicit outcome rather than being left for the model to improvise.

Day 3: build the bounded workflow. We connect the agreed steps and create any focused review screen needed to supervise them. The aim is to make the proposed approach tangible on the agreed systems and examples. We do not treat a successful demonstration with one clean input as proof that every live request can be handled safely.

Day 4: test and inspect. We run agreed examples, examine failures and check that exceptions go to the intended person. We look for duplicate actions, missing context and unclear recovery. The evidence should show limitations as well as successful paths. If an assumption does not hold, it needs to be visible in the decision about further work.

Day 5: review and decide. We walk through what was built, the observed behaviour and the outstanding constraints. You can assess whether to stop, refine the scope or proceed to a separately scoped Full Deployment. That later build covers production controls and rollout. Ongoing Support is the run stage, with monitoring and optimisation once live.

The intended output is a mapped workflow, a bounded implementation or demonstrable approach, agreed test evidence and a clear list of limitations and next decisions. The exact deliverables are confirmed in scoping. Where an access or integration constraint prevents an implementation, we make that explicit rather than presenting a mock-up as a working production system.

You should understand which steps can be routine, where a person intervenes and what further work would be required. There is no automatic commitment to Full Deployment. Pricing is discussed on a call because the systems, preparation and risk affect the scope. We do not promise savings, replacement headcount or a return on investment from a five-day engagement.

The sprint suits a team with recurring work, a clear owner and enough access to test a bounded approach. It is less useful when the process is changing constantly, rules are undocumented or the right people cannot participate. If the task is infrequent, a template or existing software feature may be the better answer.

If your priority is a full organisation-wide rollout with a fixed deadline, start with a broader scoping conversation. If the intended action requires legal, safety or financial judgement, keep the accountable decision with a person. The sprint helps assess a workflow; it does not remove the need for governance or careful deployment.