Work · 01 Lead bridge · Records and tracking
Two CRMs that could not say when anything changed.
A field-services company ran its sales work across two CRMs and a job board. New leads arrived through six routes. A website form. A phone agent. A booking tool. A shared mailbox. Alert emails from an advertising platform. An app the field team used. Each lead had to arrive once, as one record, in the right system. Each time a job moved a stage on the board, three things had to happen once and only once. A date stamp. A due date. A new record in the operations and finance systems.
- Client
- A field-services company. Not named.
- Layer
- 1 of 4. Records and tracking.
- Measured
- 2026-09-11, from the build records.
- Where
- Remote. On accounts the client owns.
- Published
Service Lead intake & pipeline automation Work-management setup & migration How an engagement runs
Neither CRM could say when anything had changed. The first one, as it was set up, sent no message out that the automation tool could listen for. The second one offered a connection that reached only two kinds of record. It did not reach any of the records the later stages had to write.
01 The constraint
What was actually hard.
Not the number of workflows. Sixteen workflows are a week of clicking. The hard part was that one lead could arrive twice from two routes at once. It could be updated in one CRM while it was being created in the other. A retried message could deliver it a third time. Through all of that, the system still had to produce one record, one date stamp and one notification. And it had to do so with no signal from either CRM to work from. The obvious cheaper answer is a ready-made template on a no-code automation product. It fails at the first requirement, not the tenth. A template has to be started by a signal, and there was no signal to start it.
02 The mechanism
How it works.
Everything rests on one agreed lead record and one shared intake step. The parts that face each lead source are thin. The shared step is where the guarantees live.
- One agreed lead record, before anything else. All six sources are converted into the same shape. The shared step never learns which source sent the lead.
- The rule for spotting a duplicate was agreed before the first line was built. Match on the phone number first, then the email address, then the cleaned-up street address. This went into the written scope. It was not discovered later in daily use.
- Every incoming message carries a duplicate guard. The guard is the call number, the booking number or the message number. It is checked against a log before anything is written. A message delivered twice creates no second record.
- For the CRM that sent no messages out: the system asks it five times a day whether anything changed. Five was chosen to fit the vendor's usage limits and the delay the client was willing to accept. A second piece supplies the write path the connection did not offer.
- One written rule decides who wins a disagreement. If the two systems disagree about money, the finance system wins. If they disagree about the stage, the job board wins. Without that rule, the two systems correct each other forever.
- A stage is stamped once. Before writing, the system reads the stamp already there and leaves a marker. Its own write cannot set itself off again.
- Records are matched across systems through a lookup table. The board's own linking feature was deliberately not used. That is why the build survived a move to a new platform with every record still matched.
- One error path, attached to every branch. It raises an alert a person can read, with a link straight to the run that failed.
Six lead sources feed thin converters which attach a duplicate guard and one agreed lead shape. One shared intake step cleans, locates, checks duplicates and scores each lead, then writes to CRM A and CRM B or to a review board for a person. CRM A sends nothing out, so a status poll five times a day reads back into the step. CRM B reaches the stage engine through a webhook. Stage moves on the pipeline board drive the stage engine, which stamps each stage once and writes to the operational and finance systems. Tracking tables and one error path sit under both the step and the engine.
03 The figures
What it measured.
Each figure carries the date it was taken. A number without a date is not on this page.
| What was measured | Value | Measured |
|---|---|---|
| Workflows | 16 built · 14 active | 2026-09-11 |
| Functional nodes | 244 | 2026-09-11 |
| Hand-written code | 67 code steps · 1,273 lines | 2026-09-11 |
| Tracking tables | 6 tables · 118 columns | 2026-09-11 |
| Lead sources using the one shared step | 6 | 2026-09-11 |
| Runs in the seven days of history the platform keeps | 262 of 262 succeeded | week ending 2026-09-11 |
Asking the CRM five times a day uses up part of the plan's monthly allowance, whether or not a lead is waiting. That allowance is billed every month. I put it on the proposal as its own line rather than hiding it in the price. A client should see what connecting a closed system costs them. If the CRM ever adds a webhook, the line goes away. Until then, the cost is the honest price of the bridge.
04 Doing it again
What it would take to do again.
The reusable part is the shared intake step, the agreed lead record and the three tracking tables. A second client changes three things. The step that writes to their CRM. The rule that finds a location. The map between their field names and mine. Three things are decided with each client before any work starts. How a duplicate is spotted. Who wins a disagreement. What each stage move should cause. Those three decisions become the tests the build has to pass.
A fit
Two or more places leads come in from, and at least one system that cannot announce a change.
Not a fit
One lead source into one system that already connects to it. A ready-made template does that, and it should.
Up against a constraint like this one?
Thirty minutes, no prep, no pitch. Bring the thing that is slow; if it is not a fit, I say so and point you somewhere useful.