Skip to content
Vlad Levitsky Book a free callBook a call
Vlad Levitsky
Book my free 30-min call

WorkCase study · 01

I designed one lead platform for every form on the TelcoBridges website, from first click to CRM.

The Lead Engine sends each lead to up to four business systems, and it’s built so an outage in any one of them doesn’t lose an accepted lead.

Simulate a failure See the wiring
Role
Program lead: requirements, architecture decisions, AI-agent direction, production QA
Window
Sep → Oct 2026 · under six weeks to CRM go-live
Stack
WordPress, Cloudflare Workers + Queues + Durable Objects, Customer.io, Salesforce, Odoo, Google Ads, Zapier, Zoom, Usercentrics
Status
Live

01The problem

Before this project, every offer on the website had its own one-off wiring.

TelcoBridges, a B2B telecom software company, had a website lead journey for every kind of intent: product trials, sales calls, contact requests, landing pages, gated resources and webinars. Most ran on legacy Pardot form iframes. The sitewide contact widget was a floating JavaScript popup that embedded another Pardot iframe. Product-trial provisioning was handled separately, and every new offer meant another one-off integration.

Google Ads optimized on page events, because page events were all it could see. And the business needed six things at once, without pausing lead intake:

  • One platform for every form, in four languages
  • A product trial that creates a real software license while the visitor waits
  • Clean CRM records: no duplicates, no overwrites
  • A move from Salesforce to Odoo without stopping lead intake
  • Real leads reported to Google Ads as conversions
  • No vendor credentials in the browser, and no duplicates from retries

So the job was one platform for all of it, designed so a downstream outage doesn’t lose an accepted lead.

The shape of it

Before: five website entry points, each wired on its own. Contact and landing-page forms were Pardot iframes, the site widget was a JavaScript popup embedding another Pardot iframe, trial sign-ups reached the licensing system on a separate path, webinars had a one-off Zoom connection, and Google Ads saw only page events THE WEBSITE THE SYSTEMS Trial sign-up Contact sales Site widget Landing pages Webinars Pardot Salesforce Licensing Google Ads Zoom separate iframe JS + iframe page events one-off sync

BeforeEvery offer had its own wiring: legacy Pardot form iframes, a floating JavaScript widget that embedded another Pardot iframe, one-off integrations per offer, and trial provisioning handled separately. Google Ads only saw page events.

After: the same five entry points share one form engine and one edge API; a queue fans each lead out to Customer.io, Salesforce and Odoo, trial sign-ups also reach the licensing system, and Customer.io feeds Google Ads and Zoom THE WEBSITE THE PLATFORM THE SYSTEMS Trial sign-up Contact sales Site widget Landing pages Webinars Edge API validates dedupes Queue retries dead-letter Licensing trial only Customer.io marketing Salesforce during the move Odoo new CRM Google Ads real outcomes Zoom via Zapier

AfterOne form engine, one edge API, one queue. Each lead fans out to the systems that need it, and only real outcomes reach Google Ads.

02The wiring

Each kind of visitor takes a different route through the platform.

A trial needs a license before anything else, a sales request only becomes a sales lead at step two, and a webinar sign-up has to end up in Zoom. Pick a visitor and send a test lead to see its route.

Diagram of the lead platform: a website form, an edge API, a queue, and the systems each lead is delivered to.

Route: Product trial

The license is created first, while the visitor waits, so they get their serial number on the thank-you screen. Marketing and the CRMs follow from the queue, and if any of them is down, the license still stands.

  1. Website form submits
  2. Edge API validates it and blocks bots
  3. Licensing dashboard creates the license
  4. Queue accepts the lead
  5. Customer.io, Salesforce and Odoo receive it independently
  6. Customer.io uploads the conversion to Google Ads

Simplified from the production system I designed and directed.

03Lead trace

Here’s what the platform does on a bad day, step by step.

Pick a failure below to see which systems are involved and how the platform handles it, with a plain-English summary at the end.

Simulate a failure

  1. Formsubmitted
  2. Edge APIchecked
  3. Licensingcreated
  4. Queuelead safe
  5. Customer.iodelivered
  6. Salesforcedelivered
  7. Odoodelivered
  8. Google Adsuploaded
trace · product trialcomplete
  1. form.submitvisitor asks for a product trial
  2. edge.validateok · every field checked server-side; the browser isn’t trusted
  3. edge.botcheckok · bot check passed (trial form only: it creates a real license)
  4. lab.licenseok · license created while the visitor waits
  5. queue.acceptok · lead queued → visitor sees their serial number
  6. marketing.identifyok · Customer.io: profile, event and license email
  7. crm.salesforceok · no existing record → new lead, UTM campaign attached
  8. crm.odoook · new lead created, independently of Salesforce
  9. ads.uploadok · conversion uploaded server-side, consent signals attached

An illustrative trace, simplified from the live system.

In plain English

One trial sign-up became a real license while the visitor waited, then reached Customer.io, Salesforce and Odoo from the queue, plus one conversion for Google Ads. Nobody copied anything by hand.

04Decisions

Here are the five decisions I kept for myself, and the trade-off behind each one.

