How to improve a process without redesigning everything

Your team is spending hours chasing approvals over email, re-keying the same order into three different systems, and waiting on colleagues who didn't know the ball was in their court. The process isn't broken in one big dramatic way — it's leaking in a dozen small places. This article shows you how to find and fix the most painful bottlenecks without tearing everything down and starting over.

Why do people assume they need a full redesign?

When a process feels painful, the instinct is to conclude that the whole thing is wrong. But most processes that grew organically inside a company contain a core logic that actually works — it's just surrounded by workarounds, redundant steps, and manual glue that accumulated over time.

A full redesign is expensive, disruptive, and risky. You lose institutional knowledge, staff resist the unfamiliar, and projects that start as "let's fix everything" routinely stall for months before delivering any value. The better question is: where exactly is the process bleeding the most, and what's the minimum change that stops that bleed?

How do you find the real bottleneck — not just the loudest complaint?

The bottleneck is almost never where people first point. The sales team complains about slow order processing, but the actual delay is a finance approval step that nobody mapped. Here's how to locate it:

1. Walk the process end-to-end, step by step. Don't rely on documentation — documentation describes the intended process, not the real one. Sit with the people who do the work and observe what actually happens.
2. Measure wait time, not just work time. A step that takes 10 minutes of work but sits in someone's inbox for 3 days is not a 10-minute step — it's a 3-day delay. Track elapsed time between handoffs, not just task duration.
3. Count the rework loops. Every time work travels backwards — a form returned for correction, an approval re-requested, an order re-entered because the first version had an error — you've found a symptom of a broken upstream step.
4. Look for the manual glue. Spreadsheets maintained by one person, email threads used as a ticketing system, WhatsApp messages that substitute for a status dashboard — these are signs that the process outgrew its tooling.
5. Ask: what breaks first when someone is sick? The answer almost always names the bottleneck.

What does a bottleneck actually look like in practice?

Here are three concrete patterns that appear repeatedly in mid-sized businesses:

Manual approvals living in email. A purchase request is emailed to a manager. The manager is travelling. The request sits for four days. The employee sends a reminder. The manager approves by replying to the wrong thread. The finance team never sees the approval and blocks the purchase anyway. This entire sequence is avoidable — not by redesigning the procurement process, but by routing the approval through a structured step with a clear owner, a deadline, and a visible status.

Duplicate data entry across systems. An order gets entered into FileMaker, and then re-typed by hand into Exact Online — every single order, every single day. The person doing it knows it's wasteful. But no one has connected the two systems, so the double entry continues. The fix isn't a new ERP — it's an API connector that pushes the data automatically when the order is confirmed.

Inefficient handoffs between departments. A project moves from sales to operations, but operations doesn't know what was promised to the client, what the timeline is, or what exceptions were agreed. Sales considers the handoff done; operations starts from scratch. The fix isn't a new project management methodology — it's a single structured handoff record that both teams fill in and can see.

In each case, the solution touches one step, not the whole process.

How do you decide which fix to tackle first?

Not every bottleneck is worth fixing immediately. Prioritise using two dimensions:

• Impact: How much time, money, or error rate does this bottleneck cost? Be specific — "it wastes about 2 hours per order and we process 40 orders a week" is actionable. "It's inefficient" is not.
• Effort: How hard is the fix, realistically? A structural form change might take a day. An API integration might take two weeks. A process that requires retraining 60 people is a different scale of project.

Plot your candidates on a simple 2x2: high impact / low effort fixes go first. Don't start with the most complex problem just because it feels most important.

How do you eliminate steps without breaking the process?

Before you automate or integrate anything, audit every step for whether it still needs to exist:

• Who does this step? If the answer is "whoever has time" or "it depends," the ownership is broken.
• Why does this step exist? If no one can answer, it may be a historical artefact — a control that was added for a risk that no longer exists.
• What happens if we skip it? Test this mentally, and where possible, test it literally in a low-risk context.
• Does this step create value, or does it just pass information along? Pure hand-off steps — where one person reads something and forwards it unchanged — are almost always candidates for automation or elimination.

A useful rule of thumb: if a step exists only to compensate for a weakness in an earlier step, fix the earlier step instead of optimising the compensation.

What's the right way to automate without over-engineering?

Automation is most valuable when applied to steps that are: high-frequency, rule-based, and currently done by a human who adds no judgment. Classic examples:

• Sending a notification when a status changes
• Moving a record from one queue to another based on a field value
• Generating a document from structured data
• Routing an approval to the right person based on department or amount
• Syncing confirmed data from one system to another

Automation is least valuable — and sometimes actively harmful — when applied to steps that require human judgment, exception handling, or relationship context. Don't automate the escalation of a client complaint; automate the routing of a standard invoice.

Start with a single automated step. Measure the result. Then expand. This is how you build confidence in the improvement without betting the process on a big-bang rollout.

How do you make incremental improvements stick?

Process improvements fail not because the fix was wrong, but because the change wasn't embedded in how people actually work. Three practices that help:

1. Change the default, not the option. If the new step requires extra effort, people will revert. Make the improved path the path of least resistance — pre-fill fields, trigger reminders, remove the old workaround from the shared drive.
2. Measure the before and after explicitly. "This approval now takes 4 hours instead of 4 days" is a message that travels. Vague improvements don't get celebrated and don't get replicated.
3. Assign a process owner, not just a project owner. The project ends; the process continues. Someone needs to notice when the old habits creep back.

Checklist: Is this process ready for incremental improvement?

Use this before committing to any fix:

• We have mapped the actual process, not just the documented one
• We know the elapsed time between each handoff, not just the task time
• We have identified the single step that causes the most downstream pain
• We know who currently owns that step (and they know it too)
• We have quantified the cost of the bottleneck in concrete terms (hours, errors, money)
• We have at least one fix that is high-impact and low-effort
• We have a way to measure whether the fix worked
• We have a named person who will own the process after the project closes

FAQ

Won't fixing one bottleneck just expose the next one? Yes — and that's the point. This is called the Theory of Constraints, and it's exactly how continuous improvement works. You're not trying to fix everything at once; you're trying to make the system measurably better, repeatedly, over time. Each fix raises the waterline.

How do we know when a full redesign actually is necessary? When the core logic of the process is wrong — not just slow or manual — a full redesign may be warranted. Signs include: the process produces the wrong output even when executed perfectly, the process can't scale at all without breaking, or the process was designed for a business model the company no longer uses. If none of those apply, incremental improvement is almost always faster and safer.

What if the bottleneck is a person, not a step? Rarely is a person genuinely the bottleneck. Usually they're the symptom — they've become a single point of contact because a system or handoff was never formalised. Fix the structure, and the person bottleneck typically resolves itself.

How long should an incremental improvement project take? The first fix should be live within 2–4 weeks. If it's taking longer, the scope has crept back toward a full redesign. Keep the first iteration deliberately small.

Can we improve a process while still using our existing software? Often, yes. Many of the highest-impact fixes — clarifying ownership, eliminating redundant steps, structuring a handoff form — require no software change at all. Software changes become valuable once the process logic is clean. Automating a broken process just makes it break faster.

For a broader look at how to redesign workflows across people, software, and AI together, see How to redesign a workflow for people, software and AI.

---

If you've mapped your process and know where it's breaking — or suspect you do but aren't sure how to confirm it — Loggix can help you work through it practically. Whether that means building a targeted automation inside your existing FileMaker environment, connecting two systems that currently require manual re-entry, or sitting down to map the real process before touching any tooling, the starting point is always the same: find the one step that's costing the most, and fix that first.