Editorial draft · awaiting review
An original AI-assisted educational draft informed by public sources. The example is hypothetical, not a client case or an account of Shachar’s work. Awaiting editing and approval.
1. Follow one request from beginning to end
Choose a task you can describe without relying on a broad label such as “operations”: handling a request for a quote, for example. Note what starts it, who sees it first, what information is needed, who makes a decision, and what counts as finished. Include the waiting between actions. Begin with one real case, then examine others so an unusual incident does not become your description of the entire process.
GOV.UK’s experience-mapping guidance draws on several users’ experiences to identify stages, difficulties and dependencies. Here, a simple map is a starting point for a conversation with the people doing the work.
SOURCES / FURTHER READING
2. A hypothetical example: the request that opened quickly, then stalled
Imagine a request entering a shared inbox, being copied into a spreadsheet, and then being forwarded to a team member. They open it and discover that the preferred date is missing. They ask for clarification, but the reply arrives in someone else’s inbox. Everyone has taken an action, yet nobody has a request they can complete.
An email-to-spreadsheet integration might save copying. In this example, it would not supply the missing information or establish ownership. Before building it, the team could try a short intake form and a clear assignment rule. That is an option to test, not evidence that every business needs a form.
SEE THE IDEA
What changes—and what stays stuck?
Continuing the fictional example: a request has no preferred date. Choose an option to compare.
Copy faster
- InboxNew request
- SpreadsheetAutomatic copy
- Team memberDate missing
- ClarificationWho receives the reply?
Copying may take less effort, but the date is still missing and clarification can scatter across inboxes. Movement between tools is not necessarily progress on the request.
Clarify intake + owner
- RequestWhat is needed?
- Check detailsInclude preferred date
- Named ownerA clear place for follow-up
- Review fitCan work proceed?
An option to test: request the essential details and assign an owner before handoff. Check whether that fits the actual work; do not assume a form solves everything.
3. Define what must be true at the end
Describe an outcome you can check: “Every complete request has an owner, a response date and a visible status.” Now review which parts of the process contribute to that outcome. A field nobody uses may be unnecessary. An approval that does not lead to a decision may need clarification.
Define ambiguous words, too. Does “handled” mean a reply was sent, the customer agreed, or the work was completed? If people use the same status to mean different things, settle that difference before a system starts moving it between tools.
4. Choose a useful measure and a starting point
GOV.UK recommends deriving measures from the service’s purpose, establishing a baseline, and combining data with user research. A small business does not need to copy government-service metrics; it needs a measure that answers its own question.
In our example, the team could track requests left without an owner or requests requiring another exchange to obtain missing information. Record how you counted and over what period. Then ask the team whether work was removed or merely transferred to someone else. The number of automated actions alone will not answer that.
SOURCES / FURTHER READING
5. Plan for failure before switching it on
Give each connection an owner and a fallback way to continue working. Write down what should happen when permission is missing, a field is empty, or a service is unavailable. Microsoft’s Power Automate guidance describes error paths, logging and notifications: a failed outcome needs a visible response rather than silently disappearing.
Pay particular attention to retries. Microsoft warns that rerunning a flow can duplicate records or messages. Before resubmitting, establish what already happened and whether repeating the action is safe. Use dummy data and authorized test recipients when testing, rather than accidentally contacting customers.
SOURCES / FURTHER READING
6. Choose a small change you can explain and maintain
Start where the rule is clear: creating a task from a complete request and assigning it to an agreed owner, for instance. Keep decisions that still require judgment under human review. Record which information moves between tools, who can access it, and who will maintain the connection.
Before expanding, walk through a complete request, an incomplete request and a duplicate with someone who uses the process. Ask them to explain what they see and what they should do. If every case needs a spoken explanation, improve the labels and handling steps before adding more automation.
Worksheet: what to settle before choosing a tool
Copy this into a notebook or document and fill it in:
The recurring task is ___. It begins when ___ and is finished when ___.
The required information is ___. The owner is ___. Work gets stuck at ___.
The change we will try is ___. We will evaluate it using ___. We will record the current situation by ___.
If the connection fails, ___. Before retrying, we will check ___. The person responsible is ___.
These answers form a planning brief. Missing answers point to questions worth resolving with the people involved.
SOURCES / FURTHER READING