How to follow one transaction from beginning to end

Your sales team closed the deal. Three weeks later, the customer is chasing the invoice and nobody can say exactly what happened in between. Sound familiar? When a transaction touches multiple departments and systems, the breakdown points become invisible — until a customer complains or an auditor asks. This article walks you through how to trace a single transaction from first quote to final payment, step by step, so you can see every handoff, every delay, and every moment a person had to intervene manually.

Why following one transaction reveals what process maps can't

Most companies already have some kind of process documentation — a flowchart on a SharePoint page, a swimlane diagram from a consultancy project three years ago. The problem is that those documents describe the intended process, not the actual one. The actual process lives in the gap between systems, in the workaround your logistics coordinator invented six months ago, and in the email thread your account manager sends every Friday to chase a production status.

Following a single real transaction end-to-end — what process analysts call a transaction trace or instance walkthrough — forces you to confront what actually happens, not what should happen. It is the fastest way to find:

• Steps that have been automated on paper but are still done manually in practice
• Data that is re-entered by hand because two systems don't talk to each other
• Waiting time that nobody has ever measured because it happens between departments
• Decisions that are made based on outdated or incorrect data

What does a full sales order transaction actually look like?

Before you can trace a transaction, you need to name every stage it passes through. For a typical B2B sales order, that journey looks like this:

1. Quote — a salesperson creates a quote in CRM or a custom system, based on a product catalogue and customer-specific pricing
2. Order confirmation — the customer accepts; the quote becomes a confirmed sales order
3. Production or procurement planning — the order is handed to operations or a warehouse to plan fulfilment
4. Delivery or service execution — goods are shipped or the service is performed
5. Invoice — the finance team generates and sends an invoice
6. Payment and matching — the customer pays; the payment is matched to the invoice in the accounting system

Six stages. In a well-integrated company, data flows automatically between each one. In most companies, at least two or three of these stages involve a manual handoff: someone copies an order number into a spreadsheet, re-types delivery details into a logistics portal, or manually checks whether a payment has arrived before releasing the next order.

How do you actually trace a transaction step by step?

Pick one real, completed transaction — ideally one that took longer than expected or caused a customer complaint. Then work through it systematically.

Step 1: Identify every system the transaction touched

Start by listing every tool that holds a record of this transaction. Common examples:

• CRM (HubSpot, Salesforce, or a custom FileMaker solution)
• ERP or order management system
• Production planning or warehouse management system
• Logistics or shipping platform (e.g. MyParcel, a carrier portal)
• Accounting software (Exact Online, Twinfield, QuickBooks)
• Email and calendar (yes, these count — if a decision was made in an email, that is part of the process)

Write them down. You are building a system map for this single transaction.

Step 2: Pull the actual timestamps

For each system, find the timestamp of when this transaction entered and left that system. When was the quote created? When was it converted to an order? When did operations first see it? When was the invoice sent? When was payment booked?

This is where most companies get their first real surprise. A quote was accepted on the 3rd. Operations saw the order on the 7th. Nobody knows why there is a four-day gap — until you look in the email inbox and find that the order confirmation was sent as a PDF attachment and someone had to type it manually into the ERP.

Step 3: Map every human touchpoint

For each handoff between systems or departments, ask: did a person have to do something here, or did it happen automatically?

Mark every manual action clearly. Concrete examples of what you might find:

• A sales assistant copies the quote line items from CRM into the ERP — every single order, every single day
• A production planner checks stock availability in a separate spreadsheet because the ERP doesn't connect to the warehouse system
• A finance employee checks whether a delivery confirmation has been signed before creating the invoice — because there is no automatic trigger

Each of these is a friction point: a place where speed, accuracy, and consistency depend entirely on one person doing one repetitive task correctly.

Step 4: Measure the waiting time at each handoff

Use your timestamps to calculate dwell time — how long the transaction sat waiting at each stage. Not processing time, but waiting time: the hours or days between when one step finished and the next one started.

Typically you'll find that the actual work in a transaction takes a few hours. The waiting time adds days. A sales order that takes 14 days from quote to invoice often involves less than 3 hours of real work — the rest is waiting in someone's inbox, waiting for a daily batch export, or waiting for a weekly finance run.

