> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh/2020-nian/w45-zai-tan-b2b-zhi-liang-yu-ti-yan-wen-ti.md).

# W45-再谈B2B质量与体验问题

最近B端收银台有两个业务方反馈的问题，在沟通排查的同时，引发了我对B2B支付在质量和体验上更长远的思考。

第一个是快驴对于B端收银台体验问题的吐槽。对此我们专门拉齐了快驴侧产研同学，一起就收集到的Bad Case做了讨论，对齐了双方的诉求与处境。

第二个是餐饮SaaS反馈的收银台sdk报错问题。由于sdk版本较老，在质量监控上一直存在短板，最终在问题排查上造成了困难。鉴于该库影响范围较大，运行也比较稳定，所以对sdk这个库的修改一直比较谨慎。

这两个问题，其实都是业务方对我们提出了更高的要求，这也意味着，我们的发展阶段不同了，需要在不同的阶段对自己提出不同的要求，来充分应对未来的变化。

最初的B2B支付，更像是一个第三方支付的跳板页，历经近一年的业务迭代，我们基本上实现了一个完整的支付产品，在账户、资金、流量等方面都形成了闭环。

面向未来，快驴和优选都是最有可能放量的业务方，在订单量还没有爆发之前，我们需要在体验和质量上未雨绸缪。

快驴是一个比较特殊的B2B场景，在业务流程上，更像C端的买方市场，对收银台提出体验上的要求再自然不过。下一步需要针对目前的问题，在体验方面做短期和长期的规划，短期偏离线化和shark，长期借力Neo的成果，同时可以作为Neo平台化在B端的试验田。目前在与各方沟通收集信息的阶段。

质量是收银台的第一性问题。目前只有收银台首页的质量保障和监控下了功夫，对于sdk和签约支付在质量方面的投入是远远不够的。表现在前端算不出SLA这个技术指标，做不到跨项目全链路的支付流程监控等等，这些都是下一步需要重点落地解决的。