The CRM saved US$25K a year. Uptime is why it stuck.

A manufacturer we worked with ran CRM and daily customer operations without a unified system. Records lived in several places, and reconciling them was somebody's afternoon. We moved both onto one platform.

The headline outcome was US$25K+ a year — around NT$800K. Most of it came from retiring the old setup, whose maintenance cost fell by 64%. Sales efficiency went up 42%. The team got back 8+ hours a week.

Those are the numbers that go on a slide. The one that decided whether any of it survived is 98.5% uptime.

Why the saving is the least interesting number

A cost saving is a one-time argument. You make it during procurement, someone signs, and then it stops doing any work for you.

What happens next is the part nobody puts in the case study. A manufacturer's sales team has a way of working that predates your system by years. It involves a spreadsheet somebody maintains, a WhatsApp group, and a person who knows where things actually are. Your new platform is competing with all of that, and it is competing badly at first, because the old way has the enormous advantage of already working.

The new system wins only if it is boringly available. Every outage is an argument for the spreadsheet. Two bad afternoons and the shadow process comes back, quietly. Then you have two systems instead of one, and the saving evaporates because you are maintaining both.

98.5% is not a badge. It is the reason the 42% exists a year later.

What "one system" actually costs to build

The phrase does a lot of hiding. Consolidating CRM and operations onto one platform means someone decides, for every field, which of two disagreeing records is the true one. That decision cannot be delegated to whoever writes the migration.

The work that took the time:

• Agreeing a single definition of a customer record across sales and operations, who had been using the word differently without noticing.
• Deciding what happens to the fields that exist in one system and not the other. Some get dropped. Someone has to say so out loud.
• Reconciling the two sources against each other before cutover, not after, because after is when you discover the mismatch in front of the person whose data it is.

None of that is technically hard. All of it needs a decision from someone with authority, and the project stalls at exactly the point where that person is unavailable.

The rule we now apply

When a consolidation is proposed, we ask what the failure mode of the old system is. If the honest answer is "it is annoying", the project is harder than it looks — annoying is survivable, and people survive it for years. The systems that get adopted replace something that is actually failing, or they are so much less effort that the shadow process dies of neglect.

Reliability is what buys the second outcome. That is why we treat it as a scoping question rather than an operations question, and why it appears in the estimate rather than after it.

What would not transfer

This was a manufacturer with a stable customer base and a sales process that repeats. The records are structured, the workflows are known, and the definition of "correct" is not in dispute once someone rules on it.

If your customer records are genuinely ambiguous, consolidation is not a technical project. Two departments can each defend a different version as correct, and neither of them is wrong. It is an organisational decision that happens to need software afterwards, and doing it in the other order produces a system nobody trusts.

If that sounds like your situation, the thing to scope is the decision, not the migration.

*This work was delivered by Luka Huang and Wei-yuan Chang within their own practice, before and alongside FDE Taiwan. It is part of the team's combined track record rather than an FDE Taiwan client engagement. The client is unnamed by agreement.*

If you have a consolidation that has stalled, our fixed-scope projects are built for exactly this shape of work — one defined problem, one price, two to six weeks.