Step 5: Note every data discrepancy

As the transaction moves through systems, does the data stay consistent? Common problems:

• The delivery address in the ERP is different from the one in the logistics system because a customer called to change it after the order was placed — but only one system was updated
• The product code in the CRM quote doesn't match the item code in the ERP, so someone has to manually translate every line
• The invoice amount doesn't match the order amount because a discount was applied verbally and never recorded

Data discrepancies are not just an IT problem. They are a process problem — they reveal the exact moment where two parts of your organisation stopped sharing a single source of truth.

Step 6: Document what you found, not what should have happened

Now write it up. Not a clean flowchart — a reality map. Include:

• The actual sequence of steps (with deviations from the intended process)
• Every manual action, with the person's role (not their name)
• All waiting times
• Every data transformation or re-entry point
• Any decisions that were made informally (by phone, email, chat)

This document becomes the foundation for any automation, integration, or improvement project. Without it, you are automating a process you don't actually understand.

What patterns should you look for?

Once you have traced two or three transactions, certain patterns tend to emerge:

The translation layer problem — Two systems use different data structures, so a person acts as a human API between them. Fix: build a proper integration.

The gate-keeping bottleneck — One person or one role must approve or forward a transaction before the next step can start, and that person is frequently unavailable. Fix: automate the trigger or distribute the responsibility.

The invisible queue — Transactions pile up at one stage (often invoicing or production planning) because that team only processes in batches. Fix: identify whether batching is a technical constraint or just a habit.

The phantom step — A step that appears in the official process but never actually happens. Example: a quality check that was supposed to happen before shipping but was quietly dropped six months ago. Fix: decide whether to remove it formally or reinstate it.

Checklist: what to capture in a transaction trace

Use this when walking through a real transaction with your team:

• List of all systems involved (with the record ID in each)
• Timestamp of entry and exit for each system
• Name of the role responsible at each stage
• Manual actions clearly marked (copy, re-type, email, phone call, spreadsheet)
• Waiting time calculated at each handoff
• Data fields that change value between systems
• Exceptions or workarounds that occurred in this specific instance
• Decision points and what information was used to make the decision

Frequently asked questions

How many transactions should I trace before drawing conclusions? Trace at least three — one that went smoothly, one that was delayed, and one that caused a customer complaint. Patterns that appear in all three are structural; problems that appear in only one are likely exceptions.

Do I need special software to do a transaction trace? No. A spreadsheet with timestamps and a whiteboard are enough to start. The insight comes from talking to the people involved and looking at the actual data, not from a tool.

What if my team doesn't have time to do this properly? A single transaction trace — done seriously, with real data — typically takes half a day with two or three people. That is almost always less than the time currently lost every month to the problems it will uncover.

Should I fix problems as I find them, or map everything first? Map first. Quick fixes applied before the full picture is clear often solve a symptom and create a new problem downstream. Finish the trace, prioritise, then act.

What is the difference between a transaction trace and a process audit? A process audit compares what you do against a standard or a policy. A transaction trace follows a real instance through reality. Both are useful, but the trace is faster, cheaper, and usually more revealing for operational improvement.

When is a transaction trace not enough? When the same transaction type has dozens of variants (different customer types, product categories, fulfilment routes), a single trace is just a starting point. You need to cluster the variants and trace a representative example of each.

What comes after the trace?

A completed transaction trace gives you something most process improvement projects lack: a shared, evidence-based picture of what is actually happening. From there, the natural next step is to prioritise which friction points to address first — usually the ones that combine high frequency, long waiting time, and manual re-entry of data.

For some of those points, the fix is organisational: clarify a responsibility, change a habit, update a procedure. For others, the fix is technical: connect two systems that currently don't talk, automate a trigger that currently depends on a person, or add a validation rule that currently relies on someone remembering.

At Loggix, we work with business owners and operations teams to take exactly this kind of transaction trace and turn it into a concrete improvement plan — whether that means building a custom FileMaker solution that bridges the gap between CRM and ERP, connecting systems through API integrations so data no longer needs to be re-entered by hand, or simply sitting down to map the process properly before any code is written. If your team has a transaction that nobody can fully explain from start to finish, that is usually the right place to start.