杓子定規に聞こえないサポートチケット返信テンプレート集

シナリオを選んで、テンプレートを使う

私が最もよく目にする8つのチケットと、実際に送る返信です。角括弧の部分と、プレースホルダー構文も、自社のヘルプデスクに合わせて置き換えてください。正確な表記はこの下の表にまとめています。

サポートチケットの返信テンプレートが機械的に聞こえる理由

私が異を唱えたいのはここです。多くのチームは、問題が構造にあるときに文言を書き直してしまいます。

顧客に嫌われるテンプレートを読むと、ほぼ必ず同じ構造が見つかります。まずお礼から始まり、次にポリシーを繰り返し、受動態で謝罪し、最後に「他にご質問があればお知らせください」で締めくくる。4つの文のうち、顧客が書いてきた内容に触れているものは1つもありません。9時間も返信を待った顧客がそれを読めば、誰もメッセージを読んでいないと正しく結論づけます。

人々が気づかないテンプレートとは、具体性から始まるものです。「ご注文は火曜日に倉庫を出発し、現在ミラノで止まっています」という一文は、その後がすべて事前に用意された文章であっても、人間らしく読めます。

このルールについて私が読んだ中で最も鋭い指摘は、あるHacker Newsのスレッドから来たもので、もう10年以上前のものです。

"I've worked in customer service, and the reps use 'canned text' all the time for common issues. I assumed this was common knowledge. Not doing so would be a recipe for RSI within a couple weeks.

The problem with canned text is when it's reused on the same person, which leads to anger on the part of the recepient (or suspicions that they're being serviced by a robot)."

mullingitover, Hacker News

問題は同じ人に対して繰り返し使うことにあるのであって、テンプレート化そのものではありません。つまり本当に必要な防御策は、より温かいトーンではなく、ひとつのルールです。同じマクロを同じスレッドで二度使わないこと。

eesel自身のトライアルデータは、この点に実数を与えてくれます。あるドイツのECチームのロールアウトでは、担当者がAIの下書きをそのまま送ったのはわずか12%で、支配的なパターンは「ざっと見て書き直す」でした。8〜15文の下書きを1〜3文の返信に書き換えていたのです。この書き直しのうち約65%は長さとトーンに関するもので、下書きが事実として間違っていたケースは約5%程度に過ぎませんでした。これは定型応答に対して担当者が抱く不満とまったく同じです。テンプレートは正確でも、目の前のチケットに対しては長さが違う、トーンが違う、ということです。

そこで、私がすべてのテンプレートに求める5つの構成要素を紹介します。

1. 具体的な問題を最初の一文で名指しする。 相手の言葉と注文番号を使うこと。
2. すでに行った対応を伝える。 過去形で、具体的に。「倉庫に確認しました」は「確認中です」より優れています。
3. 次に何が起きるか、いつまでに。 日付を示すこと。「近日中に」でも「できるだけ早く」でもありません。
4. 相手に必要なこと、または何も必要ないことを明示する。
5. 人間へのエスカレーション経路。 返信が壁のように感じられないように。

3番目を省くと、返信は門前払いのように読まれます。5番目を省くと、ボットのように読まれます。それ以外はすべてスタイルの問題です。同じ構造をメールに特化して適用した実例が14個、カスタマーサービスのメールテンプレートの記事にさらに掲載されています。

AIに最初の下書きを書かせているチームにとって、この長さに関する発見には実践的な意味があります。プロンプトを工夫するだけでは解決しません。チーム自身が送った返信を学習させることで解決します。それが、トーンのスライダーではなく実例からブランドボイスを維持することを主張する理由でもあります。

各ヘルプデスクでテンプレートがどこにあるか

どのヘルプデスクにもこの機能があります。そして、どのツールもそれぞれ違う呼び方をしているため、移行の際にはちょっとした手間になります。ここでは6つのツールで同じ機能を比較し、実際に何が異なるのかをまとめました。

1つのツールについて手順だけ知りたい場合は、Zendeskのマクロの作成について個別の解説があります。GorgiasのマクロガイドはEC向けの内容を、Freshdeskの定型応答はFreshdesk版を扱っています。

