Automation projects often begin with a sentence such as, “We need this form to talk to that system.” It sounds like a technical job, but the connection is rarely the difficult part. The harder question is what should happen to the information after it arrives.
A short process record gives that question a sensible answer. It does not need formal notation, specialist software or a wall covered in sticky notes. It needs to show how one piece of work moves through the business today, including the awkward bits people normally keep in their heads.
Choose one piece of work
Do not try to map the whole business at once. Pick a repeated job with a clear beginning and end: handling a new enquiry, preparing a quote, approving a booking or setting up a customer account.
Name the process in plain language. “From website enquiry to booked call” is more useful than “lead management workflow” because it sets boundaries. You know where to start looking and when the job is complete.
If the process has several different outcomes, choose the most common route first. You can add the unusual cases once the ordinary path makes sense.
Record the trigger and the finish
The trigger is the event that starts the work. It might be an email arriving, a customer completing a form or a member of staff changing an order status. Be precise. “A customer gets in touch” could describe a telephone call, social message or web form, and each may start a different sequence.
Then define what “done” means. An enquiry is not finished merely because somebody replied. The business may need to record the outcome, arrange the next action or close the enquiry with a reason. Without a finish point, an automated workflow can move information around while leaving the actual job unresolved.
Follow the work as it happens
Write down each action in order, using the person or system responsible as the subject:
- The website sends the enquiry to the shared inbox.
- The office manager checks whether the location is covered.
- The sales lead reviews enquiries that need a custom answer.
- The customer receives a reply and the team records the next action.
Observe a real example if you can. The written procedure may say that every enquiry goes into the customer system, while staff actually keep a few in their inbox because a required field is missing. That gap matters. Automating the official version would preserve a process that people already work around.
Include spreadsheets, inboxes, paper notes and private reminders. They may look temporary, but they often hold information the eventual tool will need to handle.
Find the decisions people make
A useful process map records decisions as well as actions. At each step, ask what the person needs to know before they can continue. A team member may check the customer’s postcode, order value, account status or requested date. They may also rely on judgement that no field can capture neatly.
Write the rule where there is one. Where judgement is involved, say who owns the decision and what information they use. Do not force a fuzzy choice into a rigid automated rule simply to make the diagram look tidy. The better design may be to collect the facts, present them clearly and leave the final decision with a person.
Note handovers and exceptions
Handovers are easy places to lose context. Record what moves, who receives it and how they know it is ready. If one person copies details from an email into a spreadsheet and then messages a colleague, list all of it. Repeated copying may be a candidate for automation, while the message could be an important notification rather than wasted effort.
Next, look at recent examples that did not follow the usual path. What happens when information is missing, a duplicate record exists, a payment fails or the usual person is away? You do not need to design every rare case before starting, but common exceptions need an owner and a safe route back into the process.
List the information the process uses
For every step, note the information that comes in, what changes and what must be kept. This exposes small but costly ambiguities. Two staff members may use “approved” to mean different things, or separate systems may store different versions of the same contact details.
Also decide which information is sensitive and who genuinely needs access to it. A new tool should not give everyone a wider view simply because the old spreadsheet did.
Turn the record into a practical brief
Once the current path is visible, mark the parts that are slow, repetitive or prone to being missed. Keep the useful human checks. Remove steps only when you understand why they exist.
The result is a much stronger starting point for discussing SaaS tools and automation. It can also show that the job needs a focused custom business app, a small change to an existing system or no new software at all.
Bring one real example, the current process record and two or three troublesome exceptions into the first technical conversation. That is enough to test the shape of the problem before anyone commits to screens, integrations or a build plan. If you would like a second pair of eyes on the process, send Mighty Digital Studio a project enquiry.