カスタマーサポートSOPの書き方：エージェントもAIも従えるSOPを作る

要約

カスタマーサポートSOPは、ある種類のチケットに対する手順書です。適用条件、確認すること、ケースごとの対応、エスカレーションの場面を定めます。機能するSOPは短く、if/thenのステップで書かれ、マクロにリンクされ、名前のある1人の担当者とレビュー日を持ちます。失敗するSOPは、顧客がすでに怒り出すまで誰も開かない長い文書です。

2026年の大きな変化は、SOPの読み手が新人とAIエージェントの2者になったことです。Zendesk、Gorgias、Freshdesk、Ada、Decagonはいずれも、新人エージェントに説明するように書いた手順を求めています。その形式でSOPを一度書けば、両方を教育したことになります。

SOPがNotion、Loom動画、古いマクロに散らばっているなら、eeselはそのすべてを過去のチケットとあわせて読み込み、同じ手順に従った返信を下書きします。SOPの修正は、次の研修ではなく次の回答に反映されます。

カスタマーサポートSOPとは

カスタマーサポートSOP（標準作業手順書）は、繰り返し起こる状況を毎回同じ方法で処理するための、書面の手順です。「返金依頼の処理方法」はSOPです。「返金は30日以内に可能」はポリシーです。「サムさん、返金を処理しました」はマクロです。

私はeeselでAIエージェントを作っていますが、そのエージェントが従う指示は、正直なところ、書式が厳しいだけのSOPです。そのため多くのサポートチームの手順を見ていますが、いちばんよくある混乱は、3つの層が1つの文書に混ざっていることです。ポリシーは年に1回、手順は四半期ごと、文面は毎週変わります。1つの文書にまとめると、編集のたびに他の2つを壊すリスクがあります。

実際の層の分け方は次のとおりです。

4行目は新しい層です。数年前、SOPは人間のためだけのものでした。今は同じ手順がAIエージェントにも渡されるため、形式が以前より重要になっています。

なぜサポートSOPの多くは読まれなくなるのか

SOPを書くのは簡単な部分です。難しいのは、誰も読まず、腐っていくことです。あるHacker Newsのコメントは、私が読んだどの運用の本よりもこの経済を的確に表していました。

"The TCO of knowledge is dominated by the maintenance cost, not the creation cost... The org must make it someone's job to grow, weed, and maintain these gardens."

kjellsbells, Hacker News

eeselの導入ではほぼ毎回、同じ3つの失敗パターンを見ます。

1. SOPはあるが、誰も知らない。 GDPRのチケットに引っ張り込まれたエンジニアは、"we already have a canned response to these requests - the person on the support team is a new hire and was unaware" と書いています（Hacker News）。手順自体は問題ありませんでした。肝心な瞬間に、誰も見せなかったのです。
2. 知識が散らばっている。 私が話を聞いたDTCのサプリメントブランドは、月に約7,000件のGorgiasチケットを処理しており、メール量の半分をAIに任せたいと考えていました。手順はClickUpのSOP、文字起こしされていないLoom動画、そして古くなったマクロの長い裾野に散らばっていました。AIがプロセスに従う前に、誰かがそれを見つける必要がありました。
3. 知識が人とともに去る。 Freshdeskを使う公共部門のITサービス会社は、月に約3,000件の複雑なERPチケットを処理しており、その年にシニアエージェント2人を失うので、退職前にノウハウを残したいとeeselの営業チームに話しました。これが暗黙知の典型です。2人が「ただ知っていた」ために、書かれなかった本物の手順です。

さらに、手順の書き方が悪いと、状況を悪化させることがあります。元eBayのサポート担当者は、"4 concurrent chats, offering pre-programmed macros often pointing to terribly written documentation the person had already read and was confused about" と振り返っています（Hacker News）。悪いSOPは役に立たないだけでなく、顧客を、混乱したのと同じページに送り返します。

3つすべてへの解決策は、ドキュメントを増やすことではありません。短い手順をチケット内に表示し、それぞれを正しく保つ責任者を1人置くことです。

どのサポートプロセスから先にSOPが必要か

すべてのチケットの種類に書面の手順が必要なわけではありません。セルフサービスのパスワードリセットは不要です。私は、次の基準のうち少なくとも2つで高く当てはまるプロセスをSOPの優先対象にします。

