该怎样拒绝一个功能请求，又不失去这位客户
阅读约 1 分钟
闭环通常意味着告诉某个人，她提出的请求已经发布了。而真正难的那一半，是大多数追踪系统根本没有任何流程去处理的那一半：要说不。大多数功能请求，其实从来都不会被真正发布出来，这意味着一个产品真正欠它用户的闭环，大部分其实是拒绝，而不是公告，而一次处理得很糟糕的拒绝，付出的善意代价，远比保持沉默要高得多。而如果处理得好，代价几乎可以低到接近于零，因为大多数时候，提出请求的人真正最想要的，其实是知道自己被听见了，而不是那个功能本身。
为什么把拒绝做好，和把发布做好同样重要
因为沉默读起来就像是一次没有任何解释的拒绝，而一个附带了解释的”不”，读起来则像是一种被认真对待的关注。一个什么都没听到的人，只能猜测自己的请求要么被忽略了，要么就是彻底石沉大海了，而这两种猜测，都会教会她以后干脆懒得再开口去问，这最终导致的结果，其实和产品直接给出一次真正的拒绝完全一样，只不过达到这个结果的过程更慢，路上还多攒了不少怨气。一句清清楚楚说不、并且给出理由的回复，能把闭环闭合得和一个已经发布的功能一样彻底，而且做到这一点的速度还更快。
| 回应方式 | 提出请求的人会学到什么 | 对这段关系造成的代价 |
|---|---|---|
| 保持沉默 | 没人读过，或者根本没人在乎 | 很高，而且每来一次新请求，代价还会继续累积 |
| 没有理由的自动回复 | 反正被扔进了某个队列里，遥遥无期 | 中等；能换来一点时间，却换不来任何信任 |
| 附带理由的拒绝 | 确实被读过、被认真考虑过，也得到了回应 | 较低，前提是这个理由是真诚的 |
| 附带替代方案的拒绝 | 真正的需求确实被认真听见了 | 最低；往往还能反过来建立起信任 |
到底是什么让一次拒绝显得特别糟糕
几乎总是三件事叠加在一起造成的。千篇一律：一句套话式的”感谢你的反馈”，如果压根没提到对方到底具体要的是什么，读起来就会像是根本没被认真读过一样，哪怕实际上确实读过。拖延：如果一次拒绝是在提出请求六个月之后才姗姗来迟，那时候对方可能都已经忘了自己问过这件事，这种感觉会比一句干脆利落的”不”还要糟糕，因为它暗示着这个请求根本没被真正考虑过就被拒绝了，而是原封不动地被晾在了那里。还有一种撑不住的理由：“这不在我们的路线图上”，这句话其实什么都没回答，而”这需要重新设计权限系统的运作方式，而我们今年并不打算去动这一块”，则给了提出请求的人一个她真正可以拿去评估的东西，而且如果这件事对她来说确实足够重要，她还能拿这个理由去升级诉求，或者另想办法绕过去。
一次好的拒绝，到底应该真正说些什么
按这个顺序，四件事。首先是一句确认，明确点出对方具体提出的是哪个请求，而不是一句泛泛而谈的转述；接着是真正的原因，即便这个诚实的原因是”这和产品要走的方向不太一致”这种听起来不那么好听的话，也要老老实实地说出来，而不是找一个更好听的借口来搪塞；然后要说清楚，这扇门到底是彻底关上了，还是只是现在暂时没开，因为这两种情况需要完全不同的语气；最后，如果确实存在的话，还要给出一个能解决背后那个真正需求的替代方案，即便它并不是字面意义上被要求的那个功能。
你好，Jamie，
谢谢你提出为团队邀请添加批量 CSV 导入功能的请求。我们认真评估过
了，但我们不会去做这个功能：出于安全方面的考虑，我们的邀请流程
就是围绕着对每一位新成员逐一进行单独审核而设计的，而批量导入
恰恰会和这个设计初衷背道而驰，而且这是刻意为之，不是我们的疏忽。
如果你真正想解决的问题，其实是想快速邀请一个规模较大的团队，
我们的 API 支持通过脚本批量发起单独的邀请，这样几乎能获得同样
的速度，同时又不会绕过审核环节：[链接]。如果你需要帮忙把这个
设置起来，随时告诉我们。请注意这段话做到了模板做不到的几件事：它点名了那个具体的功能，给出的理由和一个真实的设计决策绑在一起、而不是一句含糊其辞的政策说辞，还给出了一条能真正解决背后那个问题的路径，而不只是单纯把工单关掉了事。
这和在一个已发布功能上闭环有什么不同
背后的机制是相似的，但语气完全不同。闭环：从客户反馈到告知客户 完整讲解了功能已发布的那种情况，在那种情况下，这条消息本身就是个好消息，最大的风险只是忘了把它发出去而已。而拒绝则是个坏消息，或者至少也是一个不受欢迎的消息，它需要在给出的理由上多花一些心思，在传递方式上则要少一些自动化：一条”功能已发布”的通知，完全可以是由状态变化自动触发的一条模板化评论，但一条读起来明显像是套模板生成的拒绝，恰恰就是这整套做法本来想要极力避免的那种失败方式。不过两者依然共享一个前提条件：最初的那个请求，必须始终和提出请求的人保持关联，这正是 功能请求追踪 里讲到的那套追踪纪律，否则这两种消息里，无论哪一种，都根本没办法单独发送给对应的那个人。
一次拒绝是不是应该公开，就像公开路线图上的一个状态那样
通常不该公开的是那个具体的理由，尽管状态本身倒是可以公开。公开路线图 完整讲解了那些提出请求的人不用再重新问一遍、就能自己查到的状态标签，而一个”已拒绝”或者”暂不计划”的状态，完全可以是这套系统的一部分。但那个详细的理由，尤其是当它涉及到内部优先级排序或者一些不太光彩的背景信息时，通常更适合放在一对一的单独回复里，而不是放在一个公开的状态页面上，因为在那种公开页面上，同样一段措辞必须要能同时说服每一位读者，而不只是那个真正提出了这个问题的人。
是不是每一个被拒绝的请求都值得一条一对一的回复
每一个来自一个具名、且能够联系到的人的请求，都值得，哪怕只是简短的一句话。高流量、重复出现，或者匿名的请求，才是例外情况：把相似的请求归到一组、按组统一回复一次，或者更新一个共享的状态标签，在一对一回复真的没法规模化的时候，是完全合理的做法。需要守住的那条底线是，“我们没办法一对一回复每一个人”这句话，应该是一个经过实际请求量核实过的、真实存在的运营限制，而不能变成一个默认的借口，用来跳过一条本来两分钟就能回完的回复。
FAQ
是应该用一个站不住脚的理由迅速拒绝，还是应该多花点时间想一个更好的理由? 用一个真诚的理由迅速回应，胜过把这两者分开来单独做。哪怕理由很简短，一条附带真实理由的快速回复，也会胜过一条理由措辞很完美、但姗姗来迟的回复；拖延本身，就是损害信任的一部分原因。
一次拒绝，是不是应该承诺以后会重新考虑这个请求? 只有在这件事真的有可能发生、而且确实存在某种机制能真正重新考虑它的时候才应该这样说，比如说，有一个标签能让这个请求在下一次规划周期里重新被提上台面。如果没有这种实际机制，一句含糊的”我们会记在心里”，本质上和沉默没什么两样，只是措辞听起来更客气一点而已。
如果这个真实的理由，恰好是公司没法公开分享的内容，比如出于竞争方面的考虑，该怎么办? 那就直接说清楚，而不是去编造一个听起来更委婉的理由。“这里的具体原因我们没法透露，但这确实不是我们计划要做的东西”，这句话比一个一被追问就站不住脚的编造解释，要诚实得多，也更能赢得对方的尊重。
拒绝了一个请求，是不是就意味着应该把它从追踪系统里删掉? 不是。把它保留下来，标记为已拒绝并附上理由，这样它就能成为下一次类似请求被归类参照的那个模式的一部分，等以后背景情况发生变化了（比如出现了新的集成需求，或者团队的优先级变了），也能让这个请求重新被提上台面，而不用从零开始重新评估一遍。
本文的技术内容未经独立审核。如有错误，请告诉我们，我们会更正。