WorkerKitInbound lead qualification with AI workers
How Inbound Lead Qualifier reads an inquiry, updates the CRM and drafts a reply, with event triggers, review boundaries and cost planning.
Published by WorkerKit. Updated .
Inbound Lead Qualifier creates an AI worker that reads an inquiry and CRM context, grades the lead with cited reasons, files the contact and note, and saves a first-reply draft. It runs on demand or from a supported inbound event. A person reviews and sends the reply.
As with the support triage walkthrough, this is an implementation study rather than a customer story. No invented companies or measured conversion figures are claimed here. The usage tables below are planning arithmetic with stated assumptions, not measured kit costs. For the installation procedure and the later deal handoff, use the inbound-sales guide.
The job
The job has three outputs to check: a grade supported by the inquiry, the right CRM contact and note, and a reply draft grounded in what the lead actually asked. Preparing a draft is different from responding to the customer. Delivery time still depends on event delivery, the run and the person's review.
The worker persists after that inquiry is handled. Its instructions, app grants and limits remain ready for the next request; persistence does not mean it polls continuously. That is the basis for building an AI workforce around useful jobs.
Why this one is event-driven
To compare event delivery with a polling design, assume four inquiries a day and six tool calls per run. These are illustrative inputs to the calculation. Actual runs can make different numbers of calls; the published qualifier supports events and on-demand runs, not a polling schedule.
| Design | Runs a day | Assumed tool calls a day | Delay before a run can start |
|---|---|---|---|
| Poll every minute | 1,440 | 8,640 | Up to a minute between checks, plus service delays |
| Poll every 15 minutes | 96 | 576 | Up to 15 minutes between checks, plus service delays |
| Poll hourly | 24 | 144 | Up to an hour between checks, plus service delays |
| One event per inquiry | 4 | 24 | Event delivery and service delays |
Events remove the scheduled wait and the empty polling runs in this design. They do not guarantee a response deadline. Retries, duplicate inquiries, failed attempts and additional context reads change the cost. Compare observed usage, burst rate and the rest of your account's work with current plan limits.
Published WorkerKit plans and prices apply to shared cloud.
The loadout
| App | Granted operations | Why they are needed |
|---|---|---|
| Read and search threads; create drafts and reply drafts | Read the inquiry and prepare a reply; no send operation | |
| CRM | Search and read; create or update a contact; add a note | Match the inquiry to an owned record and save the qualification |
The kit uses email and CRM, with CRM access restricted to owned records. It does not book meetings or send the customer reply. Inspect the actual operations in the install preview: a broad Write label alone does not explain the boundary. Narrowing access can prevent the job from completing; inspect the receipt and resolve refusals before enabling event runs.
Wiring the trigger
The sender signs each delivery with its secret. WorkerKit verifies the signature and timestamp before starting work. Keep the secret on the sending server; send the signature in the request, not the secret itself.
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.
Give a person responsibility for comparing source inquiries with completed records and unresolved runs at a cadence that fits the response target. For a missing inquiry, inspect the CRM and drafts before requesting an on-demand run so a retry does not create duplicate work.
The published qualifier does not advertise a scheduled mode. If you need an automated reconciliation job, define and authorize it separately, including how it recognizes work already completed. A run record can reveal a failed run; it cannot prove that an event which never arrived should have started one.
What it costs
Holding the planning assumption at six calls per inquiry gives:
| Inquiries a day | Assumed runs | Assumed tool calls a day |
|---|---|---|
| 4 | 4 | 24 |
| 25 | 25 | 150 |
| 80 | 80 | 480 |
| 200 | 200 | 1,200 |
These totals are not throughput guarantees or plan recommendations. Leave room for retries and other workers, check rate limits as well as daily limits, and measure calls on your own inquiries.
Model tokens are billed separately at provider list price with no markup, from the wallet or your own key. Add platform charges, any metered app charges, review and correction to measure cost per acceptable result. A cheap draft that takes a long time to repair may be a poor result.
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.
- Low volume. Doing intake manually may take less effort than maintaining the rubric and reviewing automated results. Compare the actual work.
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. This kit has no email send operation. Automated sending would be a separate job and permission decision, evaluated against reply quality as well as 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 workforce it belongs to
One narrow worker per job, rather than one broad worker:
| Worker | Apps | Starts on | Job |
|---|---|---|---|
| Inbound Lead Qualifier | email, crm | Event | Qualify, file, draft the first reply |
| Deal Follow-up Assistant | email, crm | On demand | Find stalling deals and draft a follow-up |
| CRM Scribe | email, meetingNotes, crm | Schedule | Keep records current without manual entry |
Each worker has a distinct job and access grant. These catalog entries do not by themselves create an automatic handoff. The inbound-sales guide starts with the qualifier and Deal Follow-up Assistant, with a person owning the handoff into an active deal. Browse kits today and request access to run them once invited.
FAQ
Why use a webhook trigger instead of a frequent schedule?
A supported event can start work without waiting for the next scheduled check and avoids empty polling runs. Actual latency and cost depend on event delivery, execution and retries. Choose a trigger that the source and worker support.
Do I still need a schedule if I have a trigger?
You need a way to notice missed work. The published Inbound Lead Qualifier supports events and on-demand runs, so use an accountable source-to-record check and recover missing inquiries on demand. Automated scheduled reconciliation requires a separately configured job that supports that mode.
What access does the Inbound Lead Qualifier need?
The qualifier needs email reads and draft creation, plus CRM reads, contact creation or updates, and notes within its owned-record scope. It has no email send operation. Review the current install preview and connect only the accounts the job needs.
Does it email leads automatically?
No. Inbound Lead Qualifier saves a draft for a person to review and send. Its email operations do not include sending; an instruction to send cannot replace a missing permission.
What plan can run this?
Compare measured calls, rate limits, required history and account-wide usage with pricing. A lead count alone cannot determine the plan, because the amount of context, retries and other work varies. Model and metered app usage also need to be included in the operating budget.
How is the webhook secured?
The sender signs each delivery using its secret; WorkerKit verifies the signature and timestamp before starting work. The secret stays on the sending server. Rotating it requires updating the sender before its next delivery.