• 件数。 毎日発生するので、小さなばらつきが積み重なる。
• ミスのコスト。 お金が動く、データが漏れる、または法的な期限がある。
• 判断が必要。 エージェントが何かを決める必要があり、2人のエージェントなら違う決定をしうる。
• チーム間の引き継ぎ。 エンジニアリング、経理、法務が関わるので、エスカレーション経路を明示する必要がある。

ほとんどのチームでは、最初の5つは同じになります。返金と返品、アカウントアクセスと本人確認、障害とインシデント、データ削除またはエクスポートの依頼、マネージャーが必要なクレームです。まずそこから始めてください。しっかりしたSOP 5本のチームは、古びたSOP 50本のチームに勝ります。

また、すべてのプロセスが同じ形式を必要とするわけではありません。判断に使っているガイドは次のとおりです。

カスタマーサポートSOPの書き方

読み手が新人でもAIエージェントでも、私はこの手順で進めます。最初の5本は、1本につき1時間ほどを見込んでください。

1. 記憶ではなく、実際のチケット20件から始める

ある種類の最近のチケットを20件集め、トップエージェントが実際にどう解決したかを読みます。誰も書き残そうと思わなかったステップ（「まずギフトカードで支払ったか確認する」）や、毎週起こる例外が見つかります。記憶から書くと、自分が運用していると思っているプロセスになります。チケットからは、実際に運用しているプロセスが得られます。すでにチケット分析の習慣があるなら、20分の作業です。

2. トリガーは顧客の言葉で書く

最初の行は「このSOPはいつ適用されるか」に答えます。社内の呼び名ではなく、顧客の言い方で書きます。「顧客がお金を返してほしいと言う、二重に請求されたと言う、またはキャンセルして返金を求める」。これはAIにとって特に重要です。Zendesk自身のドキュメントも、英語では確実に一致する手順がフランス語では外れることがあり、対策はユースケースを顧客が使う言い回しで拡張することだと述べています。

3. 1ステップ1アクション、if/thenはすべて書き出す

これが品質を最も大きく引き上げます。Zendeskは手順の書き方のルールを公開しており、人間のライターにも渡したい内容です。1ステップに1アクション、明示的な「if... then...」条件、具体的な言葉（「アカウント情報を依頼する」ではなく「顧客に10桁のアカウント番号の提出を依頼する」）、そして常に同じ用語（「Premium Plan」と書き、ときどき「Gold Plan」と書かない）。Adaのガイダンスはさらに、すべての分岐にelseが必要で、すべてのフローに明示的な出口が必要だと加えています（Adaのドキュメント）。

ステップに「そして」が入っているなら、おそらく2つのステップです。

4. 例外と、誰が承認できるかを書く

ほとんどのSOPは理想的な経路を書いて終わります。痛い目に遭うのは例外のチケットです。あるHacker Newsのコメントは、不当に請求されたことを認めながら "could not refund me on the spot because of protocol" だったエージェントを描いています（Hacker News）。解決策はプロトコルをやめることではありません。例外の経路をSOPに書くことです。誰が、いくらまで、どれだけ早く承認できるか。数字を使ってください。「500ドル超はチームリーダーへ」なら従えます。「大きな返金は承認が必要」では従えません。

5. マクロをリンクし、文面を貼り付けない

返信はマクロに入れ、それを使うステップからリンクします。マーケティングがトーンを変えたり法務が一文を変えたりしても、編集するのはマクロ1つで、それを指すすべてのSOPは正しいままです。Zendeskはアカウントあたり共有マクロ5,000件、Gorgiasもマクロ5,000件が上限なので、足りなくなることはありませんが、SOPごとにコピーを作ると溺れます。Zendesk側については、個人用と共有マクロのガイドで扱っています。

6. 担当者を1人、レビュー日を決める

すべてのSOPの先頭に、1人の名前と「レビュー期限」を入れます。チームではなく、人です。これがないと、SOPはあるコメント投稿者が "backwaters of slowly rotting stuff" と呼んだものになります（Hacker News）。

7. 前提知識のない人でテストする

SOPをチームの最も新しい人、または別部門の人に渡し、それを使って実際のチケットを処理するところを観察します。AdaもAIの手順について同じことを勧めており、"with limited context" の人にピアレビューしてもらうとしています（Adaのドキュメント）。出てくる質問はすべて、欠けている一行です。これは私が知る限り、最も安上がりな立ち上がり期間の短縮策でもあります。

