在服务行业中，客户的需求和期望常常成为推动服务提供者不断改进和创新的动力。然而，有时候客户的一些“独特”要求和行为，却能让服务提供者哭笑不得。

服务业成了国家的经济支柱，而服务提供者也被”客户是上帝“所绑架，成了”忍者神龟“、”乙里乙气“的代言人。

他们面对客户“咄咄逼人”时，期望“智慧化解”；

他们面对客户的“质疑”，被迫“忍气吞声”；

他们面对客户的“无知”，只能“敢怒不敢言”。

我所在的SaaS行业也不例外。

今天咱们就”组织召开“一次”客户吐槽大会“，看看”各路神仙“如何”各显神通“，就像《吐槽大会》一样，用一种玩笑、诙谐、调侃的方式，抚慰一下你那层面被客户“五毒棉花黯然销魂掌”所伤透了的小心脏，权当给你做一个心灵“马杀鸡”。

第一弹：“无知”的自我思维闭环

老农在集市上卖葱，一位年轻小伙问：“葱，怎么卖？”

“1块1斤。”老农答道。

小伙又问：“行，麻烦把葱帮我切成两半，一半是葱叶，一半是葱白，葱叶给你5毛/斤，葱白给你5毛/斤，正好1块1斤，可以吗？”

“你要多少斤？”老农说。

“全部。”小伙回复道。

相信你也看出来了，这是一个段子，一个让你猛一听觉得有点道理，但又好像哪里不对。

类似事情在最近一年，我反复经历了三回。

客户问：“你们的日报里的加班时长不对，加班时间19:08-18:00=1.08分，系统怎么算成1.133呢？”

“是的，加班时长单位是小时。”我回复道。

“1小时08分和1小时13分还是有区别的，会多算工资。”客户说。

“1.133小时不等于1小时13分钟，1小时是60分钟。”我回复道。

“加班费是18元/小时，系统计算加班费是1.13318元，我们用的是1.0818元，你们这个不对。”客户说。

我察觉到了她话语中的情绪，有一种系统竟然会犯如此低级错误的情绪。

我只能“耐心”的回复道：“1小时=60分钟，1小时08分钟不等于1.08小时，而是等于1.133小时。”

担心她还是不相信，我又让AI给她说了一遍答案。

“我们是直接18:00和19:08相减后，取1.08算加班费。”她依然非常淡然的回复道。

至此我知道了，她陷入了自己的逻辑怪圈，就像那个卖葱被人忽悠的老农一样，我相信她不是故意的，只是替她们的员工感伤，辛苦加班后的加班费，可能之前一直被企业所“克扣”。比如加班1小时59分钟，最终被计为1.59小时的加班费。

第二弹：我相信人，而不是你的系统

客户宁愿相信人性的光辉，却不相信系统的客观。

“你们尽快给我查下，为什么员工打卡记录又丢失了？”客户生气地质问道。

“麻烦提供一下员工手机号，以及打卡日期，我们查下。”我们回复道。

过了一会儿，我们确认员工当天并无打卡记录，甚至连打卡页面都没进入。于是，我们就回复说：“我们从系统记录中，确实未查看员工打卡记录，且并未进入打卡页面，咱们确定员工确实打卡了吗？”

“打卡成功的截图都有，这是员工的截图，你们这系统总出这种问题。”客户满腹牢骚地边说边发过来一张图片。

上面确实有打卡成功、打卡日期、打卡时间字样，与系统打卡成功提示页面一致。我们当下也是百思不得其解，又重新去查了一遍打卡记录与请求日志，还是没收获。

前端同学就开始研究客户所提供的截图，把它进行拉伸、放大，终于看出了端倪，员工采取PS方式，将截图里的打卡日期10月05日修改成了10月06日。

我们再去查10月05日的打卡日志，确实跟客户所提供的打卡成功截图，时间、行为轨迹完全一致，除了日期是10月06日，至此确定：这是一起员工精心准备、有预谋的打卡作弊行为。

吃一堑，长一智。

我们后续把H5打卡成功页面，全屏打上了日期水印，以防再次发生这类“离奇事件”。

第三弹：我的数据，我说了算

“你们系统能不能把员工的打卡数据删了？”客户说。

