产品
五个部分，彼此之间没有接缝
大多数 CRM 是一个数据库前面套个表单，而真正的沟通完全发生在别处——邮箱里、电话里、某个自带的聊天小收件箱里（自三月起就没人打开过）。iKonekt 从沟通本身出发，向外构建。
一个收件箱，所有渠道
聊天、表单、联系我挂件、回电请求、电子邮件、电话，还有纸质传单上的二维码。八扇门，一个房间，每位来客都标着他们从哪扇门进来。
到达即分配
第一秒就确定负责人，按规则、区域或轮值。共享邮箱——那个埋葬有希望线索的著名养老院——在这里不存在。
一条会话串，备注也在其中
客户用过的每个渠道，汇入同一份历史，内部备注就在同一处，而且私密标记是真的管用。
一条直达发票的流程线
落地、分配、沟通中、已报价、已预订并付款、已开票。全程同一条记录，所以没人需要第四次重新输入同一个地址。
由数据库强制执行的隔离
从第一个数据库迁移起就是多租户。多个品牌，一套部署，而且这道边界连周五下午四点五十五分随手写出的查询也挡得住。
还有你看不见的那部分
这五个部分之下是 castomAPI——与家族中其他产品共用同一个账户、同一个钱包和同一套基础设施。这就是为什么各个连接器都很短。
五者如何配合
每一部分的存在，都是因为前一部分带来了一个问题
这不是一份由委员会围着白板拼凑出来的功能清单。按顺序读下去，每一部分都是对上一部分若不如此便会造成的混乱的解答。
把所有信息收进一个地方，不出一周你就会收获一堆壮观的积压。没有归属的量，只是把丢三落四弄得更响亮，所以任务必须在到达时就指派——而不是等谁有心情回复时。
给每件事一个负责人，负责人立刻会问唯一合理的问题：这个人已经被告知过什么？因此每个客户一条会话线程，贯穿所有渠道，包括那些尴尬的部分。一个只能靠猜的销售会自信而错误地猜，这比不猜更糟。
把完整历史放进一条线程，这条线程就会开始想把事情办完。一段以“好的，把细节发我”结尾然后蒸发掉的对话不是对话，是业余爱好。所以记录会一路延续到报价、预订、付款和发票，从不被复制到另一个系统里。
把记录保存到那么远，它就装着姓名、号码、价格和付款信息——而这正是“我们在应用层按公司过滤”不再是一句可接受的话的时刻。所以隔离下沉到了数据库里，让一个被遗忘的 WHERE 子句无法撤销它。
诚实的版本是：上面那些问题是按上述顺序被发现的，发现者都以为自己已经完成了前一步。整洁的叙事是事后整理的。代码不是。
它不是什么
iKonekt 刻意不做的三件事
一个只列优点的产品页面，是没人会相信的产品页面。这些是选择，而且是永久的选择。
它从不发送冷启动消息
iKonekt 负责回答、跟进和提醒。它不会主动和从未要求过对话的人开启对话。这条规则比这个产品更古老，而且不可配置——这让我们至少错过了一次很有意思的会议。
它不给你的客户打分
没有那个介于 0 和 100 之间的神秘数字来告诉销售谁值得花心思。线程本身就是证据。如果一个线索值得追，一个人大约九秒钟就能看出原因。
它不取代你的其他工具
clickSomo 继续负责消息自动化，FABLS 继续负责发布，你的会计继续管账。iKonekt 承载对话和客户记录。其他一切留在它们已经运转良好的地方。