カスタマーサポートSOPのテンプレート

私が使っているテンプレートです。ナレッジベースにコピーして、プロセスごとに1つ埋めてください。

SOP: [Process name]
Owner: [One person]          Review by: [Date, 90 days out]
Applies to: [Channels, regions, plans]

WHEN (trigger, in the customer's words)
- [How customers phrase it, 2 to 4 examples]

DON'T USE WHEN
- [Look-alike requests that need a different SOP]

CHECK FIRST
- [Field or system to look at, e.g. order date, plan, payment method]

STEPS
1. [One action]
2. IF [condition] THEN [action + macro link]
3. ELSE [action + macro link]

EXCEPTIONS AND APPROVALS
- [Situation] -> [Who approves] up to [$ / limit], within [time]

ESCALATE TO
- [Team or person], via [tag / group / channel], when [trigger]

TAGS / FIELDS TO SET
- [Tag names, custom fields, status]

LINKED MACROS
- [Macro name], [Macro name]

CHANGE LOG
- [Date] [What changed] [Who]

「使用しない場合」のブロックは、Decagonがエージェントの手順を構成する方法から借りています。各手順は、説明、"When to use"、"When to not use" に分かれています。

記入例：返金依頼

典型的なECストア向けにテンプレートを埋めるとこうなります。数字は自社のものに置き換えてください。

この1つの表で、新人エージェントがSlackで尋ねるはずの疑問にすべて答えられます。そしてこれは、AIエージェントが必要とするものとほぼ同じで、多くのSOPガイドがまだ追いついていない話題につながります。返金のAI側については、返金依頼へのAI活用の記事でさらに詳しく扱っています。

SOPはAIエージェントへの指示にもなった

私が調べた主要なAIサポートプラットフォームはいずれも、人のためにSOPを書くように手順を書くことを求めています。これが変化です。よく書かれたSOPはAIエージェントの学習データであり、曖昧なSOPは、ボットが自信満々に間違える原因になります。

Zendeskが最もわかりやすい例です。事業のポリシーを記述すると、AIエージェントが従う手順マップが生成され、2026年5月時点で、複数ステップの手順はSuiteおよびSupportプランに含まれています。エディタは文字どおり、ステップを「as you would with a human agent」記述するよう促します。ステップ3の形式ですでにSOPを書いているなら、貼り付けられます。より広い設定は、ZendeskのAIエージェントの解説で扱いました。

Gorgiasは2つに分けます。Guidanceはポリシーを保持し、ストアあたり最大100エントリ、各30,000文字までで、Gorgiasは「among knowledge types, guidance carries the most weight」と述べています（Gorgiasのドキュメント）。Skillsは手順の部分を保持し、注文のキャンセルのようなアクションは、skillまたはguidanceの中からのみ実行されます（GorgiasのSkillsドキュメント）。Gorgiasはまた、30日の返品記事と14日のguidanceがあると回答が一貫しなくなると警告しており、これは先ほどの層の問題がAIの形で現れたものです。

Freshdeskははっきり言っています。Natural Language Workflowsでは、"existing SOPs, playbooks, or support guides can often serve as a starting point." としています。また、"deterministic, strictly sequenced, or compliance-driven processes" にはビジュアルビルダーを推奨しており、これは良い助言です。AI側の詳細はFreddyのAIエージェントの記事にあります。

ヘルプデスク以外から、参考にしたい指針が2つあります。OpenAIのエージェント構築ガイドは "use existing operating procedures, support scripts, or policy documents" と述べ、カスタマーサービスではルーチンが "can roughly map to individual articles in your knowledge base" だと指摘しています（OpenAI）。そしてSalesforceは、私がチームに最も伝えたい点を述べています。指示は非決定的であり、"don't replace the need for coded business rules." という点です。彼らの例は30日の返金ルールで、文章ではなく、条件を確認するアクションに入れるとしています。

これが、指示としてのSOPの正直な限界です。書かれた手順はAIを導きますが、保証はしません。Air Canadaの件は、人々が繰り返し立ち返る教訓です。

"Air Canada's chatbot returned sources along with its answer. ... Air Canada's argument was that because the chatbot response included a link to a page on the site outlining the policy correctly, Moffat should've known better."

Sayrus, Hacker News

正しいポリシーは存在していたのに、ボットは別のことを言いました。そのため、お金が動く、またはデータが漏れるものについては、AIの判断のためにSOPを書き、厳格な上限はアクションそのものに置きます。新人に返金上限を覚えておいてもらうのではなく、請求ツールに設定するのと同じ理屈です。だからこそ、AIガードレールと、きれいな人への引き継ぎは後付けではなくSOPに入れるべきなのです。

サポートSOPの置き場所

カスタマーサポートSOPの最適な置き場所は、チケットを開いたときにエージェントがすでにいる場所です。実際には、まずヘルプデスク、次に別ツールです。各ヘルプデスクが、自社ドキュメントによると何を提供しているかを示します。

この表のいくつかは、私が関わったチームでつまずきの原因になりました。

• Zendeskのエージェント限定記事にはSuite Growth以上が必要で、Suite Teamでは記事をエージェントだけに制限できません。また、Zendeskのエージェント向けauto assist手順が挿入できるのは公開済みの公開記事のみなので、社内限定のSOPはリンクできません。設定はZendeskのユーザーセグメントの記事で説明しています。
• Gorgiasには、エージェント限定記事の設定がそもそもありません。Unlisted記事は公開上は存在し、URLで到達できます。Gorgias自身が勧める社内手順サイトは、検索エンジンから隠した別のヘルプセンターです（Gorgiasのドキュメント）。多くのストアには問題ありませんが、機密情報は置かないでください。
• Frontは社内ナレッジベースをサイドバープラグインに表示しますが、返信への挿入ツールは公開のものが必要です。社内SOPは会話の横に表示され、作成画面には入りません。
• Freshdeskは、エージェント限定フォルダをSolution Article Suggesterに渡せますが、Freddy AI Copilotと公開記事25件以上が必要です（Freshdeskのドキュメント）。CopilotはProとEnterpriseでエージェント1人あたり月29ドルです（Freshdeskの料金）。

別のSOPツールが意味を持つ場合

専用ツールが役立つのは3つの場合です。手順の大半が他システムでのクリック操作である（スクリーンショットが役立つ）、各エージェントが読んだことの承認が必要、または複数部門が同じ手順を共有する。一般的な選択肢の費用を、各社の料金ページから示します。

今いちばん興味深いのはScribeです。キャプチャツールはクリックして進めた手順をガイドに変え、そのガイドをAIエージェントへの入力として打ち出し始めており、MCPまたはAPIで "directly to your AI agents" 渡せるとしています（Scribe）。

どの単体ツールにも当てはまる注意点があります。ヘルプデスクの外にあるSOPは、エージェントがチケットから到達できて初めて機能します。別のアプリを開いて検索する必要があるなら、特に4件同時のチャットの最中には、誰もやりません。導入を決める前に、サイドバーアプリやブラウザ拡張があるか確認してください。そして、エクスポートの手段を確保してください。G2のあるTrainualのレビュアーは、"the moment you stop paying you lose all your hard work making the SOP" と指摘しています（G2）。手順は、どのツールに入れても自社のものです。より広い比較は、カスタマーサポート向けナレッジベースソフトのまとめをご覧ください。

SOPを古くしない方法

古いSOPは、ないよりも悪いものです。それを信じたエージェントが、自信を持って誤った回答を送るからです。私に効いている仕組みは、大きな年次監査ではなく、小さなループです。

1. エージェントがワンクリックで抜け漏れを報告できるようにする。 チケットに「sop-gap」のようなタグを付けるだけで十分です。Zendeskのナレッジパネルでは、エージェントが記事にフラグを付けると、担当者向けのチケットが作成されます（Zendeskのドキュメント）。
2. フラグはチームではなく担当者に回す。 そのために、SOPの先頭に名前を置きます。
3. SOP、マクロ、AIへの指示の順に直す。 できれば同じ日に。最後を飛ばすと、AIは先月のルールを言い続けます。
4. それでも期限を決めてレビューする。 返金、アクセス、セキュリティは90日、それ以外は6か月にしています。
5. 抜け漏れタグを毎月見る。 同じSOPに3件のフラグがあれば、パッチではなく書き直しが必要です。ナレッジギャップ分析なら、大規模にそれができます。

リマインダーを自動化するツールもあります。Zendeskの記事検証では、管理者が最大20件の検証ルールを設定でき、記事の担当者が検証するまでメールが届きますが、Enterpriseのみです。

Document360は、レビュー日を過ぎた記事を「Stale」にし、Guruは期限切れのカードを検証者のタスクキューで未検証としてマークします（Guru）。G2でGuruをレビューしたナレッジスペシャリストは、それがサポートにとってなぜ重要かを述べています。

"Instead of the content becoming obsolete, the platform enforces ownership by prompting subject matter experts to re-verify knowledge on a set schedule. This maintains a highly trustworthy repository for our support specialists directly inside our communications tools."

Dairon P., G2

ツールは助けになりますが、習慣の代わりにはなりません。別のGuruのレビュアーは、書式のためにカードを編集すると、編集者が専門家でなくても自動的に検証済みになると指摘しています（G2）。緑のチェックは、誰かがクリックしたことを意味するだけです。手順が正しいという意味ではありません。

カスタマーサポートSOPが失敗する間違い

「SOPはあるが、誰も使わない」とチームが言うとき、私がよく見るパターンです。

• 論文を書く。 1画面を超えると、エージェントはチケット対応中に流し読みして、肝心のステップを見落とします。長い背景はポリシー文書に置きます。
• ポリシー、手順、文面を混ぜる。 編集のたびにリスクが生じ、誰も編集しなくなります。3つの層を分けてください。
• 例外に数字がない。 「大きな返金はエスカレーション」は、エージェントごと、AIごとに意味が変わります。
• チャネルや地域ごとに同じSOPをコピーする。 SOPの構造についてのReddit投稿はこう言っています。"Once you start duplicate SOPs, keeping them all current becomes its own job"（Reddit）。代わりに、1つのSOPの中で分岐させます。
• SOPを台本として扱う。 ティア1の台本はステップの見落としを防ぎますが、優れたSOPは権限の上限と理由を示し、SOPが想定しなかったケースにもエージェントが対応できるようにします。コーチングの側面はサポートエージェントへのフィードバックの記事で扱っています。
• AIにSOPを無チェックで書かせ、書き直させる。 あるコメント投稿者は、エージェントが "doing massive updates on Confluence constantly" し、結果が "full of hallucinations and nonsense" だったと書いています（Hacker News）。AIはチケットから下書きできます。文脈を知る人間が最終承認します。

新人エージェントをまとめてオンボーディングするなら、SOPはトレーニングの半分です。複数のタイムゾーンで運用しているなら、午前3時のシフト引き継ぎを一貫させるのもSOPです。

カスタマーサポートSOPのためのeesel

手順がヘルプデスク、Wiki、いくつかのLoom動画、マクロの山に散らばっているなら、eeselのAIヘルプデスクチームメイトはまさにその混乱のために作られています。Zendesk、Freshdesk、Gorgias、Front、Help Scout、そしてConfluence、Notion、Google DocsといったSOPのあるドキュメントに接続し、過去のチケットからも学ぶので、誰も書き残さなかったものも含め、トップエージェントが実際に従っているステップを拾い上げます。返信を下書きするか直接回答し、何かを有効にする前に、過去の数百件のチケットでシミュレーションして、どこでSOPに従い、どこで外すかを確認できます。

SOPにとって最も重要なのは、指示ページです。これは、応答ガイドラインとワークフローのステップを書いた単純な文書で、上のテンプレートと同じ形式で書かれています。リードがチャットで回答を修正すると、eeselはその修正を指示に書き込むので、修正は1人の頭の中にとどまらず、今後のすべての返信に適用されます。

始めるのに大きなライブラリは必要ありません。私が見た英国のあるサポートチームは、同期したZendeskマクロわずか9件から、eeselに56件のタスクを解決させました。明確なSOP 5本と数個のマクロで、思う以上に先へ進めます。

立ち位置をはっきりさせておくと、eeselは研修や承認のツールではないので、全エージェントが返金SOPを読んだという電子署名が必要なら、その用途にはTrainualなどを使い続けてください。eeselがするのは、AIと、その下書きをレビューするエージェントの両方が、すべてのチケットでSOPに従うようにすることです。eeselを試すなら、カード不要で100クレジットが無料で、自社のチケットをどう処理するか確認できます。