The demonstration looks simple. A new enquiry arrives, a record is created and the right person gets a notification. Then a real enquiry arrives without a company name, from an existing client, asking for something outside your normal service.
Before automating a business process, map its trigger, finish, inputs, owners, decisions, handoffs and exceptions. Trace real cases rather than only the ideal route. The result should show which actions can follow agreed rules and which cases require a person.
Photo by Beatriz Cattel on Unsplash.
Define the process start and finish before automation
Keep the boundary narrow. For an enquiry workflow, the start might be a submitted website form. The finish might be an assigned owner who has accepted the enquiry. Quoting, contracting and delivery can remain separate processes.
Write those boundaries down. Otherwise your mapping session can turn into a discussion about every problem in the business.
Follow real cases
Bring a few recent examples to the people who do the work. Include a straightforward case, an incomplete one and one that needed an unusual decision. Ask what actually happened at each step, which system held the information and where somebody waited.
Record the current process before designing a better one. A workaround may exist because the official route cannot handle a genuine need. Removing it without understanding it can move the problem somewhere less visible.
Capture more than a row of boxes
For every step, complete this short worksheet:
Trigger: What event starts this step?
Input: Which information is required, and where is the authoritative record?
Owner: Who performs the work or handles a failure?
Action: What changes, and in which system?
Decision: Which rule chooses the next route?
Exception: What happens if information is missing, duplicated or contradictory?
Output: What proves the step is complete?
Control: Which checks, approvals and access limits apply?
Then mark the handoffs. “Send an email” is an action. “Delivery accepts a complete brief” is a handoff condition. That distinction helps prevent an automation from sending messages while the work remains unowned.
Turn the map into automation requirements
Consider an illustrative enquiry process. A form submission creates a draft record. A duplicate check flags a possible existing client. Missing service details send the enquiry to a review queue. An operations lead confirms the owner before any promise goes to the client.
The map now suggests concrete requirements: which fields are mandatory, how duplicate cases are flagged, who sees the review queue and how long unassigned work can wait before escalation.
Remove unnecessary steps and settle ownership before configuring tools. If the routing rule still changes depending on who is asked, keep that decision with a person while the team agrees the rule.
Check the failure route before the happy route
Walk the proposed process through a missing field, a duplicate submission, a failed connection and an unavailable owner. Ask whether anyone can see the failure, correct it and safely restart the work without creating another record.
Keep the map with the workflow instructions and name a person to maintain it. Update it when rules or systems change. For the basic mapping method, start with our guide to getting processes out of your head. This worksheet adds the detail needed for an automation handoff.
When is a process map ready for automation?
Ask someone who did not draw the map to walk through a normal case and a failed case. Can they identify the authoritative record, next owner, missing-input route and restart rule? If the answer depends on asking the founder what usually happens, resolve that gap before configuring the automation.
If you want help finding a sensible first workflow, request an operational efficiency diagnostic with Hili Consulting. Bring one real process and the exceptions that keep interrupting it.
