CASE 01 · Website + lead routing

I rebuilt the website so routine drop-offs stopped reaching me like business leads.

A business asking about an office pickup and a person scheduling a small drop-off used to trigger the same phone alert. I had to open both to learn which one needed me. The rebuilt path separates them before the alert and carries the useful context into the next system.

8 minute case studyReal systemNames and identifiers removed
REAL PUBLIC PAGE · NOT THE HOMEPAGE
Control Alt Recycle Items We Accept page with separate pickup and drop-off actions
The accepted-items page gives a business an obvious pickup route and gives a community customer a separate drop-off route.
EleventyNetlifyCloudflareCalendlyZapierResendGoogle Analytics
2

different jobs separated before the owner alert

Business pickup and community drop-off

3

explicit lead-value tiers

1, 10, and 50 in the current rules

6

notification-path tests

Including honeypot and nested payload cases

0

runtime AI decisions

The production routing path is deterministic

The website was creating work before the real work even started.

The old site treated two very different requests as roughly the same event. A business might need a pickup, access planning, data-destruction documentation, and a response from me. A community drop-off usually needs to know what we accept, which items have fees, and when to arrive.

Both produced the same kind of phone alert. I opened each alert, figured out what it was, and handled appointment scheduling that did not require an owner. That is a small interruption until it happens over and over.

The rebuild started with the handoff. The site has separate service, location, accepted-item, data-destruction, and drop-off pages. The form records the page, lead type, and source so the next person does not have to reconstruct them.

A drop-off can complete the preflight and book without me.

A community customer can check accepted and fee-based items, enter a rough item list, acknowledge the possible fees, answer the Apple-device question, and continue to Calendly. The form saves first. Calendly receives the name, email, and item list instead of making the customer type them again.

A business visitor can leave the consumer path and open the pickup review form. That form asks for the details that change the work: equipment, access, location, data needs, and documentation.

  1. 01

    Enter through a page with a job

    Service, location, accepted-item, and drop-off pages do not pretend every visitor has the same intent.

  2. 02

    Choose pickup or drop-off

    The contact path can preselect the likely route, but the visitor can correct it.

  3. 03

    Keep the source context

    Lead type, page, landing page, referrer, campaign fields, analytics ids, and a generated lead id travel with the submission.

  4. 04

    Save before scheduling

    The drop-off record is written before Calendly opens. A failed save leaves the customer on the form with a retry message.

  5. 05

    Send a useful alert

    The notification groups contact, equipment, routing, and attribution fields instead of flattening the request into one generic message.

Nobody should discover a disposal fee after loading the car.

The fee acknowledgement is an operating rule. Some electronics are free to drop off and some have fees. The customer sees those categories before choosing a time.

That prevents a predictable argument at the warehouse and gives the customer a chance to decide before driving over. I have not measured the reduction in fee disputes, so I am not claiming one. I can show the behavior the system now enforces.

The boring parts are what keep the lead from disappearing.

All pages use one Netlify form name so one downstream Zapier trigger can receive every submission. Hidden fields distinguish the actual request, page, lead type, score, and source. That is easier to maintain than a separate automation for every landing page.

Cloudflare sits in front of Netlify. The forwarded request has to preserve the POST body, which is an easy place to break the form. A preview test on Netlify does not prove the public domain works. Form changes still need one end-to-end submission through the public route.

The browser gives analytics 900 milliseconds to finish its callback, then resumes submission. Notification delivery uses an idempotency key when the lead has an id. Honeypot submissions are dropped before Resend sees them. Submitted HTML is escaped.

  • A failed Netlify save does not open Calendly.
  • A slow analytics callback cannot hold the customer indefinitely.
  • A failed Resend request throws with a bounded error response.
  • Six tests cover lead types, nested payloads, value metadata, allowlisting, URL-encoded submissions, and honeypot rejection.

I know which owner steps disappeared. I do not have an hours-per-month number.

The customer now handles fee review and appointment booking. I no longer need to open the same-style alert to determine whether a routine drop-off needs me. The name, email, and item list also move into Calendly without being re-entered.

Nobody recorded average alert-review time, scheduling time, or monthly self-serve volume before the change. A precise savings claim would be fiction.

WHAT I WOULD NOT CLAIM

Here is what remains unmeasured or unresolved.

Next: ITAD intake + routingAn item identity is only the start. The app still has to decide where the thing goes. →