Eight systems that were never meant to talk, working as one back office
A cafe business ran its tills, HR, staff training, e-signature, kitchen supplier invoices and accounts on separate products from separate vendors. Each one did its job, and a person retyped between all of them. We connected them rather than replacing them.
At a glance
- 8
outside systems connected
- 30
purpose-built tools
- 3
independent checks on every day of sales
- 0
card details requested or stored
The challenge
None of the products was the problem. The work was in between them: the day's takings copied out of the till's back office, timesheets pulled into a spreadsheet for payroll, starter forms retyped from PDFs, holiday records checked against the HR system from screenshots and supplier invoices coded by hand, line by line.
Replacing everything would have cost more than the retyping, and several of the products had no API worth the name. The brief was to leave them where they were and make them work together.
Architecture
Swipe to explore the diagram
Each system stays where it is. The integration layer reads from it the best way it allows, reconciles what it reads, and writes only through fenced, checked paths.
What we built
Where there's no API
- Sales, timesheets and the product list read from the JSON endpoints the till back office's own pages call, over a browser session a person logged into by hand
- The HR and absence platform's internal API captured from its own network traffic, every read tied back to the screen, and each write proven on a test employee before a real one
- The training platform's pages and API mapped the same way, so training records can be read from the source rather than exported
Where there is one
- Starter forms sent for signature over the e-signature service's REST API, with the fields placed by the same layout pass that drew the PDF
- Daily takings posted to the accounts through a fenced connector that reconciles the gross before anything posts
- The office scanner driven directly over eSCL: blank pages dropped and the scan assembled into one clean file
Data
- Kitchen supplier invoices parsed line by line into their own database, each line coded to an account from a lookup table rather than by judgement
- Barcodes taken from the JSON export, because the spreadsheet export quietly strips their leading zeros
Engineering decisions
Connect before you replace
Every product stayed until there was a real reason to retire it. Where one did deserve replacing, that was a separate decision, and three are now being replaced by a staff platform we built.
The person keeps the keys
Scripts ride on a session someone logged into by hand. They never see a password, and card-shaped fields are dropped the moment a response is parsed.
Reconcile before you trust
Each day of sales is written as a whole and checked three ways, independently, so a short day shows up straight away.
Refuse rather than guess
Invoice coding has to reconcile to the invoice's own VAT footer. When it doesn't, the tool refuses to propose a posting and a person looks at it.
Outcome
The connections run as part of the working week. Sales and timesheets are pulled and reconciled, supplier invoices are coded from a table, starter forms go out for signature already filled in and HR records are read straight from the source.