How to interview employees about the way work really happens

Your operations manager says the invoicing process takes three steps. Your finance team actually does eleven — including two spreadsheets that nobody talks about and a WhatsApp message to the warehouse to double-check stock before confirming. When you automate the three-step version, you haven't automated anything. You've broken something that was quietly working.

This article shows you how to interview employees in a way that surfaces the real process — the workarounds, the exceptions, the undocumented steps — so that whatever you build next is grounded in reality, not assumptions.

Why do automation projects fail at the process mapping stage?

Most projects don't fail because of bad software. They fail because the process that was automated was never the process that actually existed.

Management typically describes the intended process — the one in the procedure manual, the one that made sense when it was designed three years ago. Employees, meanwhile, have adapted. They've found shortcuts around a slow system, invented a naming convention to compensate for a missing field, or started CC-ing a colleague on every order confirmation because the handoff to logistics otherwise gets lost.

None of that is in any document. And nobody thinks to mention it in a project kickoff meeting, because from the employee's perspective, it's just how you do the job.

The result: a new system or automation is built on the official version of the process, goes live, and immediately hits friction — because it doesn't account for the workaround that was carrying 30% of the real workload.

What makes employee interviews different from a requirements meeting?

A requirements meeting asks: what do you need the system to do? An employee interview asks: walk me through what you actually did yesterday.

The difference sounds subtle. It isn't. Requirements meetings invite people to describe the ideal. Interviews invite people to describe reality — and reality is where the complexity lives.

The goal of a process interview is not to gather feature requests. It is to reconstruct a faithful picture of a business process as it is executed day to day, including:

• The steps that happen before the official process starts (someone checks something informally, or a decision is made that never gets recorded)
• The exceptions that happen more often than anyone admits ("well, when the supplier sends a PDF instead of an EDI message, we...")
• The compensating actions that exist because an upstream step is unreliable
• The tribal knowledge that lives in one person's head and stops the process cold when they're on holiday

How do you prepare for an employee process interview?

Good preparation is what separates a useful interview from a polite conversation that tells you nothing new.

1. Choose the right people — not just the managers Interview the people who execute the process, not the people who oversee it. In a manufacturing context, that means the line operator, not the production manager. In finance, that means the accounts payable clerk who processes 80 invoices a day, not the controller who signs off on the month-end.

2. Pick a specific process — not a department Don't ask someone to describe "how purchasing works." Ask them to describe "what happens from the moment a purchase request lands in your inbox to the moment a purchase order is sent." Specificity forces concrete answers.

3. Review the official version first Before the interview, study the documented process — the flowchart, the SOP, the ERP configuration. Not because it's accurate, but so you can spot the gaps between what the document says and what the person describes. Those gaps are where the most valuable information lives.

4. Block enough time — and do it one-on-one Group interviews produce the official story. One-on-one interviews, with enough time (45–90 minutes), produce the real one. People are much less likely to mention a workaround in front of their manager or their peers.

What questions actually work in a process interview?

The most productive interviews are built around three types of questions: walkthrough questions, exception questions, and friction questions.

Walkthrough questions

These reconstruct the process step by step, in the employee's own language.

• "Take me through a typical day — what's the first thing you open when you sit down?"
• "Walk me through the last time you processed an order from start to finish."
• "What happens just before this step? What triggers it?"
• "What do you do next — and where does that information come from?"

The goal is to follow the actual sequence of actions, not the intended one. Push for specificity: which system, which screen, which file, which person.

Exception questions

Exceptions reveal the true complexity of a process — and they happen far more often than anyone's official process map suggests.

• "What happens when a customer order comes in with missing information?"
• "What do you do when the system doesn't have what you need?"
• "When was the last time something went wrong in this process — what happened?"
• "Is there a situation where you do this process differently?"

In a manufacturing environment, a line operator might describe how a materials shortage triggers a completely separate coordination chain — phone calls, manual overrides, a temporary log in Excel — that management has never seen documented because it "only happens sometimes." In practice, it happens twice a week.

Friction questions

These surface the pain points that employees have stopped actively noticing because they've adapted to them.

• "What's the most frustrating part of this process?"
• "What do you do that feels like a waste of time?"
• "If you could change one thing about how this works, what would it be?"
• "Is there anything you have to do manually that you think should happen automatically?"

In a finance team, the answer to that last question is often: "I re-key the supplier invoice data into our ERP every morning because the supplier sends a PDF and there's no import." That's not a minor inconvenience — that's a 45-minute daily manual process that an API or document parsing tool could eliminate entirely.

How does employee shadowing complement interviews?

Interviews capture what people say they do. Shadowing captures what they actually do.

