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