How to map a business process before automating it

Your operations manager says the order-to-invoice process "basically works." Your sales team says approvals take too long. Your finance department says invoices go out late. Everyone is describing the same process — and no two descriptions match. That gap is exactly where automation projects go wrong. This article walks you through how to map a business process with enough precision that what you build actually solves the right problem.

Why do automation projects fail before they even start?

The most common cause isn't bad software or a weak development team. It's automating a process that was never properly understood in the first place. When a company decides to automate its order-to-invoice flow, the instinct is to jump straight to a tool: a new ERP module, a custom FileMaker workflow, an API connector to the accounting system. But if no one has sat down and traced exactly what happens between "customer places an order" and "payment hits the bank account," the automation will faithfully reproduce every bottleneck, every workaround, and every undocumented exception — just faster and more expensively.

Automating a broken process doesn't fix it. It scales it.

What does process mapping actually mean?

Process mapping is the act of making a business process visible — drawing out every step, every decision point, every handoff between people or systems, and every exception that the team handles without thinking. The output is usually a process flow diagram (sometimes called a swimlane diagram or a workflow map), but the real value is in the conversations and discoveries that happen while you build it.

A process map answers five questions for every step in a workflow:

1. Who does this step? (a person, a team, a system)
2. What exactly happens? (not what should happen — what does happen)
3. When does it trigger? (on receipt of an email, at end of day, when a status changes)
4. Where does the data live? (a spreadsheet, a CRM, someone's inbox)
5. What can go wrong? (and what does the team do when it does)

The fifth question is the one most mapping exercises skip — and it's where half the complexity hides.

How do you map an order-to-invoice process step by step?

Let's make this concrete. Here is a realistic order-to-invoice process at a mid-sized B2B company, and how you would map it properly.

Step 1: Define the process boundaries

Before drawing anything, agree on where the process starts and ends. For order-to-invoice, a reasonable scope is:

• Start: A customer sends a purchase order (by email, web form, or phone call)
• End: The payment is received and reconciled in the accounting system

This sounds obvious, but teams often have different mental start points. Sales thinks the process starts when a quote is accepted. Finance thinks it starts when a sales order is created in the system. That disagreement alone is worth surfacing before you write a single automation rule.

Step 2: Walk the process with the people who actually do it

Don't map from a procedure manual. Sit with the people who process orders every day and ask them to walk you through the last five orders they handled — not the ideal scenario, the real ones. Ask: What did you do when the customer asked for a product that was out of stock? What happens when the approver is on holiday? What do you do when the invoice bounces back?

In a typical order-to-invoice process, you will discover steps like:

• A sales rep copies the customer's PO into a sales order in the CRM, then sends a separate email to the warehouse — because the CRM doesn't talk to the inventory system.
• The finance manager approves orders over €5,000 by replying to a forwarded email thread, and the approval sits in an inbox nobody else can see.
• Invoices are generated in one system and manually re-entered into Exact Online — every single order, every single day.
• Payment reminders go out on a fixed schedule, regardless of whether the customer already paid, because the payment status isn't linked back to the CRM.

None of these steps appear in the procedure manual. All of them will become problems the moment you automate.

Step 3: Draw the current state ("as-is") map

Only after walking the process should you draw it. Use a swimlane format: each lane represents a role or system (Sales, Warehouse, Finance, Customer, ERP, CRM). Place each step in the correct lane and draw arrows showing handoffs.

For the order-to-invoice example, your swimlanes might be:

Lane	Key steps
Customer	Sends PO, receives order confirmation, receives invoice, makes payment
Sales	Logs PO, creates sales order, checks stock, sends confirmation
Warehouse	Picks order, creates delivery note, marks shipment done
Finance	Approves order (if over threshold), generates invoice, sends invoice, chases payment
ERP/CRM	Holds order data, inventory data, invoice records

Mark every point where data moves from one person or system to another. Mark every manual re-entry. Mark every email that substitutes for a proper system handoff. These marks are your automation opportunities — but they're also your risk points.

Step 4: Identify bottlenecks, duplications, and missing rules

Once the as-is map is in front of the team, patterns emerge quickly. Common findings in an order-to-invoice process:

• Bottlenecks: The finance manager is a single point of approval for all orders over €5,000. If she is out, approvals stop.
• Duplicate data entry: The order is in the CRM and re-entered in the ERP. If either entry has a typo, the invoice goes out with wrong details.
• Missing rules: There is no agreed process for partial deliveries — sales handles it differently every time.
• Shadow processes: The warehouse keeps a separate Excel sheet to track rush orders, because the CRM doesn't have a priority flag.

Document every finding. Don't try to fix them yet — just make them visible.

Step 5: Design the future state ("to-be") map

Now redesign the process. For each bottleneck, duplication, or missing rule you found, decide: should this be eliminated, simplified, or systematised? Only after this redesign should you ask what can be automated.

For the order-to-invoice example, a redesigned flow might:

• Replace the email approval chain with a rule-based approval workflow inside the business system, with an automatic escalation if no response within 24 hours
• Connect the CRM and ERP via an API so a sales order created in one system automatically appears in the other — no manual re-entry
• Auto-generate invoices when the warehouse marks a delivery as complete, rather than waiting for a finance team member to act
• Check payment status in real time before sending a reminder, so the customer who already paid doesn't receive a dunning notice

The to-be map is what you hand to developers. Not a list of features — a mapped, agreed, edge-case-covered process.

Step 6: Validate with edge cases before building

Every process has exceptions. Before any development begins, walk through at least five non-standard scenarios with the team:

• What if the customer changes the order after it's been approved?
• What if delivery is partial?
• What if the customer disputes the invoice?
• What if the order comes in outside business hours?
• What if a product is discontinued mid-order?

For each exception, the process map must have an answer. If the team's response is "we'll handle it case by case," that's a gap — and gaps become support tickets after go-live.

What tools work best for process mapping?

The tool matters less than the discipline. Common options:

• Miro or Lucidchart — collaborative, easy to build swimlane diagrams in real time with the team
• BPMN notation — a standard notation if you want a diagram that developers and business analysts can both read precisely
• A whiteboard — still the fastest way to get a first draft out of people's heads and onto a shared surface

Start with the whiteboard. Digitise after the conversation.

Process mapping checklist

Before handing a process to a developer or automation platform, verify you can check every item on this list:

• Process start and end points are explicitly agreed
• The map reflects what people actually do, not what the procedure manual says
• Every handoff between people, teams, and systems is documented
• Every manual re-entry point is identified
• Bottlenecks and single points of failure are named
• Missing or inconsistent business rules are documented
• Shadow processes (Excel sheets, email workarounds) are surfaced
• At least five exception scenarios have a defined path through the process
• The to-be map has been reviewed and agreed by every role involved
• The to-be map has been shared with the development team before scoping begins

FAQ

How long does process mapping take? For a mid-complexity process like order-to-invoice, expect two to four half-day sessions: one to walk the current state with the team, one to review and complete the as-is map, and one to design the to-be. Rushing it is the single fastest way to guarantee a costly rebuild later.

Do we need a business analyst, or can we do this ourselves? You can do it internally if someone on the team is willing to play the role of a neutral observer who asks "why" repeatedly without assuming they already know the answer. The risk of doing it purely internally is that everyone in the room already has mental models of the process — and those models have blind spots. An external facilitator (or an experienced implementation partner) will surface the assumptions the team didn't know it was making.

What is the difference between a process map and a requirements document? A process map describes what happens and who does it. A requirements document describes what the system must do. You need the process map first, because the requirements should flow from it — not be invented in isolation by a project manager or a vendor.

What if different team members describe the process differently? That is not a problem with your mapping exercise — that is the mapping exercise working correctly. Inconsistency in how people describe a process means the process itself is inconsistent. Surface that disagreement, resolve it in the to-be map, and document the agreed-upon version. If you don't, the development team will make an arbitrary choice for you.

Can we map a process once and reuse the map forever? No. Processes change as teams, tools, and customer expectations change. Treat your process maps as living documents and review them whenever you change a system, restructure a team, or see a spike in errors or complaints. A process map that is two years old is a historical artefact, not a reliable guide.

---

If you've mapped your process and you're ready to think about what automation, integration, or custom tooling would actually fit — that's exactly the kind of problem Loggix works on. Whether it's connecting your CRM and accounting system through a clean API integration, building a custom FileMaker workflow that reflects your real process (not a generic template), or sitting down together to work through a process you're not yet sure how to structure, the starting point is always the same: understanding the work before touching the tools.