A process map shows how work moves between people and systems. To turn it into an automation scope, decide which part the software may perform, which rules it must follow and how you will check the result. Name the person who owns those decisions and what happens when the work cannot continue.
That matters when a task looks straightforward on paper. "Check the timesheet and prepare it for payroll" can hide missing approvals, conflicting records and a decision somebody makes from memory. Those gaps become decisions a builder needs before the work can be automated.
The aim here is a usable brief for one process. The accompanying automation scope worksheet gives you somewhere to record the map, baseline and proposed scope. You can use it with your own team or a supplier.
Choose the part worth changing
Start with a specific outcome. "Prepare an approved timesheet for payroll review" gives you a boundary. "Automate finance" leaves too many different jobs inside it.
Ask what makes this work worth examining: repeated handling, delayed decisions, preventable mistakes or a deadline that is difficult to meet. Then ask whether the business can provide usable inputs, agreed rules and authorised access to the systems involved.
Look at the alternatives before commissioning a build. An existing system may already have a suitable import or approval feature. Changing a form could remove the need to chase missing information. Some decisions should stay with a person, with software preparing the evidence around them.
Frequency helps you assess the effort, but it is only part of the decision. A rare task can still matter because an error has serious consequences. A frequent task can be a poor candidate while its rules or source data remain unsettled.
The useful outcome may be to stop or change the proposed project. GOV.UK's discovery guidance explicitly allows that outcome for public services. For a business considering automation, the same question is worth asking: does the evidence justify proceeding? GOV.UK: how discovery works.
Map what people actually do
Walk through the work with the people who perform it. Ask for ordinary cases and cases that caused difficulty. Use fictional or suitably redacted records when sharing the map beyond the people authorised to see the originals.
You can begin with paper and plain action labels. The Improvement Service's process-mapping guidance describes workshops involving the relevant staff, with enough detail to expose responsibilities, problems and remedial work. It separates the current process from proposed improvements. Improvement Service: process mapping.
For each step, record who acts, what they receive, which system they use and what they produce. Include the handoff to the next person and any wait before work resumes. At a decision, write the question being answered and identify where the rule comes from.
Keep these distinctions visible:
| Record | Question it answers |
|---|---|
| Current practice | What does the person do today, including workarounds? |
| Approved rule | What should happen, and who can resolve a disagreement? |
| Proposed behaviour | What will the automation be allowed to do? |
The distinction stops an outdated spreadsheet or an informal shortcut becoming the rule by accident. Check important decisions against approved records and the responsible owner's instructions.
Follow the awkward branches too. What happens to a missing identifier, an incorrect value, a duplicate submission or an item arriving after the deadline? What if the record exists but cannot be accessed? Put the human decision and its owner on the map.
Use a separate procedure if people need detailed instructions for a step. The map explains the flow; the scope records the proposed boundary and behaviour. Neither needs to contain the entire technical design.
Record a baseline you can use later
Choose your measures before changing the process. For this guide, handling time means active human effort. Elapsed time means the time between the chosen start and finish, including waits. Reducing data entry may release staff time while an approval delay remains.
Record the number of items, handling time, elapsed time, exceptions, rework and incomplete cases where you can observe them. Define the measures clearly. An exception count might mean affected records or separate error events; those can produce different figures. Note whether rework time is already included in handling time so it is not counted twice.
Choose an observation period that reflects the work. Include month-end if that is when the process becomes difficult. Record seasonal or unusual cases separately where your sample misses them. There is no fixed observation period in this worksheet: write down the dates, sample, method and gaps.
Keep observations separate from estimates. If someone estimates how long a task takes, label it as an estimate and decide whether it needs checking. A later comparison should use the same boundaries and definitions, while noting changes in volume or case complexity.
Time released is not automatically money removed from the budget. HM Treasury's efficiency framework distinguishes benefits that reduce spending from benefits that release capacity. That is public-sector reporting guidance, but the distinction is useful here. Include build, running, support and exception-handling costs in a financial assessment. Government Efficiency Framework.
Our repetitive admin calculator can explore your assumptions. Its output is indicative; a measured baseline still needs evidence from your operation.
Turn the map into a written scope
Choose the part of the map you intend to automate and describe its finish as a checkable state. A draft record prepared for approval is a different finish from an approved payment or a message sent to a customer.
Use the following headings to write the scope. This is a practical planning format, not a claim that every project needs the same specification.
| Scope heading | Decision to record |
|---|---|
| Purpose and owner | The outcome sought and the person authorised to settle rules and accept the work. |
| Start, finish and exclusions | The triggering event, the final state and similar-looking work that is deliberately outside the scope. |
| Inputs and record ownership | Required fields, their authoritative sources and what happens when values disagree. |
| Systems and permitted actions | Where information may be read or changed, and who authorises that access. |
| Rules and human decisions | Conditions the software can check, their source and decisions reserved for a person. |
| Acceptance and recovery | Expected results, failure tests, duplicate handling and the route for unfinished work. |
| Continuing responsibility | Who monitors the work, resolves exceptions, maintains access and approves changes. |
Be specific about record ownership. The contact system may supply a customer identifier while the finance system supplies payment status. "Use the latest value" is incomplete unless you know which source may change it and what "latest" means.
Separate permission to read from permission to change something. A workflow preparing a draft does not need authority to approve it. NCSC guidance recommends defining who or what can access particular systems, data and functions, under which conditions. Record the access needed and its owner in the worksheet; keep passwords and access tokens out of it. NCSC: identity and access management.
List unresolved technical questions. Can the target system create a draft? Is there a supported interface? How will a partly completed update be identified? A supplier should investigate those questions before treating the brief as a commitment to build.
The worksheet starts that conversation. Detailed design, delivery terms and any changes to scope still need to be agreed for the actual engagement.
Write the acceptance checks before the build
Acceptance checks describe the outcomes you need to see before accepting the work. GOV.UK's user-story guidance uses them as a checklist of outcomes showing that a service meets the need. The same approach can make an automation brief testable. GOV.UK: acceptance criteria.
Start with the following cases, then add those specific to your process. For each, name the input, expected result, evidence to inspect and person who accepts it. Use test records in an environment agreed for testing, with permission for the actions involved.
| Test case | What you should be able to verify |
|---|---|
| Valid input | The correct fields and state reach the intended record, with a traceable source. |
| Missing, invalid or late input | The agreed rule is followed; a required value is not invented and the reason for holding or rejecting the item is visible. |
| Duplicate submission | Repeating the same event does not create a second business action. A corrected version follows the separately agreed change rule. |
| Missing permission | No unauthorised change occurs; the problem reaches the person responsible for access. |
| Unavailable system | Unfinished work remains identifiable and the agreed retry, pause or escalation policy is followed. |
| Interrupted update | Completed changes are identified before a retry or manual action is allowed. |
| Unsafe or unexpected case | Processing stops at the agreed boundary and a named person receives enough context to decide what happens next. |
Check the business records as well as the run status. Reconciliation means comparing what should have been processed with what was actually created or changed. Use record identifiers and relevant values; matching totals alone can hide a missing item and an unwanted duplicate.
A timeout deserves particular care. The target system may have accepted an update even though the confirmation never arrived. Repeating the action can then create a duplicate. Microsoft's retry guidance describes this failure explicitly. Microsoft: retry pattern.
Before someone repeats the work manually, establish what already happened and prevent a competing automatic retry. Agree how the item is released for recovery. Some failures need human intervention, and undoing a completed action may be unsuitable or impossible. The right recovery behaviour depends on the process. Microsoft: compensating transaction pattern.
Worked example: prepare a timesheet for review
WORKED EXAMPLE - HYPOTHETICAL
This example illustrates a scope. It is not a record of an MSD deployment or a claim of measured savings.
A staffing business wants approved timesheet information prepared for payroll review. Its existing work includes checking an approved submission, matching the worker and assignment, and entering a draft record.
The proposed automation begins when an approved timesheet becomes available. It finishes when the draft and its source reference are reconciled and ready for a person's review. Payroll submission, changing pay rules and approving payment remain outside the boundary.
The proposed flow is:
- Receive the approved timesheet and its source identifier.
- Check the required fields and permitted processing period against the agreed sources.
- Determine whether this version has already been processed.
- Prepare the draft in the permitted system.
- Match the resulting draft back to the source and make its status visible for review.
A missing worker identifier goes to the named payroll reviewer without creating a draft. A repeated event for an already processed version produces no second draft. A corrected timesheet needs its own rule: it must not be silently discarded as a duplicate or silently added as another payment.
If the draft system stops responding after an update, the item is held for reconciliation. The reviewer can see what was attempted and which result is still uncertain before deciding how to recover it.
The completed example in the worksheet carries those decisions into the scope and acceptance fields. It leaves actual access feasibility and business rules for the organisation to confirm.
Decide whether any step needs AI
A structured timesheet may be handled through ordinary integration and fixed checks. If information arrives in varied documents or free-text messages, an extraction model may help propose the fields. Test those proposals against representative source documents and define which cases require human review.
Input variation alone does not establish that AI is necessary, and a model cannot settle a business rule nobody has agreed. Keep the distinction between interpreting an input and authorising an action clear. Our AI automation page explains that separate suitability question. MSD has not yet run an AI worker for an external client.
Use the automation scope worksheet to record the decisions you can make now and name an owner for each unresolved question. Our automation and AI service begins with understanding the work and defining its scope. Bring that outline and a sanitised difficult case when you talk to MSD.
No AI worker has run for a client yet. We scope it and discuss it; we do not claim it is running for a client.
Sources and further reading
