A web form becomes a scored, routed lead — before you spend a credential 一个网页表单,自动变成已打分、已分派的线索——还没花掉一个凭据
A small lead-capture pipeline: a form comes in, it gets enriched, scored, stored, and the team gets a clean summary in Slack. What makes it worth showing isn't the diagram — it's that the whole thing runs end to end on mock data, so the logic is proven before a single real API key, contact record, or CRM seat is touched. 一条小而完整的线索捕获流水线:表单进来,自动富集、打分、入库,团队在 Slack 收到一份干净的摘要。它值得展示的不是那张架构图——而是整条链路能在纯 mock 数据上端到端跑通,逻辑在碰任何真 API key、真联系人、真 CRM 席位之前就已被证明。
The problem问题
Leads arrive from a form, and someone has to research each one, decide whether it's worth a fast reply, and get it in front of the right person before it goes cold. Done by hand it's slow and leaky — good leads wait, weak ones eat time, and nothing is logged consistently. The obvious fix is "automate it," but most buyers have been burned by automations that are a tangle of half-connected integrations nobody can trust or maintain. 线索从表单进来,得有人去查每一条、判断值不值得快速回复、再在它变凉之前送到对的人手上。纯人工做又慢又漏——好线索干等,弱线索吃时间,而且记录不一致。显而易见的解法是"自动化",但多数买家都被那种"一堆半接通、没人敢信也没人维护得动"的集成坑过。
The constraint: prove the logic without spending trust约束:证明逻辑,却不消耗信任
Every real integration asks you to spend something up front — an API key, a paid enrichment credit, write access to a live CRM — just to find out whether the flow even works. That's exactly backwards. I build these mock-first: a stand-in enrichment server and fake data let the entire pipeline run and be watched, so you verify the behavior on evidence before wiring in anything real or billable. 每一个真集成都要求你先"押上"点什么——一把 API key、一笔付费富集额度、对线上 CRM 的写权限——仅仅为了搞清楚这条流到底通不通。这顺序正好反了。我把这类东西做成 mock 先行:一个替身富集服务加假数据,让整条流水线跑起来、被看见,于是你在接入任何真实或计费的东西之前,就已经凭证据验证了行为。
How it works它怎么运转
- Capture — a form submission enters the pipeline as a structured event, validated up front so bad input fails loudly instead of flowing downstream. 捕获——表单提交作为一个结构化事件进入流水线,先做校验,让坏输入当场报错,而不是流到下游。
- Enrich — the lead is enriched against a company/contact source. In the demo this is a mock Apollo server, so the flow behaves identically to production without a real key or paid credit. 富集——线索对接一个公司/联系人数据源做富集。demo 里这是一个 mock 的 Apollo 服务,于是这条流的行为和生产环境一致,却不需要真 key 或付费额度。
- Score — a transparent, config-driven scoring rule ranks the lead, so the routing decision is explainable and easy to tune rather than a black box. 打分——一套透明的、配置驱动的打分规则给线索排序,让分派决策可解释、好调,而不是一个黑盒。
- Store & notify — the result lands in Airtable as the record of truth, and the team gets a concise Slack summary — the good ones surfaced, the weak ones logged, nothing dropped. 入库与通知——结果落进 Airtable 作为事实记录,团队收到一条精炼的 Slack 摘要——好的被顶上来,弱的被留痕,没有一条掉地上。
Why this is my kind of problem为什么这正是我擅长的问题
The value isn't the node graph — anyone can wire boxes together. It's the engineering instinct around it: validate at the edge, make the scoring legible, keep a record that survives, and prove all of it on mock data so the client risks nothing to see it work. That "show it running before you trust it" discipline is how I de-risk every integration I take on. 价值不在那张节点图——把方框连起来谁都会。价值在它周围的工程直觉:在边界处校验、让打分可读、留一份活得下来的记录,并且全部在 mock 数据上证明,让客户不冒任何风险就能看到它跑。这套"先让它跑给你看,再谈信任"的纪律,是我给每一个接手的集成活降风险的方式。
Proof证明
A capability demo you can watch and read — running entirely on mock data. There's a short screen recording of the full pipeline going from an empty table to a scored, routed lead, and the sanitized workflow is public on GitHub — the n8n workflow, the mock enrichment server, and the scoring config — so the logic is inspectable, not just described. This is a demonstrated capability rather than a specific client engagement; the point it proves is the method. 一个你能看、也能读的能力 demo——完全跑在 mock 数据上。有一段简短的屏幕录制,展示整条流水线从空表跑到一条已打分、已分派的线索;脱敏后的工作流公开在 GitHub 上——n8n 工作流、mock 富集服务、打分配置都在——逻辑可查,不只是嘴说。这是一项被演示出来的能力,而非某个具体客户的交付;它要证明的,是这套方法。
Where else this applies还能用在哪
Any "an event comes in, it needs to be enriched, judged, recorded, and someone notified" workflow: inbound leads, form intake, support triage, order or application processing, alerting. If you've been quoted a number of days for an integration you can't picture yet, I'd rather build the mock-first version first — so you watch it work before you commit. 任何"一个事件进来,需要被富集、判断、记录、并通知到人"的流程:入站线索、表单收集、工单分诊、订单或申请处理、告警。如果有人给你一个还想象不出来的集成报了个工期天数,我更愿意先做那版 mock 先行的——让你先看它跑通,再决定投入。
← All case studies← 全部案例