Automating a workflow starts with frontline interviews

Why automation breaks on day one

Most workflows do not fail because the software is weak. They fail because the process map is cleaner than the job itself. A diagram might show five tidy steps, but real work includes side chats, judgment calls, missing details, and quiet fixes that never make it onto the page.

That gap matters. A system sees the official version of the process. It does not see the sales rep who rewrites a customer note so finance can use it, or the operations lead who spots a strange address and calls the client before an order gets stuck.

Problems usually appear first at handoffs. One team fills out a form, another team depends on it, and one small field gets skipped or entered the wrong way. People often catch that by habit. They know which customer uses a different billing name, which supplier sends incomplete numbers, or which request still needs manager approval even when the form says it does not.

A support request shows this clearly. On paper, it moves from intake to review to approval. In real life, the person reading it might spend five minutes checking old emails, fixing a product code, and adding context the customer never included. If you automate only the paper version, the request either stalls or moves forward with bad data.

Staff also hide more risk than most managers realize. They patch broken steps before anyone notices. They keep personal notes, save draft replies, or remember that one partner always sends the wrong file format on Fridays. The frontline team absorbs the mess, so the rest of the company never sees it.

That is why bad automation spreads so fast. A person can correct a wrong assumption once or twice a day. Software repeats it every time. If the process starts with missing fields, false rules, or incomplete handoffs, automation does not remove the problem. It locks it in and runs it at full speed.

Who you need in the room

If you are mapping a workflow for automation, talk to the people who touch the work at different points, not just the people who own the chart. The real process usually lives in small fixes, workarounds, and judgment calls that never reach a policy document.

Start with the people who enter data. They know which fields get skipped, guessed, or copied from old records. Then include the people who fix bad data later. They see the same mistakes repeat and know what breaks downstream. You also need the people who approve, reject, or send work back, because they decide what counts as "good enough" when the system does not fit the case.

Do not forget the person everyone messages when something gets stuck. Every team has one. Sometimes it is a coordinator. Sometimes it is a senior admin. Sometimes it is a quiet operator who knows three unofficial ways to get a task moving again. If that person is missing from the interviews, you miss the part of the job that keeps the whole process alive.

A useful interview group usually includes the person who creates the record, the one who corrects or completes it, the one who approves or rejects it, the one who chases missing details, and the person people call when the process jams.

Do not stop with one team or one office. A night shift may handle missing information differently from a day shift. A warehouse may use the system one way while head office uses it another. Two support teams can follow the same rule on paper and still do the work differently.

Managers matter, but they should not be the whole picture. Managers usually describe the intended process. Frontline staff describe the process that actually gets the work done. You need both views. When they do not match, pay attention. That gap is often where automation fails first.

Where data goes missing

Most process maps look clean because they show only the data a system expects. Daily work is messier. A customer leaves a field blank, a teammate types a name wrong in chat, or an order arrives by email with no account number. Those gaps matter more than the neat version on the whiteboard.

Ask the people doing the work which fields arrive blank or wrong most often. They usually know the answer right away. It might be phone numbers without country codes, invoices with the wrong company name, or support requests with no order ID. Then ask one more question: where did that bad data start?

A lot of data disappears during retyping. Someone reads an email, copies part of it into a form, then pastes the rest into the main system. Another person pulls details from a chat thread and creates a record by hand. Each step feels small, but one missing digit or one old address can send the whole job into manual cleanup.

The trust break matters just as much. Staff can tell you the exact moment they stop believing what the system says. Sometimes they check the original email before approving a refund. Sometimes they look in chat because the customer record is often late or incomplete. That moment tells you where the system stops reflecting the real job.

When the source record is missing, people rarely stop and wait. They improvise. They search old messages, ask a coworker, open a spreadsheet they keep on the side, or rebuild the record from memory. If you miss that behavior in interviews, your automation will fail on the cases that happen every day.

A few direct questions expose the weak spots fast. Which fields do you correct most often? Where do you copy data by hand? When do you stop trusting the screen in front of you? What do you do when you cannot find the original record?

Those answers give you a better process map than any formal document. They show where missing data enters, where people patch it, and where automation needs a human check instead of blind confidence.

Where people make exceptions

Even when a process looks clean in a flowchart, real work still depends on judgment. People bend rules for good reasons. A customer has a deadline. A supplier sent the wrong file. One field in the form is always blank even though the job still needs to move.

Ask who can actually make that call. The written policy may say "manager approval required," but the real answer might be a senior coordinator, the person on the late shift, or the employee who knows which customer always needs special handling.

Keep the questions plain. Which rule gets skipped most often? Who says yes when that happens? How often did it happen last month? What makes that case different from the usual path?