この表から特に取り上げておきたい点が3つあります。

Zendeskのマクロはまったく自動化できません。 移行してきた人がいつも驚くポイントです。Zendeskは、マクロは「アクションのみを含み、条件は含まない」と明言しており、これはチケットを評価しているのがシステムではなく担当者だからです。マクロを発火させるトリガーアクションは存在せず、それを求めるコミュニティリクエストは今もオープンのままです。公式に文書化された回避策は逆向きの仕組みで動きます。マクロがタグを追加し、そのタグがトリガーを発火させるのです。自動初回返信が欲しい場合、それはZendesk自動返信ルールやAIエージェントの仕事であり、マクロライブラリの仕事ではありません。

Freshdeskではテキストを二度書く必要があります。 定型応答は自動化ルールに紐付けられません。自動化エディタでは代わりに「依頼者へメールを送信」というフリーテキストの本文を用意することになるため、あいさつ文が2箇所に存在してしまい、定型応答を編集してもルール側は更新されません。ライブラリの上にFreshdesk自動返信を構築する前に知っておく価値があります。

フォールバック値を用意できるのはHelp ScoutとFrontだけです。 Help Scoutの構文は{%customer.firstName,fallback=there%}、Frontの構文は{{recipient.first_name | 'there'}}です。Zendesk、Freshdesk、Gorgiasでは、空のフィールドは単に空欄でレンダリングされるため、「こんにちは、」というメールが名前を登録していない相手に届いてしまいます。これは実際のキューで、毎日のように起きていることです。

プレースホルダーの落とし穴

私は壊れたテンプレートを送ったことがあります。キューを1ヶ月以上担当したことがある人なら、誰でも経験があるはずです。以下は特にダメージの大きい落とし穴で、いずれもベンダー自身が文書化しており、その多くはZendeskマクロの問題点のまとめでも再び取り上げられています。

Problemチケットで間違った名前が漏れてしまうZendesk。 {{ticket.requester.name}}を含むマクロでProblemチケットに返信すると、Zendeskはその依頼者の名前を、紐付いているすべてのIncidentチケットにも送信してしまいます。解決策はバックスラッシュです: Hello \{{ticket.requester.first_name}}。これはZendeskが文書化している回避策で、まず自力では思いつかない類のものです。

マクロの一括適用で件名が壊れる。 Zendeskではビューから最大100件のチケットに一度にマクロを適用できますが、一括更新のドキュメントによれば、件名内のプレースホルダーは文字通りの角括弧付きテキストとして保存されます。顧客には{{ticket.created_at}}というタイトルのメールが届くことになります。一括処理では添付ファイルも黙って削除され、マクロ内のCCアクションも動作しません。

ルールから発火したテンプレートが間違った人物の署名になる。 Gorgiasは、ルールがマクロを適用した場合(担当者ではなく)、すべてのcurrent_user変数をアカウントオーナーに解決してしまうため、自動送信の返信がCEOの署名になってしまいます。Frontも同じ問題を逆の症状で抱えており、ルールから送信された返信では{{user...}}変数が空欄になります。

Help ScoutからHubSpotへの移行はすべてのテンプレートの書き直しを意味します。 HubSpotはスニペットとテンプレートで波括弧を完全に禁止しています。これはレンダリングサービスが壊れてしまうためで、{%customer.firstName%}のようなものはすべて、Personalizeピッカーで手作業により置き換える必要があります。半日ほど見込んでおいてください。

そして最も痛かったのは、自社のケースです。あるドイツ語版の下書きに、そのまま{{ticket.requester.first_name}}が生の状態で埋め込まれた状態で顧客に送信してしまい、オランダ語版では未入力の[Employee Name]が残っていました。修正はしましたが、だからこそ今は「欠落フィールドがあるチケットでもきちんとレンダリングされるか」を、テンプレートを共有する前の必須チェック項目として扱っています。あれば良いという程度のものではありません。

テンプレートライブラリは劣化する、備えておく

