Turn Phone Numbers into Lead Signals

查看原文 / View Original 编辑 / Edit

Turn Phone Numbers into Lead Signals

将电话号码转化为潜在客户信号

Subtitle: Build a Python app that combines Telnyx Number Lookup with Telnyx AI Inference to qualify leads and recommend the best follow-up channel. 副标题：构建一个结合 Telnyx 号码查询（Number Lookup）与 Telnyx AI 推理（AI Inference）的 Python 应用程序，用于评估潜在客户并推荐最佳跟进渠道。

A lead form usually gives you just enough information to create a question. Someone enters a name, an email address, maybe a phone number, and maybe a note about what they want. Now the app has to decide what happens next. Does this lead go to sales? Should the first touch be SMS or voice? Is the phone number even usable? 潜在客户表单通常只提供足够让你产生疑问的信息。用户输入姓名、电子邮件地址，可能还有电话号码以及关于他们需求的备注。现在，应用程序必须决定接下来该做什么：这个潜在客户应该转交给销售部门吗？首次联系应该通过短信还是语音？这个电话号码甚至有效吗？

That is the workflow behind this example: https://github.com/team-telnyx/telnyx-code-examples/tree/main/number-lookup-lead-enrichment-python It is a small Python Flask app that takes a phone number, enriches it with Telnyx Number Lookup, then uses Telnyx AI Inference to score the lead and recommend a follow-up channel. 这就是此示例背后的工作流程：https://github.com/team-telnyx/telnyx-code-examples/tree/main/number-lookup-lead-enrichment-python。这是一个小型 Python Flask 应用程序，它接收一个电话号码，通过 Telnyx 号码查询功能对其进行丰富，然后利用 Telnyx AI 推理来评估潜在客户质量并推荐跟进渠道。

The App Shape

应用程序架构

The app exposes three routes: POST /enrich for one phone number POST /enrich/bulk for up to 50 phone numbers GET /health for app health 该应用程序公开了三个路由： POST /enrich：用于单个电话号码 POST /enrich/bulk：最多支持 50 个电话号码的批量处理 GET /health：用于检查应用程序健康状态

It uses two Telnyx APIs: GET /v2/number_lookup/{phone} POST /v2/ai/chat/completions 它使用了两个 Telnyx API： GET /v2/number_lookup/{phone} POST /v2/ai/chat/completions

The current default model is set in .env.example: AI_MODEL=MiniMaxAI/MiniMax-M3-MXFP8. The pattern is simple: gather phone intelligence first, then use an inference model to turn that data into a lead-quality decision. 当前的默认模型在 .env.example 中设置：AI_MODEL=MiniMaxAI/MiniMax-M3-MXFP8。其模式很简单：首先收集电话情报，然后使用推理模型将这些数据转化为关于潜在客户质量的决策。

What Goes In

输入内容

The request is intentionally small:

curl -X POST http://localhost:5000/enrich \
 -H "Content-Type: application/json" \
 -d '{ "phone_number": "+12125550123" }'

请求被有意简化： （代码见上文）

The app looks up the number and extracts fields like carrier name, carrier type, caller name, line type, country, and validity. Then it asks the model to return JSON like: 应用程序会查询该号码并提取运营商名称、运营商类型、呼叫者姓名、线路类型、国家/地区和有效性等字段。然后，它会要求模型返回如下 JSON：

{
  "lead_quality": "hot",
  "reasoning": "Valid mobile number with usable carrier data",
  "is_mobile": true,
  "is_voip": false,
  "recommended_channel": "sms"
}

That response is much easier to build with than a paragraph. A product can route it, store it, show it in a CRM, or use it to kick off a workflow. 这种响应格式比一段文字更容易处理。产品可以对其进行路由、存储、在 CRM 中显示，或利用它来启动工作流程。

Why This Is Useful

为什么这很有用

Lead enrichment usually turns into a pile of small decisions: Is this number valid? Is it likely mobile? Is it VoIP? Is there carrier context? Should this lead be contacted by SMS, voice, or email? Should it go into a high-priority queue? 潜在客户信息丰富通常涉及一系列小决策：这个号码有效吗？它是手机号码吗？它是 VoIP 吗？有运营商背景信息吗？应该通过短信、语音还是电子邮件联系该客户？它应该进入高优先级队列吗？

Number Lookup gives you the underlying phone intelligence. AI Inference lets you apply a lightweight reasoning layer over that data. That is a nice AI app pattern because the model is not doing everything. It is operating on structured context from a real API. 号码查询功能为您提供了底层的电话情报。AI 推理让您可以在这些数据之上应用一个轻量级的推理层。这是一种很好的 AI 应用模式，因为模型并不需要处理所有事情，它是在基于真实 API 提供的结构化上下文进行操作。

The Small Detail That Matters

关键的小细节

The app asks the model to return only JSON, with no prose and no markdown fences. It still includes a helper to strip markdown fences and parse the JSON object. I like that because AI app code should be defensive. Prompts reduce variance, but validation is what keeps the output safe to use in an application. The example keeps everything readable in one Flask app, which makes it easy to adapt. 该应用程序要求模型仅返回 JSON，不包含任何说明文字或 Markdown 标记。它仍然包含一个辅助函数来去除 Markdown 标记并解析 JSON 对象。我喜欢这一点，因为 AI 应用程序代码应该具有防御性。提示词（Prompts）可以减少差异，但验证才是确保输出在应用程序中安全使用的关键。该示例将所有内容保持在一个易读的 Flask 应用程序中，使其易于适配。

What I Would Add Next

我接下来会添加的功能

For production, I would add:

  • E.164 normalization before lookup
  • Persistent storage for enriched leads
  • Auth on the API endpoints
  • Retry handling for lookup and inference calls
  • CRM integration
  • Rate limiting for bulk enrichment
  • More explicit schemas for lead scoring
  • Human review for ambiguous high-value leads 对于生产环境，我会添加：
  • 查询前的 E.164 标准化处理
  • 丰富后的潜在客户持久化存储
  • API 端点的身份验证
  • 查询和推理调用的重试机制
  • CRM 集成
  • 批量查询的速率限制
  • 更明确的潜在客户评分模式（Schema）
  • 针对高价值模糊潜在客户的人工审核

The repo is also structured to be agent-readable. Your coding agent can inspect the README, API reference, guide, environment file, and app code, then help extend it. You can ask it to add CRM writes, tests, stricter validation, or a scheduled enrichment job. 该仓库的结构也便于 AI 代理（Agent）读取。您的编码代理可以检查 README、API 参考、指南、环境文件和应用程序代码，然后帮助扩展它。您可以要求它添加 CRM 写入、测试、更严格的验证或定时丰富任务。

Try It

尝试一下

← 返回新闻列表 / Back to news list