dispatch午前中の業務全体を自動化する。
あるいはその一部でも構わない。
休眠口座レポートの作成が完了すると、2つ目の処理工程が開始されます。リストにあるすべての口座を調査し、連絡先ごとにフォローアップメールを作成し、それを担当者に渡します。 営業担当者が主導権を取り戻す場所（リスト作成後、ドラフト作成後、あるいは全く取り戻さないか）は、別の製品ではなく、担当者自身のコピーライティングの設定事項である。
休眠口座レポート
各営業担当者の停滞している商談を見つけ出し、各顧客のサイトを実際のブラウザで開き、CSVファイルに書き込みます。
アウトリーチの草稿作成
同じCSVファイルを読み込み、各アカウントを調査し、概要をまとめ、連絡先ごとにグループ化し、メールを作成します。
読む、編集する、送信する
または、元のリストをそのまま使って自分で書き直すこともできます。 または、送信させてください。 どちらの場合も同じパイプラインです。
最初のパイプラインが完了したため、2番目のパイプラインが開始されます。
トリガー · workflow.succeeded、ID による 1 つの上流ワークフローにスコープされます
明白な方法、そしてそれが間違っている理由
2つのcronジョブ。 レポート 08:00、 08:15 。
15分というのはあくまで推測です。 暇な朝には、レポートはまだ実行中で、ドラフト作成ジョブは昨日のファイル、あるいは何も読み込まず、古いデータについて自信満々にメールを作成する。 誤った入力で実行されたパイプラインでも成功してしまうため、誰もそれに気づかない。
実際に何が起こるのか
作成プロセスは、レポートの完成を前提としています。
タイマーなし、推測なし。 レポートの処理が完了するとイベントが発生し、そこからドラフト処理が開始されます。 報告書の作成に1時間かかるなら、下書きは1時間待つことになる。 レポートが失敗した場合、ドラフト処理は一切実行されません。これは正しい動作であり、スケジュールでは表現できない動作です。
12のステップがあり、そのうち2つはモデルを使用する。
最初のパイプラインが書いたレポートを読んでください
新規の問い合わせではありません。 上流パイプライン自身の出力を読むということは、草案と報告書が、現場調査に至るまで全く同じ状況を記述しているということであり、両者が食い違うことはあり得ない。
この担当者の最も価値の高い5つのアカウントを見てみましょう。
1件のレップに絞り込み、値でソートし、上限を5件とする。 解析されたテーブルとソートであって、今日誰が重要かを決定するモデルではない。
それぞれの完全な履歴を取得します
連絡メモ、プランと支払い状況、連絡先記録、請求履歴、生涯収益、移行の複雑さ。 1アカウントにつき6回まで、一度に2アカウントまで。
各アカウントについて個別に簡単に説明する
アカウントごとに1回のモデル呼び出しを行い、そのアカウントのみを参照します。 有効期限切れ、更新中、またはプラットフォームが停止された後に更新中といった固定日付ルールに基づいて角度を決定し、冒頭で取り上げる価値のある単一の事実を選び出す。 小規模な状況、つまり一つの意思決定の場合、ローカルモデルは信頼できる。
連絡先ごとに概要をグループ化する
代理店は、1つの住所で多数の拠点を管理している。 5つのアカウントが日常的に2人に集約され、メールアドレスも5つではなく2つに絞られる。
一人につき一通のメールを書いてください
2回目にして最後のモデル募集。 完成した企画書しか見ることができず、生データを見ることはないため、数値を捏造することはできない。 顧客のアカウントに矛盾がある場合（例えば、1件は更新済み、3件は失効済みなど）、それらを1つの都合の良い主張にまとめてしまうのではなく、その旨を明記する必要がある。
配達し、コピーを保管する
下書きは担当者の作業場所にフォーマット済みで届き、すぐに使用できる状態になっている。また、その日のセットはJSON形式でアーカイブされるため、配信方法を変更してもパイプラインに手を加える必要がない。
営業担当者の間では、自動化について意見が一致していない。 彼らはそうする必要はない。
同じパイプラインが、3つの異なる地点で停止した。 3つの製品でもなく、展開でもなく、全社的な方針でもなく、営業担当者ごとにワークフローのコピーが提供され、それぞれが営業担当者が望む場所で終了する。
リストをください
最初のパイプラインの後で停止します。 毎朝、停滞しているアカウントのランキング付きCSVファイルが作成され、サイトはすでにチェック済みで、彼らはすべての文章を自分たちで作成している。 彼らが手作業で行うはずだった調査は既に完了しており、その関係性は完全に彼ら自身のものである。
下書きして、私が決める
一連の流れは、最終的に彼らが読み、編集し、送信する下書きで終わる。 判断を下すのは担当者だが、記録を探し出して更新日をじっと見つめる1時間は無駄になる。 今日運行しているのはこちらです。
送るだけ
あと一歩で終わりだ。 送信は承認制（メッセージごとにスマートフォンをタップする操作）にするか、承認が得られれば自動的に実行するように設定できます。 パイプラインの形状は変わりません。最後のステップで待機が停止するだけです。
誰もこれを最初から正しく仕様化できない
最初の実行で生成されたメールは、決して送信しないような内容だった。 2番目もそうだった。 編集されずにそのまま出力される状態にたどり着くにはループが必要であり、重要なのはそのループがどれだけタイトであるかだけだ。
実際のデータに基づいて、必要な情報をオンデマンドで入手できます。データについて質問する際に使用するのと同じチャットウィンドウからアクセスできます。
各ステップの入力と出力は記録されます。 悪いグラウンド、悪いステップ――どちらがどちらかは一目瞭然だ。
MCPに関する一文で説明されています。 ボックスのデータベース内の行は、保存時にリアルタイムで更新されます。
端から端まで約2分。 ローカルモデルなので、20回目の試行も1回目と同じ費用、つまり無料です。
結果として、実行のトリガーとなったレポートと一致しないアカウントが見つかりました。パイプラインがCRMに再度クエリを実行していたため、2つのスナップショットが一致しない可能性がありました。
何が変わったのか、一つの束縛。 最初のパイプラインが既に生成したファイルを読み込む。 スナップショットは1回、サイトチェックも1セットのみ、ずれは一切なし。
出てきたのは、すべてのメールがひとつの意見だった。 単一のモデル呼び出しによってそれらがすべて一度に書き込まれ、異なるアカウントが同じ3つの文に平坦化されてしまった。
Splitを2つのステップに変更したのはなぜか？アカウントごとにブリーフを作成し、そのブリーフから構成するという手順だ。 各呼び出しは、12個のアカウントのコンテキストではなく、1つのアカウントのコンテキストを取得します。
数ヶ月前に発表された更新日は、近日公開予定と説明されていた。 日付について推論するように求められた際、それは拙いながらも自信満々に推論した。
何が変わったのか、もう聞かないで。 スキルにおける明示的な決定表：今日という状況が与えられた場合、どの分岐が適用されるか。 このモデルは行を読み込むだけで、算術演算は行いません。
結果として、 0 ドルという価格が、まるでそれが実際の金額であるかのように顧客に提示された。
何が変わったのか？ルール：ゼロは欠損データであり、価格ではない。 決して口に出さず、代わりにフラグを立ててください。
結果として、顧客向け文書に内部スコアリングが反映され、メール本文に移行の複雑度評価が表示された。
何が変わったのか？ 1つの分野から2つの分野に変わった。 顧客が読むのはメールであり、それ以外のものはすべて担当者が読む。
出てきたのは、途切れることのない文字の羅列だった。 レンダリングエンジンを責める前に確認しておくべき点として、出力には改行が全く含まれていなかった。
段落区切りを必要とする指示と、その例文が変わりました。 書式設定のバグではなく、指示が抜けているだけです。
プラットフォームが提供するもの、そしてあなたが接続するもの
これを構築するのは、コードを書くのではなく、基本要素を組み合わせる作業だった。 自分の基準値を設定する際には、その境界線がどこにあるのかを確認する価値がある。
ディスパッチは
組み込み機能 ― すべてのワークフロー、すべての機器で利用可能。
- ワークフロー間の完了トリガー
-
foreachステップの種類 - CSV、JSON、jq変換
- スキル、承認、実行履歴
✓ 配線します
あなたのボックスのデータベース内の1行。 保存した瞬間から活用できる ― デプロイも再構築も不要。
- どのパイプラインがどのパイプラインに供給するか
- 誰のアカウントで、いくつ
- 2人のエージェントが指示を出す
- 停止する場所、担当者1人あたり
foreachは アイテムごとの処理を実行します。 だからこそ、右側のコラムはプロジェクトではなく、午後のひとときで取り組めるものなのだ。 ―そして、反復回数ごとのバリエーションが、フォークではなく複製と編集になる理由。 引き継ぎはあくまでツールなので、 どこで引き継ぎを停止するかはあなたが決めます。
本日発送開始 · 朝のレポート終了後から発送開始