Our client was winning work in one set of systems and retyping it into another before anyone could start on it. We closed the gap in three phases, from a single automated flow to a service that keeps both sides in step.
The challenge
Like most professional services firms, our client ran one set of systems for winning work and another for delivering it. Quotes and pipeline sat at the front, in a quoting tool and a CRM. Delivery sat at the back, in the practice management platform holding projects, stages, fees, timesheets and invoices, with a finance system and a file server alongside it.
Between them sat a person with both screens open. They read the won job on the left and typed it into the right: the client, the contact, the site address, the agreed fee, the scope broken into billable stages, the next project number, the job folder on the file server. It happened under pressure, because nothing could be scheduled, booked against or invoiced until it was done.
Four problems followed from that, and the firm recognised every one of them.
- Jobs sat won but not created, while delivery teams had nothing to book their time against.
- Project numbers were read by eye from a folder listing, or left to a counter that could hand the same number to two jobs started minutes apart.
- Details were typed once and then drifted. A client changing address, or a fee being renegotiated, never reached the delivery system at all.
- Nobody could say with certainty which jobs had made it across. There was no list, only the admin team’s memory.
The firm was also not starting from nothing. Its delivery platform already held around 2,460 projects created by hand over years, each in whatever shape the person creating it chose. Anything we built had to reconcile with that history rather than work around it.
The pattern
Every phase does the same four things, whatever the systems are. What changes is how much machinery each step needs.
- Watch. A job crosses the line: a quote is accepted, a deal is marked won, a project is opened. That event starts everything, and nothing runs before it.
- Resolve. Ask whether the delivery system already holds this job, first by a reference we stamp on our own records, then by business attributes. Two matches stop the record.
- Reconcile. Create what is missing. Where it already exists, compare field by field and write only what genuinely moved. Leave everything else alone.
- Record. Log every record with the identifier the destination gave it, so the run can be repeated safely and anyone can see afterwards what happened.
What we did
We started with the smallest useful piece: one flow, running end to end on the firm’s own records, before agreeing what the rest would look like. It is a cheap way to find out what the systems really do, as opposed to what their documentation says, and it turned up things that changed the plan for everything after it.
Each phase was then sized to what it actually needed rather than to a house architecture. The first is a scenario an administrator can open and read for themselves. The third is a deployed service with an audit database behind it. Neither would have been the right answer in the other’s place.
- First flow. A scenario on the low-code automation platform the firm already paid for. It checks new projects against the finance system on a schedule, creates the ones that are missing and skips the rest. It is still running as built.
- Win to project. A scripted workflow triggered by an accepted quote. It allocates the next number, copies the job folder from the template, creates the project, and builds a stage per billable item with its own fee.
- Continuous sync. A deployed integration service, monitored and audited. Four independent, re-runnable flows reconcile organisations, people, projects and the links between them.
Knowing what already exists
The obvious design, “give me the records that are not in the other system yet”, carries a trap. The mechanism that prevents duplicates also makes every existing record invisible, so a change can never reach one. We replaced it with a question asked per record: resolve the job by a reference stamped on records we created, then fall back to business attributes such as a company name or email domain, a person’s email address, a project name. A record matching two things stops and is reported rather than guessed at, because writing to the wrong project is silent and nobody finds it later.
Writing only what moved
Source systems mark a record updated when any field changes, including the many that nobody maps. Every candidate is compared field by field against what the delivery system currently holds, and only real differences are written. Where the source is blank and the destination is not, the destination wins: blanking a field somebody filled in by hand is worse than being briefly out of date. Some fields are never synced at all, being the delivery platform’s own business rather than the CRM’s.
Surviving a bad run
Every flow is safe to run again. Each record is logged with the identifier the destination assigned it, so a run interrupted halfway is re-run rather than untangled. Where a record cannot be completed properly, such as a job with no client attached or a fee the platform will only accept on a stage rather than on the project, it is held back and reported instead of created half-finished. Most delivery platforms will not let you delete a project once it exists, so a wrong one has to be repaired in place.
Leaving the judgement alone
Status, templates and anything else genuinely requiring a decision stay with the admin team, by agreement rather than by omission. We wrote down, field by field, what would fill itself and what would stay manual, and reviewed that list with the people doing the work before building anything. The integration does the typing, not the thinking.
No phase needed a new platform. Each runs against the systems the firm already had, through their own interfaces, which is also why the third could start from what the first two had already settled.
The impact
By the time an administrator opens the delivery system, the job is already there: numbered, named, addressed, with its stages and fees in place and its folder created on the server. What remains is the work that needed a person, such as confirming a status, choosing a template, or filling in a contact the source never carried.
The two sides now stay in step rather than agreeing once. A fee that moves, an address that changes, a person moving firms: each reaches the delivery platform on the next run instead of waiting to be noticed by somebody.
Numbers and folders are allocated in one place, so two jobs cannot take the same number and the folder always matches the project. And there is now a list. Every record that crossed is logged with what happened to it and when, which means a job that did not make it is visible the same day, and a question about any project has an answer that is not somebody’s recollection.
The capacity that went into retyping went into checking instead. The later phases also share a runtime we maintain, covering the run loop, the audit trail, authentication and retries, so each new flow is a matter of the firm’s own rules rather than plumbing built again underneath them.
