客户评价模块很容易变成装饰：统一五星、相似句式、看不清身份的头像。用户不是看不懂，而是会怀疑这些内容是否真实。
好的评价帮助潜在客户理解合作过程、适合什么项目、解决了什么顾虑。它是证据，不是夸奖集合。
01 优先收集具体经历，而不是请客户“夸一下”
询问项目开始前的问题、为何选择、合作中的关键感受、交付后哪里更好用。
保留客户原意和语言，不要把所有评价润色成同一种品牌腔。
02 身份信息要真实且获得授权
可展示姓名、职位、公司、行业或项目类型，具体程度取决于授权和保密。
不能公开时用“某制造企业市场负责人”等匿名描述，并明确不是虚构头像或名字。
高可信评价的组成
| 组成 | 作用 | 示例方向 |
|---|---|---|
| 背景 | 说明评价适用场景 | 官网改版、B端系统、品牌升级 |
| 问题 | 让读者产生共鸣 | 信息混乱、流程复杂、交付反复 |
| 过程 | 证明服务方式 | 先梳理结构、阶段确认、开发走查 |
| 结果 | 说明变化 | 更易维护、内部统一、用户理解更快 |
| 身份 | 提供可核验上下文 | 职位、行业、项目链接 |
| 边界 | 避免夸大 | 不虚构销售数据和绝对承诺 |
03 评价与案例互相连接
将评价放在对应案例、服务或行业页面，比全站随机轮播更有说服力。
读者可以继续查看项目范围、方法和成果，不必只相信一句话。
04 不要让视觉削弱真实性
真实头像、公司Logo和清楚排版可以增强信任，但应获得许可。统一图库头像、过度精修引号和自动轮播反而像广告。
评价文字较长时提供重点与完整内容，不要裁成无意义的一句话。
05 虚假评价和自我评价不要包装成客户声音
合成文案、员工代写和未实际合作的评论不应当作真实客户评价。
若用典型情景说明服务，应明确标注为示例，不使用客户身份、星级和评价结构化数据。
06 建立持续收集机制
在阶段验收或项目结束时发送简短问题，取得公开范围和修改确认。保存授权记录与原始版本。
定期检查客户职位、公司名称和链接是否变化，避免多年不更新。
常见问题
可以帮客户写好评价让他确认吗？
可以基于真实反馈整理，但客户需确认内容和公开范围，不能替客户虚构经历。
匿名评价有用吗？
有一定价值，若能说明行业、角色和项目背景会更可信。
评价一定要放五星吗？
不需要。B2B服务更适合具体文字和项目证据。
客户不愿公开Logo怎么办？
尊重保密，可匿名展示或只在授权范围内描述。
可以给自己的服务做Review结构化数据吗？
需遵守搜索引擎当前规范，虚假或自利评价可能不适用，不应为了富摘要滥用。
链接复制成功
