先按决策权限分类
可直接答复的内容通常是已发布且规则稳定的产品说明。需要查询的内容包括库存、订单状态和排期。必须批准的内容包括超出权限的折扣、例外退款、赔偿和非标准合同承诺。
具体边界由企业自己设定。例如“在公开政策范围内解释退货步骤”与“同意政策之外的全额退款”是两类动作,不应混用一个自动售后开关。
给每条规则写出触发条件
规则可以结合金额范围、产品类别、客户情绪、事实冲突与置信不足。不要只靠“投诉”两个字识别高风险;客户反复否定、要求负责人或提及严重使用问题,也应有升级路径。
触发后向客户说明正在确认具体事项,不虚构“经理已批准”。内部请示应包含原话摘要、相关规则、拟回复内容和需要确认的一个决定。
批准不是永久授权
一次折扣获批,不代表该客户以后所有订单都能享受相同折扣。记录审批适用订单、条件和有效范围,回复时只传达已批准内容。客户修改条件后,应重新检查原批准是否仍适用。
如果人工迟迟未回应,可先确认已收到请求并说明下一步处理安排。不要为了清空待办队列,把“等待审批”自动转成“同意”。
检查暂停与恢复是否完整
用模拟场景验证:触发请示后是否停止相关承诺,批准后能否恢复上下文,拒绝后能否礼貌说明替代方案。确保同一问题不会由不同坐席给出互相矛盾的答案。
使用 IntentGrow 的辅助或自主模式前,应把以上规则与商务及实施团队确认。先让人工查看草稿,再逐类开放稳定场景,是便于观察和纠错的上线方式。
文中场景与话术为流程示例。请按实际产品资料、业务权限和客户情况调整;具体功能、接入范围及计费条件,以商务确认与试用结果为准。