毎朝、同じように始まっていました。 メールボックス全体をスクロールする。 何が新しいのかを把握する。 すでに進行中の会話からエスカレーションを切り分ける。 緊急のものにフラグを立てる。 そしてようやく — そのすべてが終わってから — 返信を始める。
Artiomが仕分けを終える頃には、その日の最もフレッシュな時間をデータ入力に費やしていました。 誰か一人を助けられるようになるまでに、約四十分。
ArtiomはSparkのカスタマーサクセスで働いています。 彼の仕事はパーソナルな部分です。主要なアカウント、エスカレーションされたスレッド、彼が大切にしている継続的な関係。 彼はそれらを自分のメールボックスから一対一で対応しています。 人間らしく感じられるのは、実際に人間だからです。
しかし、パーソナルなメールボックスも他と同じように一杯になります。 1日に何十ものスレッド、そのどれもが彼自身が対応することを選んだものです。 そして難しいのは、決して返信することではありませんでした。 難しかったのは、返信する前に行わなければならない仕分けでした。
そこで彼は、Spark CLIを通じて受信トレイに接続したエージェントに仕分けを任せました。 彼は自分が必要とされる部分を手元に残しました。 そしてそのために新しいシステムを学ぶ必要はありませんでした — 彼は自分自身のものを使い続けました。
まずは仕分けから
忙しい受信トレイのコストは、返信を書くことではありません。 それは、どの返信を、どの順番で、どんな文脈で書くべきかを見極めることです。 その仕分けは本当の仕事が始まる前に行われ、毎日発生します。
Artiomはすでにそれに対する優れたシステムを持っていました — 彼が何年もかけて作り上げたフォルダー、Need Reply、Demo Request、Escalated to QA、Beta Feedback、Feature Requestなど。 それらのフォルダーは機能していました。 それを手作業で最新の状態に保つことがコストでした。 彼が望んでいたのは、自分自身のシステムを、自分の代わりに維持してもらうことでした。
それこそがSpark CLIの役割です。 Spark Desktopから読み取ることで、すでにSparkに保持している受信トレイにAIエージェントを接続します。 追加したすべてのアカウント — Gmail、Outlook、iCloud、Yahoo、あらゆるIMAPやEWSアカウント — に対して、一つの接続で機能します。 方法を押し付けることはありません。 あなたの方法を実行します。
自分で仕分けする受信トレイ
Artiomは1日に2回、仕分けを実行します — 一度は十一時頃、もう一度は五時頃。 エージェントは前回の実行以降に届いたものを読み取り、彼がかつて手作業で行っていたことをまさに実行します。
各スレッドを適切なフォルダーに振り分けます — 彼がすでに使っていたのと同じNeed Reply、Demo Request、Escalated to QAのフォルダーです。 新たなエスカレーションを、すでに進行中の会話から切り分けるので、新しい引き継ぎが対応途中のスレッドの下に埋もれることはありません。 そして、待てるものとは別に、今日本当に返信が必要なものを浮き彫りにします。
彼は自分の分類体系を捨てて、他人のものを学ぶことはしませんでした。 彼はすでに従っていたルール — 誰が何を担当するか、何が緊急とみなされるか、「Escalated to QA」が本当は何を意味するか — を説明し、エージェントがそれを適用します。
「私は他人のシステムを採用したわけではありません。 すでに持っていたものを説明しただけで、今ではそれが自ら維持されています。」
だから彼が受信トレイを開くと、すでに整理されています。 かつて仕分けから始まっていた朝が、今では仕事から始まります。
彼独自の声で書かれたドラフト
ほとんどの返信は、Artiomが今でも自分で書いています。 パーソナルなタッチこそが、彼が自分のメールボックスから作業する理由のすべてであり、ほとんどのスレッドには彼とキーボードがあれば十分です。 彼はすべてをエージェントに任せることはなく、そうしたいとも思いません。
しかし、彼がドラフトの支援でエージェントに頼る明確なケースもあります。 キューが溜まり、顧客がすでに長く待たされている場合。 あるいは、良い回答をするために、あちこちに散らばった事実をまとめる必要がある場合 — 変更履歴、ヘルプドキュメント、二、三本の古いスレッド、正しいバージョン番号。 一言書き始める前に、十分間の情報収集が必要になるような返信です。 そこでエージェントがその存在価値を発揮します。
彼はその声については懐疑的でした。 一般的なAIの返信は返信しないよりも悪く、一日中顧客メールを読んでいる人なら誰でも見抜けます。決まり文句、「Great question!」、堅苦しい構成。 そこで彼はエージェントに、単なる声ではなく、彼自身の声 — 彼が実際に顧客に対して書く書き方を教えました。 温かく、平易で、聞かれたことだけに答え、余計なものはなく、正しいSparkの用語を使う。 Sparkのアップデートが問題を解決する場合、ドラフトはトラブルシューティングの手順の下に埋もれさせるのではなく、アップデートとリンクを先頭に持ってきます。 なぜなら、それが彼のやり方だからです。
「一般的なAIの返信は、返信しないよりも悪い。 だから私はエージェントに、単なる声ではなく、私の声を教えたのです。」
それらのスレッドでは、エージェントが彼の書き方で返信をドラフトし、散らばった事実はすでにまとめられています。 彼はすべてのドラフトを読み、送信するのは彼自身です。 何も勝手に送信されることはありません。
「ドラフトのおかげで白紙から始めずに済みます。 判断は私のものであり続けます。 送信ボタンも同じです。」
実際に何が変わったか
それは彼を置き換えませんでした。 かつて彼の朝を奪っていた二つのこと、つまりメールボックス全体の仕分けと、回答が一度に五か所に散らばっている返信での時間のかかる情報収集を取り除きました。
その時間は、人を必要とするスレッドに戻ります。 怒っている顧客。 厄介なエッジケース。 じっくり話し合う価値のある良いアイデアを持ったベータユーザー。
「それは私を置き換えていません。 人々を助け始める前の四十分間の仕分けを取り除いてくれたのです。」
従来の常識に反しますが、それは真実です。 より良いシステムを探しに行かないでください。 すでに信頼しているものを説明し、エージェントにそれを維持させましょう。 機能するカテゴリーは、あなた自身の仕事を中心に構築したものです。 それらは置き換える必要はありません。 必要なのは維持することです — あなたが手作業で行ってきた部分です。
どこから始めるか
すでにお持ちの受信トレイで、今日からこれを試すことができます。 Spark CLIのRead accessは、すべてのプランで無料です。 デスクトップ上のSparkを通じて、エージェントをメール、連絡先、カレンダー、会議メモに接続し、何も送信したりあなたの代わりに行動したりすることなく、コンテキストを読み取り整理できます。 それは、Artiomに朝の時間を取り戻させたすべてをカバーします。
より多くの手作業 — ドラフト作成、アーカイブ、ラベル付け、共有受信トレイ全体への割り当て — を自動化する準備ができたら、Triage accessがそれを行います。何かが起こる前に、あなたが読んで承認します。 これはSpark Proに含まれています。
エージェントが仕分けをします。 あなたは重要な仕事をします。
Spark CLI向けの既製スキルを github.com/readdle/spark-cli-skillsで閲覧できます。
