哥们儿我来给大伙儿说道说道“交易特例”这事儿。别看这词儿好像挺高大上，在我这儿，就是处理那些常规流程跑不通的特殊买卖。以前，我们公司做生意，十单里头总有那么一两单，情况特别，要么是客户要求怪，要么是付款方式刁钻，要么就是产品组合是咱们标准系统里没有的。大伙儿都头疼，销售接了单，后端执行起来就抓瞎，财务那边也对不上账，那叫一个乱。
问题的出现与初步摸索
我记得那会儿，我刚负责一块小业务，天天就为这些“特例”焦头烂额。比如，有个客户，非要用一批我们快淘汰的旧物料抵一部分货款，你说这咋整？系统里没这选项。还有一次，一个大单，客户要求分18期付款，每期还款额度根据他们当月销售额浮动。我的天，这财务怎么算？
我们都是口头传话，或者拉个临时小群。 张三去协调生产，李四去问财务，王五去跟客户磨。结果？信息传来传去就变形了，要么就是中间哪个环节掉链子，客户不满意，公司也吃亏。
我寻思这不行，老这么下去，早晚得出大事。我就开始琢磨，能不能整个流程，专门应付这些“不走寻常路”的交易。
建立“交易特例”处理机制的实践
第一步，我就先找领导聊。 我说，咱们得正视这些特例，不能当它是偶然事件，得有个专门的通道。领导也觉得有道理，就让我试试看。
第二步，我拉着销售、生产、财务几个关键部门的同事开了个小会。 我说咱们以后遇到这种常规系统处理不了的单子，就统一标记成“交易特例”。然后，咱们得有个地方记下来，不然转头就忘了。
简单粗暴，我就建了个共享电子表格。表格里有这么几项：
- 特例编号： 方便追踪，比如 TL-2023-001 这样。
- 发起人/销售： 谁接的这单。
- 客户信息： 基本情况得有。
- 特例描述： 清清楚楚写明白，这单特殊在哪儿，比如“客户要求使用XX材料替代”、“付款条件为XXX”等等。
- 涉及部门： 需要哪些部门配合，都勾上。
- 初步解决方案： 销售或发起人先提出个大概想法。
- 审批状态： 比如“待审批”、“审批中”、“已批准”、“已拒绝”。
- 负责人： 每个环节指定到人。
- 当前进展： 实时更新，搞到哪一步了。
- 预计完成时间与实际完成时间： 好做对比和复盘。
第三步，就是跑流程了。 销售那边接到一个感觉是特例的单子，先填表。填完表，就提交到一个指定的邮箱，或者在共享表格里@相关负责人。然后，我们每周开个短会，或者临时拉会，专门过这些“交易特例”。大家一起看，这个特例能不能做，风险在哪，怎么规避，哪个部门负责哪个部分，时间点怎么控制。
举个例子， 之前那个用旧物料抵货款的。销售填了表，我们在会上讨论，生产说这批旧物料放库里也是积压，评估一下折旧和再利用价值，财务说只要生产那边能给出合理的估价，并且客户接受，账务上可以做特殊处理。那就好办了，生产去评估，给出价格，销售去跟客户谈，客户同意，财务就按特殊入账来操作。这事儿就算成了。整个过程，表格里都记录得清清楚楚。
实践中的调整与优化
刚开始用表格，也遇到些问题。比如有人忘了更新状态，或者信息填得不全。后来我们就规定，每周的例会上，各个负责人必须汇报自己名下特例的进展，表格当场投屏，谁没更新，一目了然，挺管用的。
再后来公司稍微有点预算了，我们还基于这个逻辑，找人开发了个简单的内部小程序，把表格那套东西搬上去了，操作更方便了点，还能自动提醒。但万变不离其宗，核心还是那个“识别-记录-讨论-执行-追踪”的闭环。
通过这么一折腾，那些以前让人头大的“交易特例”，现在处理起来就有章法多了。虽然还是麻烦，但至少不会像以前那样两眼一抹黑，到处救火了。信息透明了，责任明确了，扯皮的事儿也少多了。
这“交易特例”在我看来，没啥神秘的，就是一套应对特殊情况的“土办法”，关键是得有人牵头，有明确的规则，并且大伙儿都认这个规则，愿意去执行。今天就先分享这么多，希望能给大伙儿一点启发！
还没有评论，来说两句吧...