CASE STUDY · API MANAGEMENT & INTEGRATION (IPAAS)
Connecting five disconnected business systems through one integration layer.
- 90About 90 manual hours a month removed
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised mid-market B2B services company. Name withheld under confidentiality.
A shared integration layer with versioned mappings, monitoring and retries. Each system connects to the layer once, rather than to every other system.
- 1The company used separate tools for its CRM, ERP, billing, support and data work.
- 2Staff manually re-entered information between them.
- 3A won deal in the CRM was typed into the ERP, then again into billing, and support needed customer details copied across.
- 4Mistakes crept in.
- 5Finance and sales regularly disagreed about the same customer.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01Duplicates appeared in the first month
Customers had been entered slightly differently in the CRM and billing tool, for example with a trading name in one and a legal name in the other, so the matching logic created a second record. We stopped matching on names. Instead we introduced a shared customer identifier, ran a one-time clean-up with the finance team, and added a rule that new customers receive the identifier at creation.
- PROBLEM 02It delayed one flow by about two weeks and removed a long-standing source of confusion
- PROBLEM 03A second hurdle was the nightly reconciliation itself
In the first weeks it reported many differences that were not errors. Billing recorded amounts at invoice time while the ERP posted them on a later date, so totals for the same day never matched. We agreed with finance on which system is authoritative for each figure, compared on shared period boundaries, and listed the known timing differences in the report.
- PROBLEM 04After that, a flagged difference meant something
03 · THE PROCESS
How we ran it.
We started with a two-week discovery. We interviewed the people doing the re-entry, listed every field they copied and ranked flows by time spent and error cost. Then we delivered flow by flow in short sprints, each with a demo to the operations lead. Every new flow ran in parallel with the manual process for a period, and staff compared results before the manual step was dropped. We held a weekly review with the client's operations and finance leads, and a short handover session for each flow.
- 01Step 1
We started with a two-week discovery.
- 02Step 2
We interviewed the people doing the re-entry, listed every field they copied and ranked flows by time spent and error cost.
- 03Step 3
Then we delivered flow by flow in short sprints, each with a demo to the operations lead.
- 04Step 4
Every new flow ran in parallel with the manual process for a period, and staff compared results before the manual step was dropped.
- 05Step 5
We held a weekly review with the client's operations and finance leads, and a short handover session for each flow.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
New customers are created once, and the details flow outward.
- NOW 02
Operations reviews the failure dashboard each morning.
- NOW 03
Changes to field mappings are reviewed and versioned.
- NOW 04
Finance relies on the nightly reconciliation instead of spot checks.
- 90
About 90 manual hours a month removed
Sync errors visible in one dashboard
05 · WHAT WE BUILT
How it works.
- Hub design: a central layer receives changes from each system and routes them.This avoids point-to-point connections between all five tools.
- Canonical records: a shared model for customer, order and invoice, with a mapping to each system's own fields.Mappings are stored in version control with change history.
- Reliability: each message has an identifier.Consumers are idempotent, so retrying never creates duplicates. Temporary failures retry with back-off. Permanent failures go to a dead-letter queue.
- Monitoring: one dashboard shows volumes, lag and failures per flow, with alerts that name the record and the reason.
- Security: least-privilege service accounts, credentials in a managed vault and an audit log of changes to mappings.
- Reconciliation: a nightly check compares key totals across systems and reports differences.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- The company used separate tools for its CRM, ERP, billing, support and data work. Staff manually re-entered information between them. A won deal in the CRM was typed into the ERP, then again into billing, and support needed customer details copied across. Mistakes crept in. Finance and sales regularly disagreed about the same customer. A few scripts existed, but they belonged to people who had moved on, and nobody knew when one had silently stopped.
- What did Brandsmashers build?
- A shared integration layer with versioned mappings, monitoring and retries. Each system connects to the layer once, rather than to every other system.
- How was the work run?
- We started with a two-week discovery. We interviewed the people doing the re-entry, listed every field they copied and ranked flows by time spent and error cost. Then we delivered flow by flow in short sprints, each with a demo to the operations lead. Every new flow ran in parallel with the manual process for a period, and staff compared results before the manual step was dropped. We held a weekly review with the client's operations and finance leads, and a short handover session for each flow.
- What were the results?
- About 90 manual hours a month removed; sync errors visible in one dashboard.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
