Replacing the human integration layer in back-office ops

The operations team was spending a large part of every week moving data between systems — re-keying purchase requests from one platform into another, copying approval statuses into shared spreadsheets, and chasing signatures over email chains that stretched into days. The problem was not a lack of diligence. The problem was a process architecture that had never been deliberately designed.

The problem

The core dysfunction was visible early in discovery: three separate systems — a licensed ERP, a vendor portal, and a master spreadsheet — each held a partial version of the truth, and staff were acting as the human integration layer between them. No single person had complete visibility into where a given request stood in its lifecycle.

Three constraints shaped everything that followed:

• The ERP could not be modified — any integration had to work through an API layer that was incomplete and rate-limited.
• Several approval workflows were genuinely judgment-sensitive; experienced staff handled a class of edge cases that no static rule engine could cover without unacceptable risk.
• The engagement had a hard deadline tied to a quarterly review. Anything not shipped by then would be deprioritized.

What we built

The system comprised four linked components:

• Data sync engine — a Node.js background service that pulls records from the ERP API on a defined schedule, normalises them into a PostgreSQL schema we controlled, and writes a full audit log of every change at ingestion.
• Workflow orchestrator — a rules-based routing layer that reads incoming requests, applies a decision tree built collaboratively with the ops team, and either auto-approves, routes to a human reviewer, or escalates based on value thresholds and vendor classification.
• Ops dashboard — a Next.js interface that replaced the spreadsheet as the team's operational source of truth: a queue view, single-record detail, inline approve/reject with a required comment field, and a daily digest email flagging anything the system had touched automatically.
• Integration adapters — lightweight connectors mapped the vendor portal's webhook payloads to the internal schema on ingestion, removing the manual re-keying step entirely.

The architectural decision that unlocked the rest: we stored every external record in our own database the moment it arrived, rather than querying upstream systems on demand. This decoupled the dashboard's performance from the ERP's rate limits, gave us a stable schema to build routing logic on top of, and created a natural audit trail the client had never had before. From that foundation, every downstream feature became simpler to build and test.

How we approached it

Work opened with a process-mapping session alongside the senior ops staff who understood every exception and workaround in the existing system. Rather than automating what we could see on the surface, we mapped the full lifecycle of three representative request types — high volume and routine, medium complexity with occasional exceptions, rare but high-stakes. We counted manual touches per step and tracked how often each step produced a downstream error. That gave us a prioritisation matrix: volume, time-per-touch, and error frequency.

The first automation we shipped was the least glamorous: auto-syncing vendor data into the internal database and surfacing a clean queue to replace the spreadsheet. No routing logic, no auto-approvals — just reliable, current data in one place. This built trust with the team and gave us real operational data on how records actually moved, which sharpened the routing rules that followed.

Data migration was handled with deliberate caution. The existing spreadsheet held years of historical records, many of them informally structured with inconsistent field conventions. We wrote a one-time migration script with strict validation, ran it against a staging environment, and reviewed every failure manually with the ops lead before touching production. Records with incomplete data were migrated into a "needs review" status rather than silently truncated or defaulted. That transparency mattered.

Change management was explicit rather than assumed. The team had attempted a workflow tool earlier that had been abandoned because it did not reflect how they actually worked. We ran the new system in parallel, with staff continuing to use the spreadsheet as a backstop. Once the dashboard's record counts matched across consecutive business days, they switched over. That parallel period also surfaced edge cases in the routing rules that we patched before go-live — bugs that would have eroded confidence quickly had they appeared in production.

The guardrails we built in: every automated action writes a reason-code to the audit log, the orchestrator has a conservative fallback to human review for any record it cannot classify with high confidence, and the daily digest ensures a human reviews everything the system acted on automatically. Automation without visibility tends to degrade trust over time. We designed both simultaneously.

What we will not claim

No hours-per-week recovered, no error-rate cut, no "four days to same-day" cycle time. Those figures are not in this repo. The public claim is the system: ERP and vendor records land in one store, a rules layer routes them, and the team works a queue instead of a spreadsheet.

If your operations team is carrying work that a well-built system should be doing, start a build with us or read more about our custom software development practice.