™Systems integration · Trade services
Connecting quoting, scheduling and invoicing
Three systems, none of which spoke to the others, and one person retyping between them. The fix required agreeing what a job was before writing any code.
The challenge
A trade services business had grown past the point where its tools fitted together. Quotes were produced in one system, jobs scheduled in a second, and invoices raised in a third. The same details were entered three times.
Discrepancies were routine: a quote revised after scheduling would not reach the invoice, and the difference was often discovered by the customer.
Approach
The first session was not technical. We established which system would be authoritative for each piece of information, and what should happen when two disagreed.
That conversation revealed the real problem, 'job complete' meant something different to the crew, the office and the accounting system, so any sync built before resolving it would have propagated confusion faster.
What was built
A small integration layer that owns the mapping between the three systems, with the quoting tool authoritative for scope and price, the scheduling system for dates and crew, and accounting for anything financial once invoiced.
Conflicts are not silently resolved. Where a rule cannot decide, the record is queued for a person with both versions shown.
A daily reconciliation report lists anything that failed to sync, so a stalled integration becomes visible the next morning rather than at month end.
Technology and process
- Scheduled synchronisation with event-driven updates for the time-sensitive paths.
- An explicit shared identity for customers and jobs across the three systems.
- Idempotent operations, so a retry after a partial failure does not create duplicates.
- Logging of every synchronisation with enough detail to trace a specific record afterwards.
Outcome
Details are entered once. The office role that previously spent much of the day retyping moved to work that required judgement.
The reconciliation report proved more valuable than expected: it repeatedly surfaced process problems rather than technical ones, which is usually a sign the integration is doing its job.
What we learned
- Agreeing definitions is the integration project. The code is the smaller half.
- A visible failure report matters more than a slightly more elegant sync, silent drift is the failure mode that actually hurts.
- Starting with two systems and adding the third later would have been faster than doing all three at once.
Client identity and commercially sensitive detail have been withheld. Outcomes are described qualitatively where measured figures are not available for publication.