The same information is entered into three different systems, and none of them fully agree with each other.
Cycle times have crept up quarter after quarter, but nobody can point to a single cause.
SOPs exist on paper but bear little resemblance to how the work is actually done.
New hires take six weeks to become productive because the actual process lives in the head of one senior employee.
Escalations are routine — not the exception — and usually get resolved by going around the process rather than through it.
The cost to serve a customer is rising faster than the revenue per customer, and the team can’t explain why.
We start by walking the process with the people who live inside it. Not the idealized version from a training deck — the real one, complete with the workarounds, the unofficial approvals, and the email threads that somehow substitute for system workflows. By the end of this phase you’ll have a clear, quantified picture of where time goes, where errors originate, and which handoffs are genuinely adding value versus the ones that have just always been there.
We run structured design sessions with a cross-functional group — operations, IT, finance, and the frontline — to sketch the future process from outcomes backwards. Every proposed step has to earn its place by answering a simple question: what would break if we removed it? The output is a redesigned process with measurable targets, a clear technology footprint, and a set of trade-offs the leadership team can sign off on without surprises later.
Rather than a big-bang switch, we pilot the redesigned process with a contained team or geography. A few weeks of real-world running reveals the edge cases no whiteboard session ever will, and we refine the design before scaling it across the organization. Rollout happens in waves, with each wave informed by what the previous one taught us. Training, updated SOPs, and system changes move together — not in separate tracks that fall out of sync.
Before we leave, each redesigned process has a named owner, a dashboard that tracks the handful of metrics that matter, and a review rhythm that surfaces drift early. We train your internal team to run improvement cycles independently, so the next round of optimization doesn’t require another consulting engagement. The measure of success here isn’t how clever the initial redesign was. It’s whether the organization is still improving the process a year after we’ve gone.
B2B Services · 1,100 employees · 9 months
From a two-week order cycle to a two-day one
A mid-sized B2B services firm was losing deals to faster competitors. On paper, their order-to-delivery process took eight days. In reality, the average was closer to fourteen, and the variance was so wide that sales had stopped making confident commitments to customers. The leadership team had already tried two internal improvement initiatives, both of which had produced decks but little measurable change.
We spent the first six weeks shadowing the process end to end, from quote to invoice. The diagnosis surfaced the usual suspects — duplicate approvals, data re-entry between CRM and ERP — but also a less obvious finding: a well-intentioned compliance check added years earlier was now blocking nearly every order for an average of three days, even though the underlying risk had been addressed by a system control that already existed upstream. The check hadn’t been removed because nobody had remembered to.
The redesigned process eliminated four review stages, consolidated three separate data entry points into one, and introduced a tiered approval model based on order value and risk. After a pilot with one business unit, the full rollout took four months. Cycle time dropped to two days for the majority of orders. Sales started quoting firm delivery dates again. The finance team, freed from chasing order status updates, shifted capacity to analysis work they’d been deferring for more than a year.
Faster cycle times across core revenue and operational processes
Lower cost-to-serve through eliminated redundancies and rework
Clearer accountability with named process owners and decision rights
SOPs that reflect the real process and scale with the organization
Technology investments that actually return what was promised
A workforce spending more time on judgment and less on coordination
There’s overlap, and we draw on those methods when they fit. The difference is scope. Lean typically optimizes an existing process; re-engineering asks whether the process should exist in its current form at all. We’re comfortable with both, and we’ll tell you honestly which one your situation calls for — sometimes a tune-up is the right answer, not a rebuild.
No — and in most cases it’s better if you haven’t. Choosing software before understanding the redesigned process is how organizations end up paying for features they don’t use and customizing tools to fit broken workflows. We’d rather redesign the process first and let that shape the technology decision.
Less than you’d expect, because we pilot before we scale. The diagnosis phase is largely observational and takes almost nothing from your team. The redesign sessions are focused and bounded. The rollout is wave-based, so no part of the organization is ever asked to absorb too much change at once. Business continuity through the project is something we plan for explicitly, not something we hope works out.
Most engagements sit between 300 and 5,000 employees, though we’ve worked smaller and larger. Below that range, the complexity usually doesn’t warrant a formal re-engineering project; above it, we’ll often focus on a specific function or business unit rather than the whole organization.
Fixed-fee for the diagnostic phase, and either fixed-fee or retainer for the redesign and rollout, depending on scope. We don’t charge on a pure time-and-materials basis because it creates the wrong incentives. You’ll have a clear view of the investment before we start, and any scope changes get discussed openly rather than appearing on the next invoice.