AI coding agents wrote a lot of the code. I decided what they were allowed to touch, and these are the calls I didn’t delegate.

  1. D-01

    Only a completed request becomes a lead.

    Decision
    An email-only first step reaches marketing automation but creates no sales lead. Only a completed step two does.
    Why
    Sales reps don’t chase half-finished forms, and the CRM only counts completed requests.
    Trade-off
    More states to design, test and explain to sales.

  2. D-02

    When in doubt, ask a human.

    Decision
    If one email returns multiple matching records in the CRM, the system creates a review task instead of picking one. Existing records are never overwritten.
    Why
    A wrong merge is worse than a short delay. In one live case, the system found multiple matching records and opened a single review task instead of guessing.
    Trade-off
    Someone owns a small review queue.

  3. D-03

    Migrate without a second source of truth.

    Decision
    Odoo gets each lead straight from the website event, with its own queue, retries and replay. It went live through gated phases (off → shadow → live) in a single day. Salesforce stays on alongside it, and the nightly sync between the two can link matching records but never creates new leads.
    Why
    Copying leads over from Salesforce would copy its duplicates too. In shadow mode, test leads were created silently before any rep saw one. Retiring Salesforce later needs no Odoo redesign.
    Trade-off
    Two CRMs run in parallel for a while, with counts to reconcile before Salesforce goes.

  4. D-04

    Credentials never touch the browser.

    Decision
    The page only renders the form. Validation and bot checks run at the edge, and provider keys sit in Cloudflare’s secret store, never on the page.
    Why
    Nothing on a public page can leak a key or write to the CRM, and a broken form can’t take the site down. The Odoo credential was typed once, straight into the secret store; no AI agent, chat or file ever saw it.
    Trade-off
    Every field needs a server-side rule, so adding one is a deliberate change with its own test.

  5. D-05

    Consent means what the visitor said.

    Decision
    An unchecked newsletter box never unsubscribes anyone. Consent is stored with a server timestamp and the version of the wording shown. Ad-consent signals travel with each lead.
    Why
    Consent that drifts from the visitor’s choice turns a tracking setting into a real liability for the business.
    Trade-off
    Newsletter consent, the privacy notice and email-tracking consent stay separate, so there is more to keep straight.

05Incident

Here’s how I found, fixed and proved a quiet consent failure.

A vendor changed how it stored consent, and ad-conversion uploads to Google Ads started failing while the website looked perfectly normal.

  1. 01 Early October

    The change

    A vendor changed how it stored consent in the browser. The website’s own code hadn’t changed.

  2. 02

    The symptom

    Ad-conversion uploads to Google Ads started failing. Forms and leads kept working, so nothing looked broken on the site.

  3. 03

    The diagnosis

    Traced across the browser, the middleware and the ad API, down to the one place still reading the old format.

  4. 04 Oct 13

    The fix

    Two narrow layers: read the new format at the source, and pass the ad platform only values it accepts. The core contract between systems didn’t change.

  5. 05 Oct 13

    The proof

    A real production registration, end to end, and an accepted Google Ads upload.

    Verified in production

The leads kept flowing the whole time. The conversion signal on its way to Google Ads was the part that broke, which is the kind of failure that stays quiet unless someone reads the delivery logs.

06Receipts

Here’s what went into the build, number by number.

These numbers cover the scope and delivery of the build, and each one has a receipt with its source and time window.

8

form journeys on one platform

Show receiptHide receipt
Source
Form registry, project records
As of
Oct 2026
Values
Lab trial, two-step sales, contact, get-in-touch, landing page, two lead magnets, webinar
Note
Adding a new form only takes a config file.

4

languages: English, French, Spanish, Portuguese

Show receiptHide receipt
Source
Project records
As of
Oct 13, 2026
Note
Every form shows in the visitor’s language, all running on the same backend.

~1,600

automated tests

Show receiptHide receipt
Source
Worker and consumer test suites
As of
Oct 13, 2026

~26

production deploys, each with a rollback target

Show receiptHide receipt
Source
Deploy log
Window
Sep 4 → Oct 13, 2026, about six weeks
Note
Each one recorded with what changed, what didn’t, and the exact way back.

0

vendor credentials in the browser

Show receiptHide receipt
Source
Approved architecture, production setup
As of
Oct 13, 2026
Values
No Customer.io, Salesforce, Odoo, licensing or Zoom keys on the page
Note
The page talks to one same-origin API. Provider keys stay server-side.

< 6

weeks from approved architecture to Odoo going live

Show receiptHide receipt
Source
Project timeline
Window
Sep 4 → Oct 9, 2026
Note
Odoo went live through gated phases (off → shadow → live) in a single day.

How it shipped

Two specialized AI coding agents worked under a written change-control policy with six risk classes, tests before every release and a rollback plan for every deploy. I owned the requirements, every production approval and the live checks.

07What this means for you

If a lead in your company touches more than two tools, it’s probably taking a route nobody has drawn.

Bring one lead’s journey to the free 30-minute call, and I’ll map the route, show you where it leaks and tell you what I’d fix first.

Book my free 30-min call
Next · 02 The Search Engine Organic search nearly tripled in five months, and more than half of that traffic now comes from the Learning Center pages I created. Next case study: The Search Engine

All work