An operations pilot should answer a business question, not simply fill a month with activity. Can this team deliver usable output? Are the instructions clear enough? What does the client need to provide? What happens when the work does not follow the normal path?
The first 30 days can provide a useful structure for answering those questions, but the calendar is not a guarantee of readiness. A simple workflow may need less time. A sensitive, seasonal or complex workflow may need much more. Treat the plan below as an illustrative sequence and adjust it to the actual risk.
Before the pilot begins, write down the decision it will support. If nobody can explain what evidence would justify expansion, the pilot is not yet designed well enough to start.
Set the decision criteria before the work arrives
Choose the outcomes you will evaluate: acceptable quality, turnaround, exception handling, communication and effort required from your own team. Define each one in terms that can be observed. “The team seems proactive” is harder to assess than “Blocked items are logged with an owner and a next action.”
Agree what would cause an immediate pause. An unauthorised disclosure, an incorrect high-impact action or an inability to trace completed work may need a different response from a minor formatting error. The appropriate pause rules should be approved by the relevant business and risk owners.
The ASQ explanation of Plan-Do-Check-Act describes testing change on a small scale and reviewing what was learned before taking wider action. Use that principle to make the pilot a controlled learning exercise rather than an early commitment to full volume.
Week one: establish a shared picture of the work
Use the first stage to map inputs, output requirements, access, decision boundaries and the route for questions. Ask the delivery team to explain the workflow back to you. The explanation should include exceptions, not just the standard sequence.
Create a small reference set of representative items. Include clear examples, incomplete requests and cases that require judgement. Have the process owner explain why each outcome is acceptable or unacceptable. This gives the team a working standard rather than a vague request to be careful.
Record a baseline for the existing process where reliable information is available. Note what the baseline excludes. If historical records do not distinguish waiting time from active processing, say so instead of treating the numbers as directly comparable with a new measurement.
Week two: run a controlled batch
Move a limited set of work through the complete process. Keep the volume small enough that both sides can inspect what happened. The exact batch size should depend on complexity and consequence, not on a generic target taken from another business.
Review completed items against the agreed acceptance rules. Record corrections with a reason and an owner. Separate missing source information from execution errors so the discussion does not become an argument over a single blended failure rate.
Check communication as carefully as output. Did the team raise a blocker while there was still time to act? Did the question contain enough context to answer? Did an agreed decision make its way back into the operating instructions? These behaviours are part of delivery, not administrative extras.
Week three: test variation and recovery
Introduce realistic variation only within the approved pilot boundary. A different request type, a less familiar source format or an absence backup can reveal whether the process depends too heavily on one person or one ideal input.
Test a safe recovery scenario. For example, pause a batch before completion and ask the team to identify what is finished, what is in progress and what should not be processed again. Do not create an actual customer disruption merely to test resilience.
Look at the handover between shifts or team members. A second operator should be able to continue from the recorded state without reconstructing a private conversation. If they cannot, improve the status model and notes before increasing throughput.
Week four: review evidence, not enthusiasm
Bring the pilot’s results into one decision document. Include what was processed, what was accepted, what was corrected, what remained blocked and how much attention the client team had to provide. Explain any changes to scope that affected the numbers.
Review individual high-impact incidents separately from averages. A generally good acceptance rate does not make a serious access failure irrelevant. Similarly, one unusual case should not automatically invalidate an otherwise workable process if the team handled it transparently and the risk is understood.
Ask both teams what remains difficult. The client may see reliable output while the delivery team is relying on unsustainable overtime or constant supervision. A useful review makes those dependencies visible before they become part of the normal arrangement.
Keep the scorecard small and interpretable
For an initial pilot, consider a scorecard with a handful of measures:
- Accepted output: Items approved without requiring correction.
- Rework: Items returned, grouped by the reason for correction.
- Turnaround: Time from the agreed starting event to accepted completion.
- Blocked work: Items waiting for information, access or a decision.
- Client effort: Time spent explaining, reviewing and resolving issues.
- Critical events: Incidents that triggered the agreed pause or escalation rules.
Define the denominator for every rate. If you count only reviewed items, say so. If the reviewed set is not representative, do not present its performance as the exact quality level of all work.
Add qualitative notes where they explain an important change. A short note about a new source format may be more useful than another chart. The scorecard should help people decide, not reward whoever can produce the most reporting.
Choose among expand, refine and stop
Expansion should specify what changes next: another request type, a higher volume or a longer operating window. Avoid expanding every dimension at once. Keeping one variable stable makes it easier to understand what caused any subsequent problem.
Refinement is a valid outcome. You may need a clearer field definition, better source data or a different approval route before another batch. Set a specific action and a new decision point rather than extending the pilot indefinitely.
Stopping can also be the right result. If the process does not fit the delivery model, the required access cannot be approved or the economics do not work, document the reason and return the unfinished work cleanly. Learning that early is useful, even if it is not the outcome everyone hoped for.
Make the next phase easier than the first
Before closing the pilot, consolidate the instructions. Remove obsolete versions, capture decisions and identify who owns future updates. Confirm where the work log, issue history and accepted examples will live.
Agree a short review rhythm for the next phase. It should be frequent enough to catch a changing pattern, but not so heavy that the team spends more time preparing reviews than improving the work. Focus each meeting on exceptions, decisions and completed actions.
Most importantly, preserve the ability to pause. Expansion should increase confidence, not remove oversight. The operating agreement needs a clear path for reducing volume or returning work if conditions change.
Use the handover checklist to prepare your inputs and owners. Then use the metrics guide to keep reporting focused on the decisions that actually determine whether the next stage is sensible.
Examples and suggested targets are illustrative, not Dhiti client results or contractual commitments. Adapt the approach to your process, risk and team.
