微博客户NPS分析，要使用真实回答过统一推荐题的分数，按有效样本计算推荐者占比减去贬损者占比，再回看客户说明的理由。CodeBuddy可用AI整理授权沟通；普通好评、聊天情绪和沉默都不能换算成推荐分数，NPS也不是已发生的转介绍数量。
客户说服务不错，表达的是一次体验评价；说愿意推荐，是推荐意愿；真的介绍新客户，又是实际行为。复盘时若将三者合在一起，分数看起来很高，却无法解释究竟量了什么。
Bain的NPS计算说明使用向朋友或同事推荐的可能性问题，采用0至10量表：9至10为推荐者，7至8为中立者，0至6为贬损者。净推荐值等于推荐者百分比减去贬损者百分比。分类名称用于这种计算，不是给客户贴永久标签。
开始前依次核对：
问的是本次客服满意度，或使用五星打分，就不能直接套用同一公式。只有零散表扬或抱怨时，先做定性反馈整理，不硬生成一个NPS。
知你AI助手可查询授权客户、历史会话和消息。CodeBuddy按当前远程MCP说明完成连接后，查指定微博渠道与真实收集期间，先读取完整提问，再对应客户回答和后续解释。评分若存于外部调查表，由负责人提供正式结果；MCP没有默认结构化NPS字段。
任务可以这样写：“整理这些授权沟通中对本次统一推荐题的明确回答，列客户对应关系、题目、实际分数、时间及本人给出的原因。普通评价、答非所问、未答和身份待核分别保留。不从语气估分，不替用户补理由，先交有效记录供复核再计算。”
同一人多次回答时，依照预先确定的本轮纳入规则处理，保留改答依据，不挑高分留下。检索覆盖、分页或原题不全，应先补核；原话只说明自己的原因，不自动证明整个业务环节有同样问题。
下图为MCP连接后台布局示意，推荐分析在AI客户端整理，不是自动评分页面。
以下人物、分数和理由全部虚拟。假设同一轮统一推荐题，经负责人确认有十份有效回答，另两人未答；十份中五份为9至10分，三份为7至8分，两份为0至6分。
| 分组 | 有效回答数 | 占十份有效回答 |
|---|---|---|
| 推荐者 | 5 | 50% |
| 中立者 | 3 | 30% |
| 贬损者 | 2 | 20% |
本例NPS＝50－20＝+30，通常写作+30，而不是30%满意率。三份中立回答仍在十份分母中，不能只剩推荐者和贬损者再算；未回答的两人不补零分，同时另报未答数量及本轮覆盖。这个小样本仅用于说明计算，不当成品牌总体结论。
随后把分数与原因并列看。示例客户-王先生给8分，补充“解释清楚，但最终能选的安排还要等”。记录为8分、中立组和该段原话，不能因他表扬解释就改成9分，也不能把后半句自动判成客服响应慢。
另一位给10分却说还没有向别人推荐，也不矛盾：题目问的是可能性，不是既往行为。统计保留其实际回答，具体原因再由运营理解。不同分数组的反馈都值得看，不把低分对象统一当营销挽回名单。
下图为AI客户端辅助复核流程，人物、原话与十份数量全部虚拟。
从客户明确说的原因中选出可继续核实的问题，例如选择范围是否讲清、等待安排怎样回告。主管先核对对应事实，仍有待办的按服务流程接续；需要深入理解的，由运营安排合适的后续研究，不让AI直接推断购买或流失。
知你AI助手找回原始回答，CodeBuddy组织分组、算式和原因。比较历次结果时保留相同题目、对象定义与收集方式，并列有效回答和未答情况；这些条件改变，就先解释差异，不能只凭NPS升降宣称某项改动有效。
不能，不同题目与量表不直接互换。
推荐者占比减贬损者占比，中立回答仍属于有效分母。
不能替其回答，应另报未答数量和覆盖情况。
不是，它是推荐意愿分组的净值，不是实际推荐行为比例。
不能，只有实际推荐题的明确回答才进入该计算。
推荐意愿分析先保留统一题目和真实分数，再核对有效分母与原话原因。用AI整理授权沟通，让每个数字能够复算、每个线索能回到本人表达，先查清一轮反馈，再决定下一步服务与研究行动。
如果推荐评分散在客服沟通里，运营还要逐条回查理由，可以了解知你AI助手官网，让AI先对应真实题目、分数和原话，再复算并挑选值得继续了解的反馈。
也可以扫码交流你的客服数据整理需求：
全渠道智能客服系统，聚合微信、小红书、抖音等平台咨询，支持自动回复与多客服协同。
知你AI助手官网 >AI 驱动的智能接待助手，基于知识库生成可确认的推荐回复，提升响应效率。
知你快回官网 >浏览器插件，为小红书、抖音、网页客服场景提供快捷话术库与 AI 自动回复。
