我没有开始建立MSG。
AI是因为我发现了一个全新的AI机会.
它首先是一个小得多的问题——一个每天都在重复的问题。
一个信息以另一种语言传来。
你把它复制成一个翻译工具,读取结果,写出一个答复,翻译那个答复,然后把它粘回WhatsApp.
当客户询问一个熟悉的问题时,您会通过文档或旧的聊天来搜索您上次使用的答案.
每一步只需要几秒钟。
没有一个看起来重要到足以证明新产品是合理的。
但当有人每天处理数十个国际对话时,这些小中断会分散整个工作流程.
这是MSG.AI的起点。
为什么一个浏览器扩展而不是另一个支持平台?
我的第一个直觉是建立一个独立的网络应用程序,它有自己的收件箱,联系人,翻译工具和客户管理功能.
我很快放弃了那个方向 人们已经在WhatsApp工作。
要求他们采用另一个收件箱意味着另一个登录,另一个数据同步,以及另一个保持开放的界面.
产品可能看起来更完整,但它也会引入我试图去除的确切类型的上下文切换.
一个浏览器扩展提供了更简单的方法:将对话留在它已经存在的地方并添加周围缺失的工具.
客户仍保留在现有聊天列表中.
信件仍然通过当前WhatsApp Web会话.
该扩展处理辅助任务,如翻译,可再用回复,受控信件任务,以及导出等.
我认为这是在已经使用的办公桌旁边增加一个小工作台,而不是要求他们搬入一个新的办公室。
散装信息首先来,但翻译变得更重要 最早的版本主要侧重于分批发送客户更新.
通知一批现有客户有合理的理由:订购更新、送货通知、节假日时间表、遗失文件或交易展出邀请。
每一次谈话和粘贴相同的信息都是缓慢的,很容易错过某人.
因此,我建立了一个任务排队,可配置的间隔, 进度跟踪, 以及暂停和恢复控制。
但在更仔细地看工作流程之后,我意识到批量的讯息是偶尔的.
翻译每天都发生。
产品逐渐转向了聊天翻译:在发来的电文旁边读出一个译出版本,然后在发稿前再审稿.
目标不是使通信完全自动。
只是为了避免在需要理解信息时离开对话。
这改变了我对“核心特征”的看法。
它并不总是演示中最令人印象深刻的特征。
有时是用户不思议地伸入的小按钮,每天多次.
在发送按钮添加AI回复功能技术上直截了当之前,AI回复应该停止.
更难的决定是自动化应该在哪里结束。
一个选项是读取每个新消息,生成一个答案并自动发送.
这值得进行令人信服的示威,但在真正的客户对话中却令人不舒服。
价格、交货日期、付款条件和售后承诺具有实际商业后果。
AI模型可以写出自信的句子,而不知道是否允许使用该词的人做出这一承诺.
我选择了比较保守的设计.
MSG.AI可以使用用户故意保存的当前对话和商业信息来制作草稿.
草案进入编辑部,一个人在决定是否发送前可以审查并更改.
它不像完全自动化那样神奇,但它更接近真正的工作是如何完成的。
这里AI的有用作用是不要冒充销售员.
是为了减少推销员必须从空文本框开始的次数.
更快的批量发送并不一定更好 建造之后