一，

因为我们的软件是做免费物品分发，基本的玩法是用户摇一摇，凭运气好坏就可以摇到不同价值的物品。而且目前我们是在做试点市场，很多地方都不是很完善，我们自己也知道这些情况。为了去发现客服环节的问题以及将客服流程标准化，我们到合作的商家那里去做客户回访。

一开始就照例出示兑换依据，商家也很爽快的给予兑换了。然后我们就点了几个小菜，坐下来吃，想在这个体验过程中去发现一些问题。刚好，老板听说我们在做回访，然后就找来了，说外面一桌来兑换物品的，一下子出示四张凭据，而且都是免费的、、、像这样的玩法，他根本都做不下去就得关门了、、、

我们觉得很纳闷，为什么会出现一下子四张免费的凭据出现在一起的情况呢？我们一边安慰老板，一边去找兑换的客户做详细了解。我们发现，客户原来是在未登录状态下拿到的获奖凭据，而这种为注册登录状态下拿到的东西其实是无法兑换的，无法识别身份，怎么去兑换呢？于是，我们给老板解释了这个事情怎么处理，为什么不能兑换，然后我们给客户也做了详细的解释、、、虽然，当时客户不是很开心，但是我们几个人一直陪着客户解释，饭都顾不上吃，最后还主动提出为客户减单一部分，老板也提出让客户下次来消费给他们减免多少、、、

这个事儿，就这么过了。但对于我们来说，发现了流程中的几个重大问题：一是招商环节中和商家并没有说清楚怎么兑换和怎么处理；二是我们的客服没有及时的回访发现这些问题、、、回去之后，经过大家的一致讨论决定，制定一个合作商家兑换流程图，将兑换识别、怎么兑换以及兑换之后怎么处理做详细的图片说明，让商家一看就明白怎么做。并让客服部的人及时送达到每一个合作商家，并张贴在商家柜台显眼处；同时，将给合作商家送兑换流程图这个事情写入招商标准流程里面，并在合同中体现，同时，给客服的人强调必须在每次合作签约之后做回访并拍照，照片中必须有商家兑换流程图。

话说这个事情，要是我们没有去回访，没有遇到客户兑换并和商家发生小摩擦，我们怎么会知道兑换流程图这个事情？可能，我们很久都一直蒙在鼓里，用户怎么不使用或者商家和主动我们解约，我们不知道是怎么回事。

 

二，

诚如上文所说，我们是做免费物品分发的，所以，每天都会有很多的用户来找我们兑换各种不同的物品。这不，因为我们的应用里面植入了电影票这种东东，有用户拿到了，然后联系我们，说可不可以给买两张规定时间的电影票啊？

当时他们找来的时间是十一月4号的样子，他希望我们给买十一月九号，也就是星期天下午两点左右的票。我们就在猫眼上和格瓦拉上面给选票。这猫眼上的电影票死贵死贵的，八十一张；格瓦拉上面便宜很多，三十五甚至二十都有，但是不能购买，格瓦拉上面只显示最近两天的票，也就是说，只能够买最近两天的票。

OK，我们就给客户说一定给他买到。然后，我们就在日程上将这个事情记录下来。然后等到八号一早，我们就开始上格瓦拉买票，谁知道选座之后，居然一直提示：和中心数据库连接出现故障，当时依照我的判断是影城最近生意好可能故意将订票的服务器给关停；后来，我们又尝试了时光网，也是提示数据库连接有问题，一大早晨，我们的几个手机上都下满了订票的APP，甚至大麦我们都下了。

实在没招了。我就给客服说，要不咱们去影城直接买票吧，不然客户明天拿不到票，这对于我们是很大的声誉影响；客服想想也对，于是就去影城买票，经过和影城的交流才知道，原来是他们的订票那个系统出问题，不确定什么时候恢复、、、也就是说，我们如果不去影城买票的话，可能等到九号，也是买不了的。后来，我们就买了两张票，每张30，打车给客户送过去的。

客服觉得心里挺堵的，说就为了买票这事耽误了两个人一上午的时间。但我觉得，这是一个好事，我们通过这件事情我们发现了购票的问题，至少我们以后在处理这些电影票的兑换上面，我们可以第一时间告诉他们，只能够定最近两天的票，或者直接给现金，用最果断直接有效的方式，让客服工作高效运转。而如果我们不经历这么一茬，那么这样类似的事情肯定会有的，而且我们可能会付出更多的代价和成本。这样说来，这么一次意外早早的发生，其实是帮我们完善工作，对我们是大大的有帮助。

 

三，

之前曾经带过团队做网站以及软件开发的。那是在成都温江的时候，因为公司里面有三四个程序员，然后呢，公司的收入一直不是很稳健，所以，就决定找点小业务来做做，贴补家用。

我以为接单子接活这些事很简单。以为就是接了单子然后叫公司的程序员做了就是了。而事实上是，这些东西得有一些规则和技巧的，否则，就会弄得很被动。

第一个单子是一个朋友介绍的网站业务。客户我现在都还记得，是成都一家做展会的公司。当时，他们的老板希望我们给他们做一个展示型网站，他看了人家的网站，觉得有一些可取的地方，然后就让我们按照这样做；而事实上呢，别人那个网站是整站FLASH，我们根本都没法弄到人家的源代码，如果要达到客户的需求，我们就只有用JQUERY特效来体现，而其他部位用其他方式替代。

当时为了赢得客户，我很着急的1800块钱拿下来了。而且客户给我们的信息，也只是他们的主管描述而已，所以，合同上也写的很模糊。我们当时并没有认识到这样做的潜在风险。直到后来的时候，我们才发现这个问题的严重性；我们按照客户的最初想法，将他们需要的效果实现了给他们看，他们当天可能觉得还蛮不错的，但是过了当天，他们就会挑这样的毛病那样的毛病，要求我们修改，好吧，为了尊重客户，我们就按照他们说的修改，修改了一次，又一次，再一次、、、后面程序员直接就不干了、、、、我把这事情反馈到客户那里，客户说签了合同的，没有给他做好就不给尾款、、、

好吧，最后是我自己掏钱几千块将这个事情弄完。从心底上说，我很恨那个客户，让我自己掏钱做项目；但是，从道理上来讲，我们应该感谢他，感谢他让我们明白开发项目写需求的重要性，而如果当时我们最开始就以文档的形式将需求定好，并且附在合同中，而且定好一旦确认页面之后的每一次修改都必须重新议价；每一个页面都要求客户签字确认，每一个颜色都要求客户签字确认，每一次对话我们都有记录可查，如果我们自己做好工作做细致一点、、、、我们也不会有那么被动。可惜，没有如果。

但是，从那事之后，我开始认真的写需求文档，尽可能的在合作过程中将确认、验收、修改、调整、、、这些事情沟通明白，就算是开发公司帮我们开发，我们也主动将这些事情沟通明白，因为我知道：让别人不麻烦，实际上也是让自己不麻烦。

 

我一直不是很明白很多人求神拜佛求签卜卦，妄图寻求先知来告诉自己将来要怎么做怎么做；而事实上，没有人去告诉你应该怎么做。而只有你自己走过了，经历过了，你才会知道到底应该怎么做，怎么做才是最合适的。