我是一个程序员，去年 5 月份一个人开了家公司做外包，大半年后发现自己不适合做外包，于是转做产品。
上一个尝试的方向是提高会计工作效率的产品，市面上完全没有类似产品。MVP 出来后发现完全没有市场需求，放弃。
于是这次决定尝试没那么创新，有同类产品的东西。
那就客服云吧。
不知是否正确的初步设想（为什么要做 MVP）
最初定价 70元 / 座席 / 月，先只有基本核心功能。座席数 = 最高同时在线客服数，不是客服账户数量。之后随着功能完善再看要不要涨价。
随手一搜的结果表明：国内客服云一般 1000-2000 / 座席 / 年，有的提供免费使用。至少有部分产品 X 千起售，据说某大厂产品首次充值最少 1 万。
不难想象，可能有一些公司，免费的满足不了需求，但又不想一下投入几千，按月付费对他们相信是有吸引力的。
按月付费当然也有缺点，那就是没钱招销售上门一个个面谈，以及现金流压力大。但公司就我一人，我也不善销售不爱出门，这样正好。
有了设想，接下来需要快速做出第一版推出来，看看市场反应，决定下一步。
也就是所谓的 MVP，最小化可行产品，简单地说就是做个最简单的版本拉出去试试。
MVP 这个概念因“精益创业”这本书而流行，其核心思想可以归纳为：产品常常做出来推出去后才发现完全不行，创始人对市场的设想往往是不正确的，因此，需要尽快尽早地推出产品，获得市场反馈，验证设想是否正确。
这和我自己的经验和见闻也是一致的。
这个客服云的想法，同样有可能完全行不通。原因可能是：
- 现有成熟产品太多，新产品没有吸引力
- 按月付费反而给人不靠谱的印象
- 资本寒冬，客服云市场缩水
- 不面对面交流建立信任是一个极大的劣势
因此，决定要花尽可能少的时间，做出只有核心功能的第一版，拿出去卖并看看反馈。
界面和功能设计
反正一个人，我是直接脑内画原型的。这里就直接放成品截图了。
会话界面（只支持 web 端）。用户和客服的界面都是这个。第一版只支持嵌入页面的样式，不支持挂件或新窗口打开。
客服和多人聊天时，每一个浏览器标签页对应一个客户，而不是如微信 web 版一样在一个界面和多人聊天
有多个客服时，如何调度分配工作？答案是不分配，而是从未读会话中自行认领。每次进入会话时，会清零未读消息数，这个用户同时也就会从未读会话的列表消失。进入会话 = 标记为已读 = 认领用户。只要会话窗口没有关闭，这个用户的新消息会直接被标记为已读。
很多不重要的功能直接放弃了，以下是没做的功能：
- 发送接收图片
- 临时会话
- 自助注册，整合支付，修改找回密码，客服账户管理
- 座席限制，订阅到期时停止服务，续费功能和提醒
- 整合多个客服渠道，CRM，移动端 SDK，智障机器人
- 官网，文案，帮助文档，api 文档
图片消息在有第一个用户时就做，文档暂时用本文代替，账户管理相关先管理员（我）代替手动操作，其它功能之后再说。
相信对于大多数的老板和工程师，是没想过可以砍功能到这种程度的。
不能自助注册就算了，密码修改都没有？续费和提醒都不做？气泡聊天没有就算了，图都不能发？
所以不是说了嘛，要花尽可能少的时间。
按照普遍的做法，后台管理 20 - 30 个页面，功能不停加加加，是不可能这么快完成的，哪怕每天通宵。
想要快，就要敢砍需求。
技术栈的选择
后端：NodeJS + Express + MySQL + WebSocket
前端：React（preact） + SemanticUI
浏览器兼容：IE 10+（由于使用了 WebSocket）
全是用过的，熟悉的技术栈。目标是快速产出，不是踩坑、学习新技术、或者自己爽，所以没用能兼容更低 IE 的库如 socket.io。
详细开发时间表
5月07日：基本框架和数据库设计
5月09日：设置页面（生成 accessToken）
5月10日：个人资料页面，react 编译环境，开始做会话界面样式
5月13日：完成会话界面的样式，开始做会话 react 组件
5月14日：继续做会话 react 组件，会话 react 组件的 mock 数据源
5月15日：用户发送消息功能
5月16日：查看历史消息，消息推送，断线重连
5月17日：客服的会话功能，所有会话列表页面，客服和单个用户会话页面
5月20日：记录未读消息数，未读会话页面
5月21日：未读会话页面的数据推送，完善小细节
5月22日：给用户用的 api
5月23日：ie兼容，加上客服页面，完善更多小细节
API 设计
最初的想法是只有前端 sdk，甚至一个 iframe 解决。但很快否决了这个想法。因为会有身份伪造的隐患。
假设聊天窗口的地址如下：
用户只要修改 userId 参数的值，就可以伪造成另外一个用户，以他的身份发送和接收消息。
后端安全基本之：永远不要信任用户输入的数据。
为了确保用户无法伪装成另一个用户，需要后端的介入。最终设计出的接口如下：
1.获取 userToken
需要服务器在后端调用
提交数据：
"accessToken": "必填，从后台获取的accessToken",
"identifier": "必填，用户 id，也可以直接传数字，最长 255 字符",
"nickname": "必填，用户昵称"
}
返回数据：
"userToken": "userToken内容"
}
出错时 http 状态会是 200 以外的值，并附有 message 值表示信息。
这个接口同时也有添加和更新用户的功能。在数据库内无 identifier 一致的用户时会添加用户，nickname 不一致时会更新用户信息。
2.嵌入iframe
请将粗体的部分换为上个接口返回的 userToken。同时，建议不要保存 userToken，而是在每个嵌入客服的页面中调用上面获取 userToken 的接口。
style 内的内容可根据需要调整。
3.查询未读消息数量
需要服务器在后端调用
提交数据：
"accessToken": "必填，从后台获取的accessToken",
"identifier": "必填，用户 id，也可以直接传数字"
}
返回数据：
"unreadCount": 0
}
出错时 http 状态会是 200 以外的值，并附有 message 值表示信息。
接口的设计并不 restful，但是简单清晰，能够满足需求。
更多成品截图
accessToken 之所以这么长，是因为附上了签名，防止暴力破解。其它所有 token 也都有签名保护。
你已经是一个成熟的客服云系统了，要学会自己整合自己
后续计划
不管有没用户，这个产品是会继续运行下去的。因为至少我自己公司会使用这个系统。当然，用户太少的话，开发重心会转到其它产品上。
如果这个 MVP 如果能吸引到 2 个以上的用户，我就觉得是初步成功了，可以对它投入更多时间精力，下一步是 10 个用户，下下一步是 100 用户。
看起来目标很低？毕竟，我的上一个产品 0 人有兴趣，0 人买单…… 也见过听过不少人，开发投入几十万，结果没有走到上线这一步。
创业就是这么回事，失败是正常的。
求反馈！
觉得这个设想如何？产品如何？是否靠谱？
你是否会考虑购买，或者推荐给朋友？为什么？
如果想和我交流，或者对这个产品有兴趣，欢迎发送邮件至 yixiang@linguang.tech