WhatsApp 获客平台

背景

一家创意工作室靠 WhatsApp 陌生开发拿新客，但找客户这件事本身把它要填的管道给吃掉了：找新商家、验号码、避免尴尬地重复联系同一个人、一条一条写开场白。

这套流程明显是通用的 —— 别的商家也有同样的问题 —— 于是这个工作室的内部工具变成了一个卖给别人的产品。

挑战

• 陌生开发需要每天有一批从没联系过的新客源；去重必须靠系统，不能靠记忆。
• 开场白要像是一条条单独写的，但量大到根本不可能一条条写。
• 从一个用户变成多个租户，意味着必须硬隔离：任何租户都不能看到别人的线索。
• 增长不能依赖人工开通 —— 注册、试用和收费必须自己跑。
• 只有在基础设施和运维成本接近于零的前提下，这门生意才算得过来。

我们做了什么

开发

• 采集是一条受控的管线 —— 商家从后台触发采集；一个排队的 worker 每次跑约 100 个新客源，走按活动划分的来源通道（光是一个垂直行业就横跨 67 个马来西亚城市的 21 个搜索词），并对照每个活动 90 天的窗口、以及所有租户做去重。数据库约束保证同一个商家、同一个活动、同一天只能有一个进行中的请求；卡住的任务会被回收，重试保持幂等。
• 值得发出去的消息 —— 每条线索都附一句个性化开场白，从一个 15 变体、多框架的文案引擎里挑出来，行业需要时给双语版本，以点击即发的 WhatsApp 链接交付。每天的工作压缩成：打开名单、看一眼、点一下、发出去。
• 租户隔离由数据库强制 —— 每一行都在服务端盖上所属租户的印，行级安全让跨租户访问在结构上不可能发生。一套提权测试会挨个尝试越界，并且预期每一次都被拒绝。
• 自助增长闭环 —— 注册即自动开通工作区，免费试用立刻给出真实线索。已接入 Stripe Checkout 做分层订阅，并用 webhook 驱动的等级同步，让数据库以 Stripe 为准而不是相信客户端；正式收费待客户自己的上线检查。
• 运营方全局视图 —— 运营方在一个界面上统管所有租户、活动和采集任务。

这一切跑在一套刻意选择的 serverless 架构上。

结果

• 一个每天在用的上线产品。
• 商家一键拿到全新、已去重的线索名单，取代过去几个小时的找客户。
• 每条线索都带一句可以直接发出去、语言正确的个性化开场白。
• 新客户完全自助地注册和试用。
• 租户数据在数据库层隔离，并由对抗性测试验证。