我们自己是第一个用户
你在这个网站上看到的每一样东西，我们每天都在用
不是先接了单再去学怎么做，也不是把别人的方案换个封面拿出来。同一套东西，我们自己的生意每天都靠它跑。
先有问题，才有系统
每一套都是为了解决自己生意里的某个具体麻烦做出来的，不是为了做一个产品去找场景。所以它们的形状是被真实业务磨出来的，不是在白板上设计出来的。
跑在真实的业务量上
订单、客诉、退换、多语种同步、每天要发出去的内容——不是演示数据。一个环节出错，当天就会有人来问，没有「等下个版本再修」这种余地。
所以我们知道它会在哪里松掉
一套东西上线三个月之后，谁会开始绕开它、哪一步的人会嫌麻烦、哪条规则会悄悄失效——这些不写在任何方案里，只有自己天天用才知道。
所以诊断的时候，我们看你的流程用的是经营者的眼睛，不是乙方的眼睛—— 先问这件事一个月发生多少次、错一次要赔多少，再谈技术上怎么接。 具体是哪六套系统、各自解决什么，写在案例索引 →
你对接的人
没有销售层，没有中途交接
从第一次诊断到最后交接，对接你的人不换，而且他就是动手做这套系统的人。不会出现「这个我要回去问一下工程师」。
谈的人就是做的人
诊断时你说的每一句、临时想起来补的每一个特例，不需要经过一层转述才到实现的人手上。少一层转述，就少一批「后来发现方案里没写」。
我们也不转包
这个行业里最常见的失望是：投标时来的是高手，交付时换成新人。我们做不出这件事——因为交付的就是来谈的那个人。
代价是同时能做的项目有限
这不是谦虚，是排期上的事实。如果时间排不开，我们会直接告诉你，而不是先签了再说。被排在后面比被塞进队里好，至少你还来得及去找别人。
我们只接什么样的项目
一次只做少量项目，所以选择上会比较挑
三条判断标准，也是我们在诊断里最先确认的三件事。
流程已经定型的
规则下个月可能被推翻的，自动化只会把临时做法固化成制度，越跑越难改。
有真实业务量的
一个月跑三五次的事，省下来的时间不够开一次立项会，做完也没人会记得它在跑。
有人能拍板的
三个部门还没就规则达成一致的，卡点不在技术——先把规则定下来，这件事才轮得到我们。
诊断阶段我们会主动告诉你哪些不值得做—— 一份只说「什么都能做」的方案，通常意味着对方没认真看你的流程。 该用现成工具的地方，我们会直说该用现成工具。