调问新增 AI 电话回访：上线前先想清楚重试和配额
内容提要
调问新增AI电话回访与样本配额功能，但接入前需理清工程细节：电话任务应拆分呼叫与答卷记录，超时先确认状态再重拨，避免重复打扰；配额在并发下需明确超额处理与占位释放，规则应留版本。监控应关注接通和有效提交，而非接口成功。开源代码不等于无需维护，录音转写须确认告知与权限，建议小范围试跑后再扩大。
延伸解读
电话回访的重复拨打风险
文章指出，电话回访由系统主动发起，遇到未接听或通话中断时，业务容易要求自动重试。但若请求超时却已成功发起呼叫，简单重试会导致重复联系同一用户。建议拆分呼叫任务与答卷记录，为每次回访设置稳定标识，超时先确认状态再决定是否重拨，并确保回调重复到达时不重复生成有效答卷。
配额并发下的占位与释放
配额和甄别规则看似配置问题，实际涉及数据库竞争。文章提出，当剩余名额有限且多个回访同时进行时，需明确在接通时占位还是提交时扣减。前者可能被未完成通话占住，后者可能让已接受回访者无法计入样本。建议先由业务定义超额处理方式，再决定是否采用临时占位和超时释放，避免先查后写的计数器。
监控应关注业务结果而非接口成功
文章强调，接口返回成功只代表请求被接受，不代表用户接听或问卷完成。接入生产时应分别记录发起、接通和有效提交状态，并保留暂停后续拨号的开关。这样在花费失控或规则配错时能及时停止，而不是边拨边查。监控业务结果比监控接口成功更能反映电话回访的实际效果。
开源不等于免维护，试跑再扩大
文章提醒，代码开源让团队能检查数据流向，但不能据此判断电话服务是否依赖外部供应商。若保存录音或转写文本，需先确认用户告知、访问权限和保留期限。对小团队，建议先选范围明确、用户已同意回访的场景试跑，记录人工核对结果和实际费用，验证异常任务能否停住、答卷能否对账，再扩大范围。
Q&A
调问新增的AI电话回访功能，上线前需要重点考虑哪些工程问题？
需要重点考虑重试机制和配额管理。电话任务不能照搬网页提交，应拆分呼叫任务和答卷记录，给每次回访一个稳定标识；请求超时先确认状态再决定是否重拨，避免重复打扰。配额在并发下要明确超额处理与占位释放，规则应留版本。监控应关注接通和有效提交，而非接口成功。
AI电话回访中，为什么不能简单给队列任务加自动重试？
因为电话回访是系统主动发起的动作，遇到未接听或通话中断时，如果只是自动重试，在超时但已成功发起呼叫的情况下，可能导致重复联系同一个人，多一次请求就变成多一次打扰。正确做法是拆分呼叫任务和答卷记录，请求超时先确认状态再决定是否重拨，回调重复到达也不能重复生成有效答卷。
样本配额在并发场景下会遇到什么问题？应该如何设计？
配额和甄别规则会碰到数据库竞争。当某类样本只剩少量名额且多个回访同时进行时，需要明确是在接通时占位还是提交答卷时扣减：前者可能被未完成通话占住，后者可能让已接受回访的人无法计入样本。建议先由业务讲清楚超额如何处理，再决定是否需要临时占位和超时释放，不要靠先查后写的计数器碰运气，规则修改要留版本以便追溯。
电话回访的监控应该关注哪些指标？为什么不能只看接口成功？
监控应分别记录发起、接通和有效提交的状态，并保留暂停后续拨号的开关。接口返回成功只说明某一步请求被接受，不代表用户接听，更不代表问卷完成。花费失控或规则配错时，先停下来比边拨边查更踏实。
开源代码能直接说明电话回访服务不依赖外部供应商吗？接入时还要注意什么？
不能。代码开放让团队有机会检查数据流向，但不能仅凭这句话判断电话服务是否依赖外部供应商。如果计划保存录音或转写文本，需先确认用户告知、访问权限和保留期限，是否真的需要存也应单独讨论。能采集不等于应该长期留着。
小团队想试跑AI电话回访，建议怎么开始？
建议先拿一个范围明确、用户已同意回访的场景试跑，记录人工核对结果和实际费用。先验证异常任务能否停住、答卷能否对账，再扩大范围。电话拨出去以后，撤回功能开关也收不回用户已经接到的来电。
