Case study: answering inbound leads in minutes

A walkthrough of the Inbound Lead Qualifier kit, which runs on an event not a clock: the access it needs, why a trigger beats polling, and what it costs.

Most kits in the directory run on a clock. Inbound Lead Qualifier is one of the few that runs on an event, and that makes it the clearest worked example of when a webhook trigger is the right answer.

As with the support triage walkthrough, this is an implementation study rather than a customer story. No invented companies, no invented conversion figures. The numbers are from /pricing or arithmetic you can check.

The job

The kit's own job sentence: *qualifies new inbound leads, files them in the CRM, and drafts the first reply within minutes.*

"Within minutes" is the whole design constraint, and it is what rules a schedule out. In inbound sales, speed to first response is the variable that moves outcomes most, and an hourly sweep spends 59 of every 60 minutes not responding.

Why this one is event-driven

Compare the two ways to build it, on a day when 4 real leads arrive and each check costs about 6 tool calls:

The trigger does **less work than the hourly schedule and reacts faster than the minute-by-minute one.** That is unusual, because latency is normally bought with cost. It happens here because polling spends its budget discovering that nothing happened, while an event-driven worker does not run at all on a quiet day.

The top two rows are not merely wasteful, they are unaffordable: Free allows 500 tool calls a day and Pro 5,000.

The loadout

No calendar, so it cannot book anything. No files. Two apps, both needed, nothing spare. The app firewall grants each level explicitly, and either can be narrowed to Read later, in which case the worker keeps running and records on its receipt what it could not do.

Wiring the trigger

The webhook URL is reachable by anyone who learns it, so each trigger is signed with a secret that the calling system includes, verified before anything runs.

Two operational details worth planning for on day one:

• Secrets rotate. When one does, the sending system has to be updated. A stale secret shows up as refused calls rather than as silent success, which is the failure mode you want.
• The wire format is disclosed rather than magic, so a form provider that has never heard of WorkerKit can be configured to call it.

The safety net nobody thinks about

Here is the mistake worth avoiding: shipping the trigger alone.

Triggers travel over a network, and networks drop things. The sending system goes down, a payload arrives malformed, a run errors. **A worker with only a trigger has no way to notice it was never called.** The failure is silent, and in inbound sales a silent failure is a lead nobody answered.

So pair it: the trigger handles leads as they arrive, and a low-frequency schedule sweeps for anything the trigger missed. Twice a day is enough. That costs about 12 extra tool calls and converts a silent failure into a late response.

Dynamic Focus-Time Optimizer is the same pattern in the directory: it runs on demand, on a schedule and on events.

What it costs

Event-driven workers are the cheapest shape to run, because they scale with real work rather than with the clock:

A team taking 80 inbound leads a day can run this on the Free plan. What pushes an account to Pro is usually headcount of workers and log retention rather than this one worker's volume.

Model tokens are billed separately at provider list price with no markup, from the wallet or your own key.

Where it should stop

• Sending, versus drafting. A drafted first reply that a person sends is a very different risk posture from autonomous outbound to a stranger. Start with drafts.
• Qualification that encodes bias. "Qualifying" a person against criteria deserves scrutiny that a kit cannot supply. Review what the instruction actually scores on.
• Enrichment from outside sources. This kit works from the lead and your CRM. Pulling in third-party data about a person is a separate decision with its own privacy consequences.
• Very low volume. Under a handful of leads a week, a human reads them faster than you will tune the worker.

The reasonable objection

Two versions, and the second is the serious one.

"Faster is not better if it is worse." Speed to first response is easy to improve by sending something generic quickly, which is not the same as responding well. A worker that answers in ninety seconds with something that misreads the enquiry has optimised the metric and damaged the thing the metric was a proxy for. The mitigation is that this kit drafts rather than sends, so the speed you gain is speed to a prepared reply, and a human still decides. If you promote it to autonomous sending, you have taken on this risk deliberately and should measure reply quality rather than only response time.

**"Qualifying a person is a judgement with fairness consequences, and a kit cannot supply that judgement."** This one deserves more than a mitigation.

"Qualification" sounds like a neutral sorting operation and is not. It is a system deciding which people get attention, using signals that correlate with things nobody intended to sort on: company size correlates with geography, writing style correlates with whether English is someone's first language, email domain correlates with employer and therefore with a great deal else. A worker applying those consistently at volume does not introduce the bias, it industrialises whatever bias the instruction encodes, and it does so invisibly, because each individual decision looks defensible.

Three things follow, and none of them is "the model handles it":

• Read your own instruction as a scoring rubric, because that is what it is. If it says to prioritise by company size or seniority, you have written a policy about who deserves a fast reply, and that policy should be one you would defend out loud.
• Prefer routing over ranking. Sorting enquiries into categories a human then works is materially different from assigning a quality score that determines who gets ignored.
• Never let it close the door. A low-qualified lead should still receive a reply. Qualification deciding order is defensible; qualification deciding whether a person is answered at all is a decision to make consciously, in the open, with someone accountable for it.

The honest position: this is a legitimate use of a worker, and it is the kit in this walkthrough where the instruction most deserves a second reader who was not the person who wrote it.

The fleet it belongs to

One narrow worker per job, rather than one broad worker:

Three workers, three keys, three access grants, each switchable off without touching the others. Free allows five.

FAQ

Why use a webhook trigger instead of a frequent schedule?

Because it is both faster and cheaper. A trigger responds in seconds and only runs when something happened, where a 15-minute schedule responds up to 15 minutes late and spends tool calls all day discovering nothing arrived. Polling only wins when there is no event to subscribe to.

Do I still need a schedule if I have a trigger?

Yes, as a safety net. Triggers travel over a network and networks drop things: a worker with only a trigger cannot notice it was never called. A low-frequency sweep, twice a day, turns a silent miss into a late response for about a dozen extra tool calls.

What access does the Inbound Lead Qualifier need?

Write on email so it can draft the first reply, and Write on the CRM so it can file the lead. Nothing else, and either can be narrowed to Read later with the worker still running on what is left.

Does it email leads automatically?

It drafts. Whether a draft is sent automatically is a separate decision worth making after reading a few weeks of receipts, because autonomous outbound to a stranger is a materially different risk from an internal draft.

What plan can run this?

Free handles up to roughly 80 leads a day within its 500 tool calls. Because an event-driven worker scales with real work rather than the clock, it is one of the cheapest shapes to run. Model tokens bill separately at list price with no markup.

How is the webhook secured?

Each trigger is signed with a secret the calling system includes, verified before anything runs. Secrets can be rotated, and a stale one produces refused calls rather than silent failures.