创业程序员如何 1 人 12 个工作日完成客服云第一版（MVP）开发

我是一个程序员，去年 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 解决。但很快否决了这个想法。因为会有身份伪造的隐患。

假设聊天窗口的地址如下：

https://example.com/chat?accessToken=xxx&userId=1

用户只要修改 userId 参数的值，就可以伪造成另外一个用户，以他的身份发送和接收消息。

后端安全基本之：永远不要信任用户输入的数据。

为了确保用户无法伪装成另一个用户，需要后端的介入。最终设计出的接口如下：

1.获取 userToken

POST https://saas.linguang.tech/support/api/getUserToken

需要服务器在后端调用

提交数据：

{
    "accessToken": "必填，从后台获取的 accessToken",
    "identifier": "必填，用户 id，也可以直接传数字，最长 255 字符",
    "nickname": "必填，用户昵称"
}

返回数据：

{
    "userToken": "userToken 内容"
}

出错时 http 状态会是 200 以外的值，并附有 message 值表示信息。

这个接口同时也有添加和更新用户的功能。在数据库内无 identifier 一致的用户时会添加用户，nickname 不一致时会更新用户信息。

2.嵌入 iframe

<iframe src="https://saas.linguang.tech/support/frame/chat?userToken=userToken"  style="width: 411px; height: 731px; border:none"></iframe>

请将等号后的 userToken 换为上个接口返回的 userToken。同时，建议不要保存 userToken，而是在每个嵌入客服的页面中调用上面获取 userToken 的接口。

style 内的内容可根据需要调整。

3.查询未读消息数量

POST https://saas.linguang.tech/support/api/getUnreadCount

需要服务器在后端调用

提交数据：

{
    "accessToken": "必填，从后台获取的 accessToken",
    "identifier": "必填，用户 id，也可以直接传数字"
}

返回数据：

{
    "unreadCount": 0
}

出错时 http 状态会是 200 以外的值，并附有 message 值表示信息。

接口的设计并不 restful，但是简单清晰，能够满足需求。

更多成品截图

accessToken 之所以这么长，是因为附上了签名，防止暴力破解。其它所有 token 也都有签名保护。

你已经是一个成熟的客服云系统了，要学会自己整合自己

后续计划

不管有没用户，这个产品是会继续运行下去的。因为至少我自己公司会使用这个系统。当然，用户太少的话，开发重心会转到其它产品上。

如果这个 MVP 如果能吸引到 2 个以上的用户，我就觉得是初步成功了，可以对它投入更多时间精力，下一步是 10 个用户，下下一步是 100 用户。

看起来目标很低？毕竟，我的上一个产品 0 人有兴趣，0 人买单…… 也见过听过不少人，开发投入几十万，结果没有走到上线这一步。

创业就是这么回事，失败是正常的。

求反馈！

觉得这个设想如何？产品如何？是否靠谱？

你是否会考虑购买，或者推荐给朋友？为什么？

如果想和我交流，或者对这个产品有兴趣，欢迎发送邮件至 [email protected]

阅读更多创业经验分享，请访问公司网站： https://linguang.tech/