Weekly exceptions matter far more than rare disasters. If a team changes an order, reopens an invoice, or bypasses one approval every few days, that is part of the job. Treating it like a strange edge case will break the automation quickly.

A simple rule helps here: if it happens often enough that staff can answer without thinking, it is normal work in disguise. Rare edge cases usually need special review. Repeated exceptions usually mean the official process never matched reality.

This often shows up in small ways. A support team may promise a replacement before finance signs off because the customer is long-term and the issue is obvious. An operations team may ship with a missing internal code because waiting another day costs more than fixing the paperwork later. You will not see those choices in the standard process map, but they keep the business moving.

You also need to find the real decision-maker when the written rule does not fit. Sometimes one person owns that call. Sometimes the team decides by habit. Sometimes the person with the most context wins, even without formal authority.

If you want automation to work, capture that judgment path too. Otherwise the system will reject normal work, staff will work around it, and the old manual process will return through email, chat, and side notes.

What nobody writes down

Most work runs on spoken rules, sticky notes, and habits people build over time. If you miss that hidden layer, automation usually copies the official process and skips the real one.

Staff often carry small memory tricks that never reach a manual. They know which customer names need a second look, which form field people usually leave blank, and which reply over the phone tells them something is off. A model will not guess any of that unless someone says it out loud and you record it.

One of the best questions is simple: "What do you tell a new hire after the training is over?" That usually brings out the practical stuff. People mention side notes, verbal checks, and the little warnings they share on day three, not day one.

Teams also build shortcuts to keep work moving. Someone skips a field and fills it later. Someone checks an old order because the current record looks wrong. Someone recognizes a repeat customer and makes a call based on past issues, not just what the screen shows.

Those choices matter. They may protect speed, reduce mistakes, or avoid annoying a good customer. They can also hide risk. If you do not write them down, your automation will either block normal work or make bad calls with false confidence.

Ask where people keep personal notes or reminders. Ask which checks happen in chat, calls, or hallway conversations. Ask when staff ignore the written rule and why. Ask which customer histories change the decision. These answers usually reveal more than a polished process document.

A simple example makes the point. An approval flow may look clean in a diagram, but the team may quietly fast-track repeat buyers with a good payment record. They may also pause orders from new customers when shipping details look incomplete, even if the form passes validation. That judgment never appears in the process map, yet it shapes daily work.

Before you automate, collect those unwritten rules in plain language. Give each one an owner, a reason, and a limit. That turns private know-how into something the team can test, improve, and trust.

A simple interview process

Start small. Pick one workflow and one outcome people can name in a sentence, such as "send a correct invoice" or "approve a refund without delay." If the goal is fuzzy, every interview drifts and you end up automating a guess.

Talk to people one by one first. Group meetings sound efficient, but they hide the real job. In a group, the loudest person often tells the official version while the person who fixes the odd cases stays quiet.

A simple sequence works well. Choose one workflow with a clear finish line. Interview each person who touches it on their own. Write the steps in plain words as they describe them. Mark every gap, exception, and handoff while you talk. Then bring the draft back to the team and correct it together.

Keep the interview concrete. Ask, "What happens first?" Then ask, "What makes this stop, slow down, or go off script?" People remember the messy parts better when they can walk through a real example from last week.

Write the map in everyday language, not software language. "Customer sends missing form" is better than "input validation failure." Plain wording helps everyone spot where data goes missing, where someone makes a judgment call, and where the process depends on memory.

Mark disagreements live. If one person says a case always goes to finance and another says they solve it themselves, write down both versions. Do not clean it up too early. The mismatch is often the most useful part of the interview.

After the individual conversations, read the map back to the team line by line. People react faster to a visible draft than to abstract questions. They will say, "No, that only happens for new customers," or "We skip that step when the supplier is late." That is the detail you need before you automate anything.

The last step is to turn repeated pain points into rules. If three people say they re-enter the same order number, the rule might be to carry that number forward automatically. If everyone checks one field before approval, the rule might be to block approval until that field is filled.

This is the same pattern experienced CTOs use when they clean up messy operations. The best automation plans usually start with a plain map, a few honest interviews, and a short list of rules pulled from real work.

Example: a workflow that looks simple on paper

A refund process often looks clean in a diagram. The customer asks for a refund, support checks the order, finance approves it, and the payment goes back. You can draw that in four boxes and feel done.

Then real cases start showing up.

A customer says the package arrived damaged, but the return form only has codes for "wrong item" and "changed mind." Support cannot pick the right reason, so the ticket leaves the system and moves into email. Someone asks the warehouse if photos exist. Someone else checks whether the carrier already paid a claim. Finance waits for a code that never came through the form.