顧客との会話で何度も耳にするパターンがあります。1ヶ月目、20件のマクロを作り、誰もが気に入ります。6ヶ月目には80件になっています。担当者それぞれが自分のマクロを追加していったからです。2年目には300件になり、そのうち6件は2025年に変更された送料が記載されたままで、検索ボックスでもう良いものを見つけられません。

これは仮の話ではありません。月間約7,000件のチケットを扱うあるDTCサプリメントブランドの運用リーダーは、社内のノウハウがSOP文書、文字起こしされていない動画の解説、そして「多くの古くなったマクロ」に散らばっていると教えてくれました。彼らが持っていたのは、本当の意味での資産ではありませんでした。検索ボックスが付いたメンテナンス負債だったのです。

担当者たちも同じことを内側から語っていて、こちらの方がユーモラスです。

"lol i'm helping the supes clean up a 6 year old macro library that has sunset nothing. some of the most used ones get an update when the policies or products change but typically we just write a whole new one and leave the old one to rot 🥲"

u/mensfrightsactivists, Reddit

これが実際の仕組みです。誰も編集せず、みんなが複製する。

上限は十分に緩く、何も歯止めになりません。Zendeskは1アカウントあたり5,000件の共有マクロを許可しており、Gorgiasも同じ5,000件が上限です。どちらの数字も目標にすべきではありません。

私が実際に四半期ごとに行うこと。

• 利用状況で並べ替え、ゼロのものを削除する。 90日間使われていないものはすべて削除します。Zendeskでは、そもそも利用状況で並べ替えるにはSuite GrowthまたはSupport Professionalが必要で、マネージャーにレポートを約束する前に知っておく価値があります。
• 数字を明記するすべてのテンプレートに担当者を付ける。 価格、返金期間、SLA、配送見込み。これらは静かに間違っていくものです。
• 命名規則をフォルダ代わりに使う。 Zendeskはタイトル内の二重コロンでネストします。例: Refunds::Declined::Outside window。これがネストできる唯一の方法です。リストがすでに散らかっている場合はマクロカテゴリの整理にさらに詳しい情報があります。Help Scoutには手動での並べ替えが一切なく、返信はアルファベット順に表示されるため、命名規則だけが頼りです。
• 何を個人用として残すか決める。 Zendeskは個々の担当者が個人用マクロを持てる唯一のツールで、個人的なショートカットには最適ですが、共有すべきポリシー文には向きません。どこで線を引くべきかは個人用と共有マクロのガイドで解説しています。
• 削除する前にエクスポートする。 Gorgiasは4列(name、body_text、tags、id)のCSVにエクスポートでき、一致するidで再インポートすればその場で更新されるため、スプレッドシートでの一括編集がしやすくなっています。Zendeskにもエクスポート手段があり、その仕組みはマクロのエクスポートとインポートのガイドにまとまっています。

この監査は地味な作業です。しかしそれがすべてでもあります。すべて正しい40件のテンプレートは、6件が嘘をついている300件のライブラリに勝ります。

私がこれまで見た中で最もうまくいっているルーティンの説明は、あるZendesk管理者が語っていた週次のサイクルでした。

"Yes. We run our email macros by our QA so we know we're doing best response (oh, we feed it in ChatGPT that's pre-configured with our support bible) and update everyone on Slack that it's good to go and everyone uses it, it saves so much time! We also create macros to auto-tag tickets and complete tagging of forms. In our weekly meetings we calibrate on correct tagging, macros to add, edit, archive."

u/fast8048, Reddit

QAレビュー、それからSlackでの告知、そして追加・編集・アーカイブが行われる週次の調整会議。同じスレッドの別の管理者は、実際にかかる時間として月1時間ほどという現実的な数字を挙げていました。それが、嘘をつかないライブラリを維持するコストです。

テンプレートを書くのをやめるべきとき

テンプレートが適した場面は、多くのチームが思っているより狭い範囲です。それを決めるのは2つの変数です。そのチケット種別がどれだけの量あるか、そしてそのチケットがどれだけばらついているか。

