一个把每位新用户领到他第一次成功的智能体——并且知道他是否真的到达了
一个把激活当作引导式旅程来运行的智能体——迎接每位新注册者，一步步领他走到第一个真实成果，依据他在你产品里*实际做了什么*而非嘴上说什么来作出反应，并跨应用、邮件和聊天持续触达，直到他配置就绪。当他被激活时，它把人交接出去；当他卡住时，它介入。
一条真正的激活旅程，因人而异
一条 storyline 领每个新账户走过真正要紧的那些步骤——接一个数据源、搭出第一个东西、邀请一位同事——一次一步，精确记住每位用户走到了哪里，而不是把同一套序列轰向所有人。
由他做了什么驱动，而非他说了什么
一步的前进，是在你的产品报告了那个真实事件时——数据源已接上、第一份报表已生成——而不是在用户声称他做了时。激活是被测量出来的，不是猜出来的。
在他所在之处触达他
因为进度是按人保存的，同一段旅程会跨应用内助手、邮件和聊天延续——于是一次轻推落在用户实际所在的任何地方，并从半途接着来。
在他卡住时介入
在一步上闲置太久，或明显卡住，旅程就分支到一条更轻的路径或一份帮助的提议——而不是任由账户悄悄漂向流失。
把一位客户成功经理扩展到千万级
一位好的上手专员的判断——下一步做什么、何时推、何时收——作为一张图运行，同时服务每一个账户，只把那些真正需要真人的账户交到人手上。
激活是大多数 SaaS 悄悄流失用户的地方。注册很容易；而从“账户已创建”走到“这如今成了我一周的一部分”，是一个多步骤流程——接上数据、搭出第一个东西、拉一位同事进来、养成习惯——而且每位用户都不一样。一套定时的邮件序列托不住它，因为无论那个人是否真的做完了那一步，它都照发。一个普通聊天机器人也托不住它，因为对话一结束它就忘了。
一个上手智能体把激活作为一条 storyline 来运行——一段它与每个新账户一起走的旅程。它迎接他们，一次一步领他们走到第一个真实成果，而且——这才是要紧的部分——它依据他们在你产品里实际做了什么（通过一个回调报告回来）前进，而不是依据他们声称做了什么。进度保存在这个人名下，所以同一段旅程会跨你的应用内助手、邮件和聊天延续，并在几天后从正确的那一步续接。当有人卡住时，它分支到一条更轻的路径或提供帮助；当他被激活时，它把人交接出去。
这就是一位好的上手专员的判断——下一步做什么、何时推、何时收——作为一张图运行，同时服务成千上万个账户，只为那些真正需要的账户拉进一位真人。
常见问题
- 这和一套上手邮件序列有什么不同？
- 一套序列按定时器发出，不管用户做了什么。这是一段有状态的旅程——每一步只在用户到达真实成果时才前进（由你产品自身的事件测量），它记住每个账户走到了哪里，并在有人卡住时分支。它对用户作出反应，而不是朝他广播。
- 它怎么知道用户是否真的完成了一步？
- 你的产品会通过一个回调把真实事件——数据源已接上、第一份报表已创建——报告给智能体，那一步在收到这个信号时前进。它依据你产品里发生的事前进，而不是依据用户嘴上说他做了。
- 同一段旅程能跨应用和邮件延续吗？
- 能。每位用户的进度保存在他名下，而非某一次会话，所以旅程会跨你的应用内助手、邮件和聊天延续——一次轻推能在他所在的任何地方触达他，并从正确的那一步续接。
- 搭建它需要工程开发吗？
- 你把旅程作为一张图来设计——步骤、条件、分支——无需写代码，再通过一个简单的回调把你产品的事件接上去。智能体从你自己的文档和帮助内容作答，所以它谈论的是你的产品，而不是一个通用产品。
- 用户卡住时会怎样？
- 一步可以按时间或按信号分支——闲置太久、反复尝试失败——转到一条更简单的路径、一条有针对性的提示，或交接给一位真人。账户在它正在漂移的那一刻就得到关注，而不是等它流失之后。