In short
A UK logistics SME hired us to connect three systems they had been operating in isolation - a warehouse management system, an accounting platform, and a CRM. Six weeks later they were live, 65% of the daily order-processing time had vanished, and six months later the integration had paid for itself in saved staff hours. This piece is the non-engineering version of that project: what we built, what we deliberately did not build, what it cost, and why the timeline was achievable. The technical breakdown is in our warehouse ERP case study; this is the one you can hand to your finance director.
What six weeks actually looked like
- Week 1 - discovery. Two days on-site with the warehouse manager, the finance lead and one of the account managers, mapping what each of the three systems was authoritative for, what data moved between them today (manually), and what the "done" state looked like. One day with each vendor's API documentation, plus a sandbox account where one did not already exist.
- Weeks 2–4 - build. Three integration pipes - WMS → accounting, WMS → CRM, CRM → accounting - each built and tested against a staging environment of all three systems. The middleware itself, with validator, outbox, retry and dead-letter dashboard, was the work of about eight engineering days; the rest was reading docs, writing test fixtures, and chasing edge cases.
- Week 5 - QA. A mix of synthetic test scenarios and replayed production traffic from the past month, with the client's ops team running their normal workday on the staging environment. Twenty-three issues found, eighteen fixed in the same week, five deferred to post-launch.
- Week 6 - parallel-running and cutover. Both the old manual workflow and the new integration ran side by side for a week, with the ops team double-keying for the first three days and spot-checking thereafter. We cut over on the Friday morning, watched the dashboard through the weekend, and closed the project on the following Monday.
There is no week missing from that list. The reason six weeks was achievable is not that the team was unusually fast - it is that the scope was unusually disciplined.
What we deliberately did not build
Three things landed on the "not in scope" pile at kick-off, every one of which would have doubled the timeline:
- No new UI in any of the three systems. The integration was invisible to the warehouse, finance and account-manager teams. They continued to use their existing tools exactly as before. We did not build dashboards inside their WMS or new screens in their CRM. The only new UI was the dead-letter monitoring page for the warehouse manager, which is two screens.
- No historical data migration. The integration went live on a fixed date and only synced events from that date forward. Historical data already lived in each system; it was not our job to reconcile it. This is the single largest scope cut and the one we have to defend the hardest on every project - and the one that saves the most time.
- No new business rules. The integration moved data between systems faithfully. It did not enforce credit limits, did not flag "unusual orders," did not generate alerts. Those are good features. They are also features the business could specify properly only after watching the integration run for a few weeks. We deliberately deferred them to a phase two that the client commissioned (and we delivered) four months later.
Each of those decisions came up multiple times during discovery. The discipline of saying "not now, definitely yes later" was the most important architectural decision we made.
The cost model, in shape
We do not publish per-project pricing for case studies, but the shape of the cost is useful to know if you are scoping something similar. Roughly:
- Discovery (week 1): ~10% of the total budget. The cheapest week to overspend on - every misunderstanding caught here costs nothing; every one caught in week 4 costs days.
- Build (weeks 2–4): ~55% of the budget. The bulk of the work, but cleanly bounded: three pipes, one middleware, one dashboard.
- QA (week 5): ~15%. People underestimate this. Synthetic tests are cheap; replayed-real-traffic tests are not, but they catch the failures that synthetic tests miss.
- Parallel-running and cutover (week 6): ~10%.
- Reserve / contingency: ~10%. Held back for the things you could not have predicted in week 1. On this project we used about two days of it, around the accounting vendor's authentication scheme being slightly weirder than the documentation suggested.
And the savings, in shape: the client measured an end-to-end processing time reduction of 65% on a daily order volume that touched roughly twenty-five orders a day, with two staff members previously spending about half their working hours on data re-entry between the three systems. The math on the labour saved alone covered the integration cost inside six months; the second-order benefits (fewer reconciliation errors, faster invoicing, better customer experience) sit on top of that.
What you need to bring to make a six-week timeline possible
Three things, in this order. None of them is technology.
1. A named decision-maker who can sit in the discovery week. Not delegated. Not "the team will get back to you." A person who can answer "is this the correct interpretation of how customer credit works in your business" without having to escalate. Every project that goes over runs into this on the first scope question.
2. Working API credentials for each system, on day one. Vendor portals, sandbox accounts, OAuth setup - all the things that "will take a day, two at most" and have consistently taken a week. If we cannot make a successful test call against each system by the end of week one, the rest of the timeline has to slip to match. Get this started before the project even formally kicks off.
3. An ops team available for week six. Parallel-running is not optional; it is the only honest test of an integration. The ops team needs to be expecting it, with a half-hour of training at the start of the week and the capacity to flag anything that looks off. The week-six cost is real and worth budgeting for.
With those three in place, six weeks is achievable for an integration of this shape - a small number of well-bounded systems, no UI work, no historical migration. With any of the three missing, expect to add weeks until you have them.
Considering a similar project? See our ERP integration services, our full warehouse case study page, or our guide on how ERP integration works.