How Do You Find Out How Work Actually Gets Done Before Automating It?

Detailed Explanation

Most businesses have at least three versions of an important process: the written procedure, the manager's explanation and the version staff use when the inbox is full and a customer needs an answer now. An automation built from only the first two versions tends to fail on the third.

Process discovery is the fieldwork used to establish what really happens. It means watching the task, following real cases, looking at the systems and side records involved, and asking about the conditions that cause the official path to bend. The output becomes the evidence for process mapping before automation, but the two activities are not the same. Discovery gathers and reconciles the facts. Mapping turns those facts into a shared representation.

The Australian Government Digital Service Standard applies the same basic principle at a larger scale: understand users, research their context, and test assumptions during discovery. A small business does not need a government service-design program, but it does need to replace assumptions with observation before spending money on a build.

Follow real cases from start to finish

Start with recent completed work, not a hypothetical walkthrough. Pick one ordinary case and several variations that staff remember as troublesome. For each one, trace:

1. What triggered the work.
2. Where the information first arrived.
3. Who touched it, in what order and using which system.
4. What they checked before moving it on.
5. What they recorded outside the official system.
6. Which decision changed the next step.
7. How the team knew the case was complete.

Ask the person to show the work on screen where appropriate. "I check the customer record" can conceal several steps: search by email, open a note, compare a spreadsheet and message another person for confirmation. An automation scope based on the short description will miss most of the task.

Use completed or sanitised cases when live records contain personal, financial or health information. Discovery does not need broad access to production data to be honest.

Interview the roles around the handoffs

Do not run one large workshop and assume consensus means accuracy. Speak separately with the people who create, receive and approve the work, then compare their accounts.

Useful questions include:

• What information is usually missing when this reaches you?
• Which step do you repeat because you do not trust the earlier result?
• What do you keep in email or a spreadsheet because the main system cannot handle it?
• When do you bypass the stated approval path?
• What happens when the usual person is away?
• Which cases look normal at first but need different treatment?
• How do you know a case has become stuck?

Leaders often know why a process exists and which controls should apply. Frontline staff know which fields get skipped, which approval is often returned and where the shadow spreadsheet lives. The automation needs both views.

Reconcile contradictions with evidence

Contradictions are findings, not workshop problems to smooth over. If one person says every refund needs approval and another says low-value refunds are handled immediately, pull several recent examples and establish what actually occurred. Then decide whether the difference is an accepted rule, an undocumented exception or a control failure that should be fixed before automation.

Keep three labels while reviewing the evidence:

• Current practice: what people actually do now.
• Required control: what policy, contract or law requires.
• Future decision: what the business wants the automated process to do.

Mixing these together creates a process description that is neither current nor approved. Discovery should show the gap before anyone designs the future workflow.

Look for the side systems

Many important steps sit outside the system named in the procedure. Check shared mailboxes, personal folders, spreadsheets, Teams or Slack messages, browser bookmarks, saved templates, printed forms and calendar reminders.

The goal is not to shame staff for using them. A side system usually solves a need the official process did not meet. Ask what purpose it serves before removing it. The spreadsheet may be duplicating data unnecessarily, or it may be the only place the team records a status the main system cannot represent.

This evidence also changes whether a paid discovery phase is worth it. If the process crosses several roles and nobody can describe the same current state, producing a reliable account is real project work, not administrative padding before a quote.

Turn the findings into a buildable scope

Finish discovery by replaying a short draft to the people involved. Walk through one normal case and each important exception. Ask them to identify anything that would force them back to the old method.

Only then turn the findings into a process map and automation requirements brief. The brief should name what the first release handles, what remains manual and which exceptions are out of scope. That boundary is often more useful than an ambitious promise to automate the whole process.

Things to Consider

• Make the exercise non-punitive. If people think discovery is a performance review, they will demonstrate the official path and hide the adaptations that matter most.
• Observe timing as well as sequence. A five-minute task that waits three days for an approval has a different automation opportunity from a task that consumes three hours of active work.
• Separate a rare case from a rare but serious case. Low frequency does not make an exception safe to ignore when it involves money, privacy, safety or a contractual deadline.
• Time-box the investigation. Discovery should become more precise as cases are reviewed. If it expands indefinitely, narrow the first release rather than trying to resolve every historical variation.
• Keep evidence proportionate. A four-step internal notification needs a short walkthrough. A process spanning customer data, billing and several approvals deserves deeper observation.

Common Mistakes

• Interviewing only managers. This captures purpose and policy but usually misses workarounds and small handoffs.
• Asking people to describe the process from memory. Following a real case reveals screens and checks that have become too routine to mention.
• Treating a workaround as automatically wrong. Understand the condition it solves before designing it out.
• Forcing agreement in the room. Resolve conflicting accounts against recent cases and required controls, not seniority.
• Starting the build before the exceptions are bounded. Unknown exceptions become change requests, manual clean-up or production failures later.