大多数“人工智能催收”演示不过是美化版的邮件合并：模型撰写三段语气逐渐严厉的文字，定时任务在第 7、14 和 30 天发送这些邮件，然后众人鼓掌喝彩。这在客户回复“我们上周二已经付款了，请查阅你们的记录”之前都还算顺利——但你的单向电子邮件服务无法读取回复，因此代理仍然会发送第 30 天的严厉催款信。结果，你侮辱了一位已付款的客户，而你的应收账款团队不得不打电话道歉。
催收不是一个只发不收的问题。它是一个礼貌但坚定且必须读取回复的流程——因为最重要的两条信息（“我已经付款”和“我对这笔费用有异议”）是以入站电子邮件的形式到达的，它们是应当立即停止升级阶梯的两个信号。从设计上讲，无法接收邮件的催收代理是错误的工具。
这正是将其部署在代理账户上的全部原因。代理账户是代理拥有的真实完整邮箱——它既能发送也能接收邮件，对回复进行线程化处理，并在收到入站邮件时触发网络钩子。升级逻辑和“在付款或争议发生时停止”的规则由你的代码决定，但读/写/回复的基础设施已由系统处理。
我负责 Nylas 命令行界面（CLI）的工作，因此下面的终端命令正是我在构建和调试此类循环时所使用的命令。每个步骤都有两种形式：curl HTTP 调用和等效的 nylas ... 命令。
你实际获得的功能
代理账户只是一个授权——与每个 Nylas 邮箱背后的 grant_id 抽象概念相同。在数据平面上无需学习新知识。如果你曾经通过 Nylas 列出消息或发送过电子邮件，你就已经熟悉其应用程序编程接口（API）表面。特定于代理的部分在于，ar@yourcompany.com 是一个由代理端到端控制的邮箱：
-
从中发送催收步骤（
POST /v3/grants/{grant_id}/messages/send）。 -
以应用范围的
message.created网络钩子形式接收回复。 - 读取完整消息正文并在线程内回复，以便客户看到的是一个对话，而不是三条互不相关的催促信息。
催收阶梯、语气和停止条件存在于你的应用程序和你的计费系统中。Nylas 永远不知道发票是否已支付——那是你的单一事实来源。保持这一界限清晰，其余部分则是机械性的操作。
为何这优于事务性电子邮件服务提供商
单向提供商（如 SendGrid、Resend、Postmark）发送效果出色，但听不到任何回音。对于营销群发来说，这是一个特性；但对于催收来说，这是失败模式：
- 它看不到“我已经付款”的回复，因此无法停止升级阶梯。你会向已付款的客户升级催收。
- 它看不到“这是一笔争议款项”的回复，因此无法在事态升级到法律层面之前将对话线程转接给人工处理。
- 它无法进行线程化处理。你的第 14 天提醒会作为一封新邮件到达，而不是跟进邮件，导致客户每次都必须重新构建上下文。
代理账户闭环解决了这个问题。回复只是入站邮件，而入站邮件是代理可以获取、分类并采取行动的内容。
开始之前
你需要：
- 在已注册的发送域名上拥有一个代理账户（自定义域名，或
*.nylas.email试用子域名）。新域名的预热期大约为四周，因此不要在仅注册一天的域名上启动你的第一个真实营销活动。 - 一个应用级别的
message.created网络钩子订阅，以便入站回复能到达你的系统。 - 一个可以查询支付状态的计费系统。这是关键所在。代理绝不能自行判定发票已支付；它必须询问你
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