“咱们为什么需要删除呢？”我们问道。

“我们跟员工在仲裁，他的打卡数据都是作弊的，不算数，所以我们要求你们把它从系统里删除。”客户回复说。

“员工打卡数据属于客观数据，也是属于你们的私有数据，我们是无权随意删除的。如果员工有打卡作弊行为，我们是可以提供技术支持，帮忙确认作弊行为的。”我们说。

“我们已经确认了，就是打卡作弊，你们就把它删了就行。”客户有点不耐烦的说到。

“抱歉，我们确实没办法删除这种数据。如果是仲裁需要，我们可以提供打卡作弊相关的技术支持。”我们说。

“算了，算了，我们自己的数据，让你们删除就这么费劲，真是的。”客户生气的回复说。

最终我们也没做妥协，不是技术上做不到，而是从企业价值观而言，必须保持价值中立，不能真成了客户的“帮凶”。

第四弹：TA的数据，我想看看

“你们的薪酬分析，行业分析，数据源，都是外部企业的，能不能加入咱们合作客户的薪酬数据源，这样更真实，可以不做报告对外公布 但是数据库的参考可以调用。”客户问。

“不能，薪酬数据属于客户的私有、隐私数据，我们是不会拿它们去做分析、使用的。”我回复道。

“为什么不能？”客户反复道。

“我们是提供平台跟软件服务，每家客户的数据（尤其是薪酬数据）属于完全私有化数据，不能随意进行分析与使用。”我回复道。

“好吧。”客户无奈的回复道。

我无从判断客户当初提这个问题时，是否曾经想过：“如果别的客户想要她们的数薪酬数据，她们是否愿意授权？”

这个问题的本质，也是属于价值观的问题。如果我们真有可能进行真实数据的分析（如果客户愿意授权的话），不确定她们是否还愿意使用我们的SaaS服务？

第五弹：“天马行空”的方案

客户属于意向客户，在测试系统需求满足度的过程中，发现我们现有的批量调薪功能（即通过文件上传调薪金额），与其需求有差异（即期望直接在线编辑调薪金额），在我们按定制开发报价40人日后，觉得太贵，所以就自主去寻求“解决方案”。

“你们可以把奖金包功能，给我简单改个名字，弄成“调薪”，保证一线部门审批人在使用批量调薪时，可以用你们现在的奖金包功能。”客户问道。

“咱们为什么需要把奖金包改成调薪？”我问。

“你们这是什么态度？你们不给我想办法，我自己寻求各种方案，感觉还被你们阻挠？”客户质问道。

“是这样，因为上次沟通后，时间有点长，过程中，可能你跟我们销售伙伴沟通过，但我不确定现在最新的信息，所以需要了解下背景。”我回复道。

“我们也没有沟通啊，你就看看能不能把奖金包改一个名字，我们用来当做批量调薪功能，保证一线使用流程正常，最后可以不自动调薪，他们在线上编辑后，提交审批到我这里，我再手动调薪就行。”客户说。

“嗯，我理解你的想法，但站在技术实现角度是做不到，把奖金包改个名字就可以当做调薪使用的。”我说。

“我都已经同意付费，还做不到吗？”客户继续追问道。

“是的，这就像你盖了一栋十层的高楼大厦，觉得其中一个卧室不错，说我还需要一个独立书房，让工人把其中一个卧室单独复制，改一改，就可以当做独立的一个书房一样。”我说。

客户视角下，只要表面相似的功能或产品，是可以快速复制的，却不曾会想到软件产品跟实体建筑一样，也是讲解基础架构和依存关系的。

写在最后

客户是人，是人就会犯错和产生情绪，而你作为提供产品服务的人，也一样。

TA们的情绪可以直接向你表达，就像你可以直接向快递、外卖员，直接表达你作为消费者的情绪一样；

而你的情绪可能却无从表达，就是快递员、外卖员一样。

但情绪表达既是人性诉求，也遵守“能量守恒定律”。如果你无从对客户表达，却也需要有别的表达方式。

希望今天的文章，可以当作你的一种情绪表达（就像一个情绪树洞一般）。如果你遇到“更奇葩”、“更气愤”的客户（相信肯定有），欢迎你留言、评论。