1. Describe the process in a single sentence
Use this structure: “When [trigger] happens, validate [inputs], obtain [approval if needed], update [destination] and tell [owner] whether it completed.” If the sentence contains several unrelated processes, choose the one with the clearest business owner and observable completion point.
Record the current effort and failure pattern using actual observations. Time spent on a process is useful evidence, but it is not automatically a saving: review work, exceptions, subscriptions and maintenance may remain after automation.
2. Complete the scope worksheet
| Decision | What to record | Who should confirm it |
|---|---|---|
| Trigger and finish | [Event that starts work; event that proves completion; excluded cases] | [Process owner] |
| Inputs and quality | [Required fields; formats; source; missing or invalid data rules] | [People providing and consuming the data] |
| Systems and access | [Source and destination; supported API; permissions; available test environment] | [Application owners] |
| Business rules | [Field mappings; decisions; approval conditions; permitted actions] | [Business approver] |
| Volume and timing | [Typical and peak volumes; business deadlines; external limits to check] | [Operations and technical owners] |
| Exceptions | [Missing data; duplicate; timeout; failed update; named resolution owner] | [Operating team] |
| Acceptance and handover | [Test cases; reviewer; release approval; runbook; support boundary] | [Buyer and operating owner] |
| Commercial boundary | [Included work; dependencies; excluded changes; licences and consumption costs] | [Buyer and delivery lead] |
3. Example: a laboratory request intake
Suppose a laboratory receives approved sample or testing requests through a form. It wants to create or update the record in its laboratory system and prepare the next task. The first scope could cover the form, validation, one approval and one destination system. Migrating historic records, changing the laboratory data model and automating later notifications would be separate decisions.
| Condition | Expected result | Resolution owner |
|---|---|---|
| Complete, valid and approved request | Write the agreed fields once, record the destination identifier and mark completion. | Process owner accepts the result. |
| Required field missing | Stop before the write and request the missing information through the agreed channel. | Intake owner resolves the request. |
| Approval declined or unanswered | Do not proceed to the protected update; record the outcome or follow the agreed reminder rule. | Named approver or delegate. |
| Repeated submission | Apply the agreed matching rule and avoid an unintended duplicate record. | Operations owner reviews ambiguous matches. |
| Destination timeout | Record the attempt; confirm whether the update happened before deciding whether to retry. | Technical owner investigates uncertain outcomes. |
| Permission or mapping failure | Pause the affected item and expose enough context for resolution without publishing sensitive data. | Application owner corrects access or mapping. |
4. Agree exception ownership, not just error messages
For each failed step, specify who sees the issue, what information they receive and how they resume or close the item. Retrying every failure can repeat a business action. The design must distinguish a temporary technical problem from invalid data, a rejected approval or an uncertain update.
Also decide where the operating record lives. A team needs a practical way to answer whether an item is pending approval, completed, failed or awaiting a person, without reading source code or guessing from an inbox notification.
5. Choose the implementation after the operating decisions
Custom code, workflow engines and the automation built into your existing platforms solve different combinations of integration, hosting, validation and maintenance needs. Review supported APIs, available permissions, expected usage, licence costs and the team's ability to own the result. They can be combined when the scope warrants it.
6. Define a useful first work package
A single laboratory might start with one complete workflow. A department might select a process with several application owners. A larger organisation can start with a bounded integration that uses its approved environments and release controls. In each case, agree inputs, dependencies, tests, handover and exclusions before committing to dates or fees.
Bring the completed worksheet and one anonymised example to the first discussion. It makes it easier to identify what can be scoped now and which access or business decisions need resolving first.