配送状況やパスワードリセット、「Xへ配送していますか」のように、量が多くどのチケットもほぼ同じ内容である象限では、人間が1日に40回もテンプレートをコピーすること自体が高くつくAPI呼び出しのようなものです。AIチケッティングシステムがその場所で力を発揮し、その成果は雰囲気ではなく動くデフレクション率として表れます。

量は多いがばらつきもある、例えば請求に関する紛争のような場合は、テンプレートを骨格として使い、中身は人間が書くのが望ましいです。それを担うのがAIマクロです。量が少ないなら、そのまま書けばいいだけです。

最初に自動化する価値があるECの3カテゴリは、ほぼ常に返金、交換、配送で、ゼロから書き始めるのではなく出発点が欲しい場合はAIマクロテンプレートとしてすでに用意されています。これらを正しくルーティングすることは、回答自体と同じくらい重要なので、返信を下書きする前に走るチケットトリアージと組み合わせてください。

r/Zendeskのあるエージェントは、私よりも上手にこの中間地点を言い表していました。

"Pretty accurate tbh. Macros work best as a 70% draft, not a final reply. Once they get stale, agents absolutely start retyping, and yeah, 20 to 40 "same-ish" responses a day isn't weird at all. What makes them stick is good naming, folders by scenario, placeholders, and letting agents edit/own them instead of using stuff leadership wrote years ago."

u/palestagnation, Reddit

テンプレートは70%の下書きです。残り30%こそが、顧客が実際に読む部分です。最初の70%がマクロから来ていてもAIから来ていても、これは変わりません。逆の見方もできます。同じスレッドの別の担当者が指摘していたように、AIによる下書きはライブラリの代わりにはならず、そこから学習する仕組みだということです。つまり、劣化したマクロライブラリは、静かにAIの出力も蝕んでいくのです。

これまでの取り組みが無駄にならないのが救いです。マクロは捨てるものではなく、第一級のナレッジソースです。私たちが一緒に仕事をしているあるドイツのイベント企業は、ヘルプセンター、マクロ、過去のチケットからなる580件のドキュメントで運用しており、返金、バウチャー、主催者からの問い合わせにわたって、実際のドイツ語チケットを完全自動で処理するボットを稼働させています。

これが最後に伝えたい視点の転換です。すでに維持しているライブラリは、学習データそのものです。先ほどの「9件のマクロから56件の解決」という数字は、それが小規模でどう表れるかを示しています。

eeselを試す

Zendesk、Freshdesk、Gorgias、Front、Help Scoutのいずれかを使っていて、マクロライブラリが担当者以上に働いているなら、eeselが具体的に行うのはこれです。すでにあるマクロ、過去のチケット、ヘルプセンターを読み込み、普段使っているヘルプデスクの中で返信を下書きします。新しいタブを開く必要も、テンプレートを別のツールの形式に書き直す必要もありません。

特に取り上げたい点が2つあります。1つ目は、ワークフローが内部メモであることです。担当者はチケットに@eesel draft a replyとタイプするだけで完全な下書きをレビュー用に受け取れます。これはマクロを呼び出すのと同じ操作感です。2つ目は、顧客に届く前に、過去のチケット約100件でシミュレーションを実行し、AIが実際に言っていたであろう内容と実際に人間が送った内容を比較し、そのギャップレポートを読めることです。これを作ったのは、自信満々に聞こえるボットが間違った回答をする場面を見てきたからで、それを過去のチケットで見つけておく方が、稼働中のキューで見つけるよりずっと良いからです。

"It is getting us to the right articles really quickly and easily, as well as curating well-formed responses with consistent, on-brand tone, still keeping our own style and still keeping that human touch."

Eddie Stephens、CartonCloud社 サービスデスク リード

無料で試すことができ、セットアップは導入プロジェクトというより、数分で終わる程度のものです。

Zendesk統合は、マクロを多用しているチームがまず最初に選ぶことの多い選択肢です。ネイティブのFreshdesk統合もあり、ECのキュー向けにはGorgiasもあります。すでに優れたテンプレートが書かれているなら、作業の大部分はもう終わっています。