Asking someone to describe a process relies on their ability to recall and articulate it. But many steps in a well-practiced process become automatic — people do them without consciously registering them, which means they often forget to mention them.

Shadowing means sitting next to someone while they work through a real task in real time. You watch them switch between four browser tabs, copy a value from one system into another, open a shared drive folder they never mentioned, and send an email to a colleague asking for confirmation before proceeding — all within the space of five minutes. None of those steps would have appeared in an interview.

A practical shadowing approach:

1. Ask the employee to narrate what they're doing as they go ("think out loud").
2. Note every system, file, communication, and decision point — even the ones that seem trivial.
3. When something unexpected appears, pause and ask: "How often does this happen? What do you do when it doesn't work?"
4. Do this across at least two or three people doing the same role — you'll often find that no two people do the process identically, which is itself critical information.

How do you document what you learn without losing the nuance?

The output of a set of process interviews should not be a tidy flowchart. Not yet. The first output should be a raw record of what people actually described — in their own words, with the exceptions and workarounds still visible.

Some useful documentation approaches:

• Verbatim notes with timestamps: capture the specific phrases employees use. "We always have to check in the old system" is more useful than "employee cross-references legacy data."
• Sticky-note process mapping (physical or digital): after the interview, reconstruct the process on a board, one action per note. Include decision points, exceptions, and system touchpoints as separate colours.
• Annotated official flowcharts: take the original process map and mark every deviation, workaround, or undocumented step in a different colour. The density of annotations tells you how far reality has drifted from the design.
• A "who knows what" log: note which steps rely on a specific person's knowledge. If a process only works because one employee has memorised a supplier's quirks, that's a fragility that automation must account for — or first resolve.

What are the most common things you find that weren't in the original process?

Across manufacturing, finance, and operations, the same categories of hidden complexity come up repeatedly:

• Shadow systems: a spreadsheet, a shared inbox, or a personal notebook that carries information the main system can't hold or doesn't capture in the right format.
• Informal communication steps: a Teams message or a phone call that functions as an approval, a check, or a handoff — completely invisible to any system.
• Manual reconciliation: someone who regularly compares two systems because they've drifted out of sync and neither automatically corrects the other.
• Personal workarounds for broken upstream steps: an employee who has developed a private fix for a recurring error in a previous step — and has never reported the original error because the fix has become routine.
• Undocumented exception handling: rules that exist only in experienced employees' heads, applied consistently but never written down.

In an operations team, you might discover that the dispatch planner has a personal rule: any order over a certain value gets a manual check against a second system before it's confirmed, because there was a costly error two years ago. That rule is real business logic. It needs to be in any system that touches dispatch.

Checklist: before you start mapping or building anything

• Have you interviewed the people who execute the process, not just those who manage it?
• Have you asked about exceptions, not just the standard flow?
• Have you shadowed at least one person doing the task in real time?
• Have you compared what employees describe against the official documentation and noted every gap?
• Have you identified which steps depend on a specific person's knowledge?
• Have you found all the shadow systems (spreadsheets, shared inboxes, notebooks) involved?
• Have you asked what happens when something goes wrong?
• Do you have a documented picture of the process as it is, separate from how it should be?

FAQ

How many employees should you interview for one process? At minimum, two or three people who perform the same process. Differences between their descriptions are as important as the descriptions themselves — they reveal where the process has no single standard execution, which is a risk for any automation.

What if employees are reluctant to share workarounds? They often are, because workarounds can feel like admissions that something is broken — or that they've been doing something unofficially. Frame the conversation explicitly: you're not auditing their work, you're trying to understand the real process so you don't build something that ignores what's actually keeping things running. Managers should not be present.

Should you record the interviews? Only with explicit consent, and be aware that recording can inhibit candour. Detailed notes, taken during or immediately after the session, are usually sufficient and less intrusive.

How is this different from a standard business analysis? Traditional business analysis often starts from documented requirements and works forward. Process interviews start from observed reality and work backward toward requirements. The difference matters enormously when the gap between the two is large — which, in most organisations, it is.

When is the right time to do this in a project? Before writing a single requirement. Before drawing a process map. Before evaluating software. The interviews are the foundation. Everything built on top of them is only as good as the picture of reality they produced.

---

If what these interviews reveal is a process that has outgrown its current systems — disconnected tools, manual re-entry, logic that lives only in people's heads — that's exactly the territory Loggix works in. Whether the right next step is a tailored FileMaker solution, an API integration that connects systems that currently require manual bridging, or a consultancy session to map out what a realistic build would look like, the starting point is always the same: a clear, honest picture of how work actually happens. That's what good interviews give you.