That one missing code causes more trouble than it seems. The work no longer follows the neat path in the workflow tool. It breaks into side messages, copied notes, and memory. If you map only the official steps, you miss the part where people actually solve the case.

There is usually a quiet rule too. A team lead may approve a refund faster for a trusted customer, maybe someone with a long order history and no abuse flags. Nobody writes that rule in the handbook because the team thinks it is obvious. It lives in habit, not documentation.

Automation fails fast when that rule stays hidden. It treats a long-time customer the same way it treats a first-time risky order, or it blocks the case because the damage code is missing. Staff then step around the system, send emails, and fix the result by hand. The tool looks slow or careless, even though the real problem started earlier.

That is why frontline interviews matter before you automate. You need the missing code, the off-system detour, and the unwritten shortcut. Once those details are named, you can decide what the system should do, what still needs a person, and where the process itself needs repair first.

Mistakes that blur the real job

When you map a workflow, the clean version people describe first is often the least useful. People usually start with the official path because it sounds correct, looks tidy, and matches the policy. That answer helps a little, but it rarely shows how work gets done when deadlines slip, records do not match, or a customer asks for something unusual.

A common mistake is treating workarounds as noise. They may look messy, but they often keep the process alive. If one person keeps a side spreadsheet, renames files by hand, or sends a private message before entering data, that is not random behavior. It usually means the main process drops context somewhere.

Another mistake is giving rare cases too much weight. Edge cases matter, but they should not drive the whole design. If a strange exception happens twice a year, note it and plan for a manual route. If it happens every Tuesday and everyone calls it rare, you found part of the real job.

Approvals cause trouble for the same reason. On paper, an approval can look like a simple yes or no. In practice, people check timing, customer history, missing documents, risk, and their own sense that something feels off. If you automate the click before you understand that judgment, you build a fast way to make bad decisions.

Teams also stop too early when they hear the first consistent answer. If three people describe the same flow, ask for the last time it went wrong. Ask what they do when the system blocks them, when data arrives late, or when one field does not fit the case. Real detail shows up in recent stories, not polished summaries.

A finance team might say invoices follow a simple path: submit, review, approve, pay. Five more minutes of questions can uncover the real version: missing purchase order numbers, suppliers who use different names, urgent payments that skip the queue, and one experienced employee who fixes half the issues before anyone notices. That is the process you need to study.

Quick check before you automate

A workflow is not ready for automation until the people doing it can answer a few blunt questions. If the answers are fuzzy, the system will copy the gaps, not fix them.

Use this check with the staff who do the work every day, not only with managers or process owners. The best answers usually come from the person who notices the bad order, fixes the spreadsheet, or chases a missing field late in the day.

Ask them to point to the first moment data turns unreliable. Name the exceptions that happen most often. Map every handoff between people and tools. Get the unwritten steps spoken out loud. Mark the rule that still needs a human call.

A simple test helps. Give one recent real example to the team and ask them to walk it through step by step. Stop each time someone says "usually," "it depends," or "I fix it myself." Those are not side notes. They are the job.

This is where automation usually succeeds or fails. Clean paths look great in a diagram, but real work lives in the messy parts. If you can name the first bad data point, the common exceptions, the handoffs, the unwritten actions, and the human judgment call, you have something real enough to automate.

What to do next

Start with one narrow step and test that first. Good pilots are usually plain, repetitive jobs: one intake form, one approval handoff, one follow-up message, or one status update. A small pilot shows where the real friction is without putting the whole process at risk.

Use the staff interviews as the pilot brief. Build around the places where data disappears, where people pause to make a judgment call, and where someone fixes a problem quietly before it spreads. That gives you a test based on the real job, not the diagram on a whiteboard.

Keep human review in place anywhere exceptions still matter. If staff sometimes override a rule, merge duplicate records, or decide that a case needs special handling, let the system assist rather than decide. A model can sort, draft, prefill, and flag. A person should still approve the cases that carry risk.

For the first few weeks, watch a short set of measures: errors that reach the next step, handling time per case, rework caused by missing or wrong data, and the number of cases that still need manual exception handling.

Those numbers are simple, but they tell the truth. If the process moves faster and staff spend less time fixing avoidable mistakes, the pilot is working. If speed goes up but rework goes up too, stop and adjust the design.

If you need a second set of eyes on that work, Oleg Sotnikov at oleg.is advises startups and smaller companies on Fractional CTO work, AI-first software development, and practical automation. It fits best when you already have real interview notes and need help turning them into a plan that matches how the team actually works.