Free kit / Speed-to-Lead Blueprint
Speed-to-Lead Blueprint Pack
Seven stages, one pipeline: capture to assigned rep in under ten seconds, with the config and the failure behaviour written down.
Related kits: the Routing Stack bundles this pipeline with the routing layer that decides who owns the lead, the Automated Lead Routing Kit is that routing layer on its own, and the Workflow Audit Kit finds where the pipeline is leaking.
The pipeline
Every form fill, ad conversion and chat message goes through the same seven stages: validation, dedupe, enrichment, scoring, routing and assignment. This pack is the buildable version of that pipeline. Stage by stage, with the keys you set and the way each stage fails.
One unified webhook endpoint accepts form fills, chat transcripts and ad conversions. Payloads get normalized and schema-checked before anything else happens. From there the lead moves left to right, then writes back and notifies.
ingress
|
v
[01 Capture] -> [02 Validation] -> [03 Dedupe] -> [04 Enrich] -> [05 Scoring]
|
v
[07 Assign] <- [06 Router] <- -----------------------------------+
| ^
| +---- conflict resolver (score or territory tie)
v
[CRM write] -> [Notifier: Slack / SMS / Email] -> [Dashboard readback]
dead-letter queue + correlation log on every hop| Stage | Name | Job | Tells you when it is wrong |
|---|---|---|---|
| 01 | Capture | Accept one event shape from every source | Event count drops or payload shape changes |
| 02 | Validation | Reject garbage before it becomes a record | Reject rate climbs above baseline |
| 03 | Dedupe | Match before create, merge with a paper trail | New record count spikes against stable traffic |
| 04 | Enrich | Firmographic and intent context in parallel | Provider timeouts, cache hit rate falls |
| 05 | Scoring | One fit and behaviour score, 0 to 100 | Score distribution shifts without a traffic change |
| 06 | Router | Territory, load and availability in one pass | Unresolved owners, territory conflicts queued |
| 07 | Assign | Hand to a rep or queue, start the SLA clock | Notification not acknowledged inside the window |
Stage-by-stage build guide
Capture gateway
Inputs: website and landing page forms, webinar and content downloads, Facebook Lead Ads, Google Ads conversions, LinkedIn Lead Gen Forms, Drift or Intercom chat transcripts.
Config: one public endpoint. Normalize every source into your internal event contract before anything downstream reads it. Preserve event_id, correlation_id, idempotency_key, source_system, source_record_id, utm_source, utm_campaign. Store the raw payload alongside the normalized one.
Guardrail: HMAC signature verification on the endpoint before processing. Unauthorized test submissions are a real source of junk records.
Failure behaviour: non-2xx to the provider, payload persisted for replay, alert if the error rate moves. Budget 150 ms.
Validation
Inputs: the normalized event.
Config: schema and sanity checks. Required fields present. Email format valid. Consent captured where regulation needs it. Enum fields limited to allowed values. Budget and urgency checked against the list you route on. Session and UTM context passes through untouched.
Rule: reject to a review queue, do not write a partial record. A contact created with an empty required field is worse than no contact, because the follow-up sequence will fire on stale data.
Failure behaviour: reject count and reasons logged per field, dead-letter queue holds the payload. Budget 100 ms.
Dedupe (Redis + fuzzy)
Inputs: validated event.
Config: deterministic match on email and phone. Fuzzy match on company name and normalized domain. Redis keyed on normalized values for the lookup, target under 100 ms. Merge strategy per field: first non-empty wins for contact fields, latest wins for behavioural fields, never overwrite a human correction.
Order of operations: search contact by email, search company by domain, search open deals by contact and pipeline, update when found, create only after the search clears. Store every object ID against the original event.
Failure behaviour: ties and near-matches go to the conflict resolver, never auto-merged. Every merge logged with its inputs. Budget 100 ms.
Enrichment
Inputs: deduped identity (email, domain, company name).
Config: parallel lookups against providers such as Clearbit and Apollo, plus LinkedIn where your licence allows it. Cache keyed on domain with a TTL you can defend. Warm the cache on your top 200 domains before cutover.
Rule: a lead never waits on a lookup. Hard timeout per provider, then fall through to cached data and mark the record enrichment: partial.
Failure behaviour: circuit breaker per provider, staggered re-enable, alert when the cache hit rate falls below your floor. Budget 3000 ms including timeout.
Scoring
Inputs: firmographic fit, behavioural interest, source, campaign, prior interaction history.
Config: one 0 to 100 score. Keep the inputs visible on the record: fit component, behaviour component, and the rules that fired. Retrain on conversion outcomes so routing decisions improve as the dataset grows.
Rule: if a model classifies messy text, force it to choose from a closed list and validate the choice: sales_priority, sales_standard, founder_review, nurture, reject_spam, manual_review_missing_data. Store the raw answer beside the summary. Raw pain tells you what the buyer said. Summaries compress, and compression loses edge.
Failure behaviour: score outside 0 to 100 or missing inputs routes to manual_review_missing_data. Budget 400 ms.
Router
Inputs: score, territory, availability, existing owner, open deal status, customer status.
Config: territory rules by region, account book, segment or language. Load balancing across active reps. Account-based routing, round-robin and skill-based assignment run through the same engine so there is one place to inspect.
Rule: owner status is checked at routing time. The record cannot be trusted for it. An inactive owner ID is the fastest way to lose a lead. Log the decision: which rule, which evidence, which rep.
Failure behaviour: unresolved territory or tie goes to the conflict resolver, then to a manual queue with an SLA timer. The router keeps a dead-letter queue for anything it cannot place. Budget 250 ms.
Assign and notify
Inputs: resolved owner, lead record, context note.
Config: write to CRM, then fire the notification hub: Slack, SMS, push and email with priority queuing. Include enough context in the alert that the rep does not open the CRM to decide whether to care.
SLA escalation: if the primary rep does not acknowledge inside the window, escalate to the next rep automatically, then to the team channel. Timer state lives with the lead so a restart does not lose it.
Failure behaviour: notification failure does not roll back the assignment, it pages. Budget 300 ms assign, 400 ms notify.
Make.com scenario outline
Plain module sequence. Treat it as the shape of the build. The config above is what you copy into it. Put error handlers on every module that writes.
1 Webhook (custom trigger) receives raw payload
2 HTTP: verify HMAC signature reject unsigned calls
3 Tools: set variable event_id, correlation_id, received_at
4 JSON: parse + schema validate required fields, types, enums
5 Router A: valid / invalid
5a Data store: append rejected dead-letter record with reason
5b Router B: match or new
6 Search: CRM contact by email
7 Search: CRM company by domain
8 Search: CRM open deals by contact
9 HTTP: Redis GET normalized key deterministic dedupe hit
10 HTTP: fuzzy score company/domain near match under threshold
11 Router C: create / update / conflict
11a HTTP: Clearbit enrich parallel, hard timeout
11b HTTP: Apollo enrich parallel, hard timeout
11c Tools: merge cached fallback
11d HTTP: scoring service 0 to 100 + routing label
11e Router D: territory + load + owner status
11f HTTP: conflict resolver ties and high-value leads
12 HTTP: CRM create or update idempotency key header
13 HTTP: CRM associate objects contact, company, deal, note
14 Data store: append audit row before, after, rule, owner
15 Slack: priority alert to rep
16 SMS / email: fallback channel
17 Error handler (attached to 4,9,11a,11b,11d,12,15)
-> HTTP: alert on-call
-> Data store: append failure with correlation_id
-> route to DLQ for replayPut a token bucket in front of the CRM. Bulk operations against a 100 requests per minute ceiling will throw 429s the moment you go live with real volume. Handle it with concurrency, exponential backoff and jitter instead of a plain retry loop.
Example webhook payloads
Inbound capture (source to your endpoint)
{
"event_id": "sub_01HYT9C7M4",
"source_system": "tally",
"source_record_id": "audit_request",
"received_at": "2026-04-26T10:17:33.884Z",
"email": "ops@example.com",
"phone": "+39 051 000 0000",
"full_name": "Elena Moretti",
"company_name": "Example Srl",
"company_domain": "example.com",
"budget_range": "5000_15000",
"urgency": "high",
"pain_summary": "Form submissions create duplicate contacts and never route to an owner.",
"consent_to_contact": true,
"utm_source": "linkedin",
"utm_campaign": "revops_q2",
"raw_payload_stored": true
}Normalized internal contract (every source maps here)
{
"event_id": "sub_01HYT9C7M4",
"correlation_id": "corr_lead_01HYT9C7M4",
"idempotency_key": "lead_intake:tally:audit_request:sub_01HYT9C7M4:ops@example.com",
"source_system": "tally",
"source_record_id": "audit_request",
"email": "ops@example.com",
"phone": "+39 051 000 0000",
"company_domain": "example.com",
"budget_range": "5000_15000",
"urgency": "high",
"pain_summary": "Form submissions create duplicate contacts and never route to an owner.",
"consent_to_contact": true,
"utm_source": "linkedin",
"utm_campaign": "revops_q2"
}Post-stage record (what the CRM receives)
{
"correlation_id": "corr_lead_01HYT9C7M4",
"dedupe": {
"match_type": "deterministic_email",
"existing_contact_id": "123456789",
"action": "update_existing"
},
"enrichment": {
"status": "cached",
"sources": ["clearbit", "apollo"],
"employees": 120,
"industry": "software"
},
"score": { "total": 82, "fit": 74, "behaviour": 90 },
"routing": {
"label": "sales_priority",
"rule": "budget_5000_15000_and_urgency_high",
"owner_id": "987654321",
"owner_status": "active",
"territory": "italy_north"
},
"controls": {
"queue": "crm_revenue_events",
"retry_policy": "exponential_backoff_with_jitter",
"dead_letter_queue": "crm_failed_workflow_events",
"replay_safe": true
}
}Latency budget
Measured per stage rather than guessed at the end. Each stage gets a hard ceiling. If a stage blows its ceiling, that is the alert.
| Stage | Budget (ms) | Measured at | On breach |
|---|---|---|---|
| Capture gateway | 150 | Endpoint entry to normalized event | Page if p95 breaches for 5 min |
| Validation | 100 | Schema check start to pass or reject | Log reject reasons, alert on rate |
| Dedupe lookup | 100 | Redis GET plus fuzzy compare | Alert on cache miss rate |
| Enrichment (with timeout) | 3000 | Parallel call start to last provider back | Circuit breaker, serve cached |
| Scoring | 400 | Inputs assembled to score returned | Fallback rule-based score |
| Router | 250 | Rules start to owner resolved | Conflict resolver, then manual queue |
| Assign | 300 | Owner resolved to CRM write ack | Retry, then DLQ |
| CRM write | 900 | API request to response | Backoff, token bucket shed |
| Notification | 400 | Write ack to provider accepted | Page on-call, do not roll back |
| Dashboard readback | 200 | Write to visible on rep view | Warn, non-blocking |
| Retry and queue allowance | 2000 | Worst case single retry cycle | Dead-letter with correlation ID |
| Typical total | 7800 | Capture to acknowledged assignment | Hard ceiling 10000 |
Headroom to the ceiling is deliberate. It absorbs one retry cycle and a cold enrichment cache without failing the promise.
Alert thresholds
Thresholds are configuration. Set them before launch, write down who they page, and review them after the first month of real traffic.
| Signal | Threshold | Window | Action |
|---|---|---|---|
| Capture endpoint error rate | > 1% | 5 minutes | Page on-call, check provider delivery |
| Schema reject rate | > 3% | 15 minutes | Alert, dump reject reasons by field |
| Capture to assign p95 | > 10000 ms | 15 minutes | Warn first, page if sustained 1 hour |
| Stage p95 over budget | > 1.5x budget | 15 minutes | Warn naming the stage |
| Enrichment provider timeout | > 10% | 15 minutes | Open circuit, serve cached, alert |
| Cache hit rate | < 60% | 1 hour | Warn, review TTL and warm list |
| Duplicate records created | > 0 per hour | 1 hour | Page, freeze creation step only |
| Unresolved owner or territory | > 0 | 15 minutes | Route to manual queue, alert ops |
| Notification unacknowledged | Primary 60 s, secondary 300 s | Per lead | Escalate up the chain automatically |
| Dead-letter queue depth | > 0 for 10 minutes | 10 minutes | Page with payload and correlation ID |
| CRM 429 responses | > 0 sustained | 5 minutes | Shed load, drop concurrency, alert |
Weekly review checklist
- Every dead-letter item from the week has an owner and a decision: replay, fix, or drop.
- Duplicate merges reviewed, each one logged with its inputs.
- Escalations counted, with the rule that fired each time.
- Scoring model inputs still match the fields you capture.
- Owner roster checked against active users in the CRM.
- Latency budget reviewed stage by stage.
Rollout plan
| Window | Build | Exit criterion |
|---|---|---|
| Weeks 1 to 2 | Instrumentation and dedupe | Baseline response times measured. Dedupe live on your highest-volume lead source. |
| Weeks 3 to 4 | Enrichment and scoring | Providers wired, caches warmed, scoring trained on your historical conversions. |
| Week 5 | Routing and notification | Territory rules, escalation chains and Slack or SMS alerts running end to end. |
| Weeks 6 to 8 | Load test and cutover | Full-volume load testing and failure drills, then every remaining source switches over. |
Build order if you cannot do it all at once
- Capture and validation. One endpoint, one contract, rejects visible.
- Dedupe. Search before create beats every downstream cleanup.
- Assignment and notification. Even a crude router beats no router.
- Failure path. Dead-letter queue, correlation log, alerts that page.
- Enrichment and scoring. Add once the boring layers are trusted.
The stages above the write path protect the record. Enrichment and scoring make the record smarter, they do not make it correct. Fix correctness first.
FAQ
Does this replace the systems blueprint?
No. The blueprint explains the architecture. This pack is the build version. It carries the keys and the module order, plus the payloads, the budgets and the thresholds.
Which orchestration tools does it assume?
Make.com for the outline, since it handles nested iterators and error handling well. Zapier, n8n and custom API receivers map to the same stage boundaries.
What if my volume is small right now?
Keep the same stage boundaries. Shrink the budgets, keep the dead-letter queue. Volume changes the sizing. The shape stays the same.
Where does AI fit?
Classifying messy pain text, urgency and fit in scoring, with a closed list of allowed outputs and validation on the choice. The final routing path still gets a strict schema.
What happens next. When the pack is not enough, the same systems ship as client engagements. The work covers speed-to-lead builds, CRM and API workflow overhaul, lead qualification systems and monitored production workflows.
Get the fillable workbook
Everything above is yours to read. The workbook adds the empty worksheets, so you fill them in on your own stack with your own owners, fields and failures. It opens in any browser, on any device, and it saves as you type.
When you want my read on your own stack, the speed-to-lead questionnaire takes ten minutes, and I reply with the first fix I would make and what it costs.