散装信息听起来像一个直截了当的生产力特征:写一次,寄给许多人,并节省大量重复的工作.
我第一次为MSG.AI建立工作流程时就是这样看待的。
曾经我有一个工作排队, 无法想象的拖延, 进度跟踪, 和暂停和重置控制, 技术问题是可以解决的。
困难的问题是决定何时应使用该特性。
工具越可靠,谈论克制就越重要。
经常讨论一些客户发散装邮件有合理的理由,认为这与冷酷的外联是同义词。
在真正的客户业务中,并非总是如此。
企业可能需要告知现有客户交货延误的情况。
销售人员可能需要在一次交易展上与提出要求的人分享更新的文件.
支助小组可能需要将服务中断通知受影响的客户。
供应商可能需要向活跃的买方通报节假日时间表。
这些信息可以有用、及时和预期。
重复部分已开始运作。
开启了数十个聊天,粘贴同样的更新,检查姓名,附上正确的文件,并记住谁已经收到它,为错误创造了空间.
任务队列可以减少机械工作.
但解决机械问题并不能回答更重要的问题:这个人是否应该收到信息?
同意不能作为发送间隔开发者来实施,比如能够以设置表示的问题.
如果发送太快产生风险,则添加延迟.
如果相同的时间看起来不自然,则随机划分间隔.
如果任务太大,则将任务分成批.
如果用户出错,则添加预览屏幕.
这些管制是有用的,但并不引起同意。
在不想要的信息之间延迟5分钟仍然会产生不想要的信息.
随机计时不会将未知电话号码变成现有的客户.
预览可以显示一个不正确的收件人列表,但它不能确定每个收件人是否期望收到发件人的消息.
这种区别成为我最重要的产品教训之一:操作保障和许可是不同的层次.
软件可以帮助某人小心发送.
发件人仍负责决定来文是否适当和合法。 “规避禁令”这一首要目标是错误的。
我能发送多少信息?
什么延迟是安全的?
我如何避免被禁?
这些问题是可以理解的,但它们使问题倒退。
如果主要目标是找到一个平台所能容忍的不受欢迎的外联的最大数量,那么任何设置都不能使工作流程健康.
平台限制变化,接受者行为不一,账户历史关系重大.
没有普遍的数字能够保障安全。
更好的一组问题是:收件人是否已经认识发件人?
消息是连接到现有的请求、命令还是关系?
内容对这个特定受众有用吗?
接收者能否轻易地要求不要收到未来的更新?
如果信息是手动发送的,它还会觉得合理吗?
如果这些问题产生不舒服的答案,减缓任务不是解决办法。
良好的控制在发送前应该能够看到错误,一旦我停止将速度作为主要产品收益来对待,设计的优先次序就会改变.
接收者审查变得比导入按钮更重要.
一个小型的测试发送比最大吞吐量变得更加重要.
与大量“完成的”成果相比,每个接受国的成果变得更加重要。
我现在认为必要的控制是故意普通的:在开始前审查最后的接收者名单。
预览个性化变量而不是假设它们是正确的.
在更大的任务之前发送一个小测试.
允许任务暂停或停止非医学