上下文只能手动收集
自由留言往往只留下姓名和回电请求。重要细节还要再次询问。
源自 Marquiz
我们采用 Marquiz 式的问题收集方式,并加入回答快照、经理审核、版本、提案发布,以及与 CRM、Finance 和 Documents 的关联。
从 Marquiz 到商业流程
Marquiz 式问题让第一次沟通更清晰。SHD 将其推进到已审核的提案,而不是留在潜客列表中。
自由留言往往只留下姓名和回电请求。重要细节还要再次询问。
问卷会根据所选场景提问,并把回答保存到请求快照中。这是流程的起点,不是已批准的公开提案。
发送后回答不会消失
提案模板
提案由清晰的部分组成:范围、条件、计算和下一步。客户看到的是结果,而不是内部笔记。
需要完成什么,以及客户应该得到怎样的结果。
面积、对象、限制条件和请求中提供的回答。
何时开始、过程中发生什么,以及哪里需要检查。
价格范围和工作边界,不承诺自动完成计算。
客户需要做什么,才能从阅读进入决定。
模板保持顺序,团队仍然负责内容和价格。
客户路径
每个阶段都会留下记录:回答变成请求,请求变成工作快照,检查后的快照变成客户提案。
客户选择真正影响后续沟通的参数。
发送前确认经理会收到什么,以及是否遗漏了信息。
团队补充条件、确认边界并提出剩余问题。
客户收到范围清楚并带有下一步操作的已发布版本。
快照保存原始回答,方便与最终进入提案的内容进行比较。
快照记录输入信息,但不表示项目已经审核或获批。
已发布版本是检查后的结果,不是未经处理的问卷回答。
经理工作
由人做决定并负责内容。模块帮助团队保留从问题到发布的路径。
客户回答已经在一个快照中,不再散落在邮件和消息里。
经理澄清范围、例外、时间,以及需要写进提案的内容。
审核后发布当前版本,工作草稿仍保留在内部。
自动化保存上下文,但商业决定仍由经理负责。
提交请求前
模块连接问题、请求快照和提案,但不会把它们变成自动交易。
不是。问卷是入口场景。提交后会生成带回答快照的请求,由经理审核并转成已发布提案。
如果模板中定义了计算规则,模块可以计算一个数值。但在发布前,经理仍会检查范围、条件和最终价格。
不一样。页面、问题和跳转规则取决于当前启用的模板。
不能。发布前提案留在工作流程内部。
可以。新的约定应进入当前版本,而不是抹掉历史。
不是。模块记录路径和提案版本,决定与联系仍由团队负责。
提案上下文
我们会检查客户需要回答哪些问题、哪些内容要保存为快照,以及经理在哪里做决定。
从当前问卷、表单或聊天开始,建立不添加额外承诺的路径。