サポートの承認ワークフローが実際にカバーするもの
承認ワークフローは、チームの誰かが単独で動けないときに働きます。サポートでは、たいてい次の3種類の依頼です。
- お金： 担当者が付与できる範囲を超える返金、クレジット、お詫びの対応、手数料免除。
- 例外： 期限を過ぎた返品や、トラブルシューティングなしの解約など、文書化されたポリシーの外にあるもの。記録のしかたはサポート例外管理のガイドで解説しています。
- AIの作業： AIエージェントが下書きし、送信前に人が確認する返信やアクション。
お金のケースは最も古く、現場の担当者は業界を問わず同じように語ります。ある通信会社のサポート担当者が、実際のクレジット承認の階段を説明した例です。
"Supervisors can approve up to about $300 in credits, then whatever is left gets rolled up to their managers. Floor support or SME'S have about the same limit as a supervisor, but they do not have access to things like the credit qué and a few other things."
誰も文書にしていなくても、これはワークフローです。ロールごとの上限があり、一部の人しか見られないキューがあり、その上に上位への引き継ぎがあります。まず書き出すことが第一歩で、それはポリシー本体と並べてサポートSOPに置くべきものです。
多くのワークフローがつまずくのは依頼カードなので、ここから始めます。承認者はカードだけで判断できるべきです。
マネージャーがチケットを開き、やり取りをスクロールし、さらに注文まで調べる必要があるなら、承認は15秒ではなく15分かかります。キューの側からは、そのコストを毎週目にします。お客様は待たされ、担当者は自分が下していない決定の伝令役になります。
ツールを選ぶ前に、何が承認を必要とするかを決める
ツールの問いは二の次です。まず、そもそもどの依頼に第二の担当者が必要かを決めます。そのために2つのテストを使います。
テスト1：担当者の上限を超えているか？ 金額帯を設定し、各帯に承認者を置き、担当者には自分の帯より下のものは確認なしで処理させます。少額の承認は純粋な無駄です。37セントの返金で待たされたあるコメンターが指摘したとおりです。
"This is why for the store it is better to have a smoother process for small price adjustments, it should not be necessary to wait 15 minutes for the store manager's approval on a 37 cent refund, nor should he even have to deal with it at all, that is a waste of his time and salary to be attending to something so minor."
テスト2：取り消せるか？ AIが絡むとこちらの方が重要です。返金は取り消したり償却したりできますが、メールで伝えた約束は撤回できません。AIエージェントが承認なしで何をしてよいかを論じた最近のスレッドも、まさにこの点に落ち着きました。
"imo the cutoff isnt really about the action type, its about reversibility. if the agent does something you can undo in 30 seconds, let it run. if undoing it requires an apology email to a customer, that needs approval."
2つのテストを組み合わせると階段になります。以下の数字は例であり、基準値ではありません。ご自身の返金履歴から決めてください。
ほとんどのチケットは一番下の段で止まるべきです。返金チケットの半分が階段を上るなら、上限が低すぎるということで、上るたびにお客様の待ち時間が増えます。金額帯の決め方は返金承認マトリクスのガイドで詳しく扱っています。公平な反論もあります。現場の担当者は価格やポリシーがなぜそう決まっているかを常に知っているわけではないので、理由があって存在する承認もあります。目標は、承認をゼロにすることではなく、減らして的を絞ることです。
各ヘルプデスクが承認をどこに置いているか
eesel の導入で最もよく見るヘルプデスクのヘルプセンターを確認しました。大きく3つに分かれます。本格的な承認オブジェクトを持つツール、IT承認向けに作られたツール、そして「承認」が共有下書きと取り上げた権限を意味するツールです。お使いのものを選ぶと、設定、承認者が判断する場所、プランの条件が分かります。
要点はこうです。ステータス、クローズのブロック、記録を備えた承認オブジェクトが必要なら、チケット向けにそれを提供しているのは、この中では Zendesk Professional、Freshservice、Jira Service Management の3つだけです。ほかは運用で補います。
Zendesk：Suite Professional からの本格的な承認リクエスト
Zendesk は使用例として返金を挙げています。担当者が返金チケットを受け取り、承認リクエストを作成し、チームリードなどの承認者に送ります。Zendesk の承認に関するドキュメントによると、ルールは有用な形で厳格です。
- 1リクエストにつき最大5人の承認者。複数いる場合は全員の承認が必要で、1人の却下でブロック全体が却下されます。
- 承認者は、チケットの依頼者、担当者、リクエストの作成者のいずれにもなれません。職務分掌が組み込まれています。
- グループ承認者は30人以下のグループでのみ機能し、最初の回答が採用されます。
- 保留中のリクエストは、全員が回答するか取り下げられるまでチケットのクローズを妨げます。
- リクエストは作成後に編集できません。取り下げて作り直します。
これを前提に設計する前に、欠けている点を知っておく価値があります。順次チェーンはありません。チームリードの次にマネージャーが必要なら、1つ目のリクエストを作成して待ち、次を作成します。Zendesk にはリマインダー設定の記載もないので、遅い承認者への催促はリンクを共有する手作業になります。Zendesk のプロダクトマネージャーはコメント欄で、コンプライアンス上の理由からメール返信による承認は対象外だとも確認しています。
2026年の大きな変更は Slack です。2026年5月以降、個々の承認者には Slack の DM が届き、グループ承認ではグループ全員が入る一時的なプライベートチャンネルが開きます。
2026年10月には、Zendesk が Slack のコメントを監査可能な記録としてチケットに同期する機能を追加しました。それでも Slack からリクエストの作成や取り下げはできません。自動化フローでは、アクションフローのレシピが最大30日間一時停止し、Approved、Denied、Withdrawn、Expired で分岐できますが、高度な承認アクションにはアーリーアクセスプログラムが必要だと Zendesk は述べています。
Suite Team の場合の代替はサイドカンバセーションです。ただしこれは承認や却下のオブジェクトではなく、別のスレッドです。プランの条件はZendesk料金の解説に、誰がリクエストを作成できるかはロールと権限のガイドにまとめています。
Freshservice と Jira Service Management：IT水準のチェーン
どちらのツールも IT 側から生まれており、それが表れています。承認は第一級のオブジェクトで、カスタマーサービス向けのヘルプデスクにはない多段階のロジックを備えています。
Freshservice では、承認者がグループに入り、グループがチェーンに入ります。各グループにはルール（Everyone、Anyone、Majority、First Responder）があり、チェーンにもルールがあります。
カスタマーサービス系のツールにもまねしてほしい機能が2つあります。Freshservice は N 時間ごとに承認者へリマインドでき、承認者は開始日と終了日を指定して同僚に承認を委任できます。「マネージャーが休暇中」という問題の解決策です。料金は年払いでエージェントあたり月19ドルから99ドルで、複数承認ワークフローは全プランに含まれます。プランの詳細はFreshservice料金のガイドにあります。
Jira Service Management は、ワークフローのステータスに承認をステップとして追加します。承認者の人数、出どころ、担当者や報告者などどのフィールドから除外するかを選びます。承認者はヘルプセンター、メール、Slack、Teams から操作でき、JSM ライセンスは不要です。Jira Service Management料金の記事では、Free プランの1日100通というメール上限が承認通知に響きうる理由を解説しています。
サポートチームがすでに Freshworks や Atlassian のアカウントを IT と共有しているなら、返金承認をそこで運用する価値があるかもしれません。そうでなければ、マネージャーのYesだけが欲しいサポートチームにとって、これらのツールは設定の手間が大きすぎます。
Front、Help Scout、Freshdesk：下書きと権限
この3つにはチケット用の承認ボタンがありません。あるのは、他の人が見られる下書きと、特定の人の送信を止める手段です。
Front 自身が推奨する方針は、サポートワークフローの記事によれば「価格に関する質問は、必ず下書きをマネージャーと共有して承認を得る」ことです。共有下書きは共有受信トレイでは初期設定で有効ですが、@メンションしない限りチームメイトには通知されません。
これを厳格なルールにするには、新人などのグループから「Send messages」権限を外します。それには月額シートあたり105ドルの Enterprise が必要で、共有チャンネルにしか効きません。Front は承認依頼のために、マネージャーに割り当てる関連タスクも提案しています。これは全プランで使え、タスクが解決されると会話が上に戻ります。プランの詳細はFront料金の記事にあります。
Help Scout の文書化された方法はもっと単純です。新人は返信を下書きとして保存し、マネージャーが Send options メニューから代わりに送信します。メモは残せても返信できない Light Users には Plus か Pro が必要です。問題は、Help Scout が個別の会話を制限する方法はないと明言していることで、「この担当者は返金チケットだけ承認が必要」とは指定できません。詳しくはHelp Scout料金の解説をご覧ください。
Freshdesk は承認ワークフローを文書化していますが、それは Enterprise のナレッジベース記事向けで、チケット向けではありません。Freshdesk でのチケット承認は、ロールと権限と社内メモで組み立てる運用です。選択肢はFreshdeskの承認のガイドで順に説明しています。
Gorgias と HubSpot：ロール別の権限、承認は別の場所
Gorgias は承認ではなくロールで返金を制御します。Basic、Lead、Admin ユーザーはチケットから直接 Shopify の返金やキャンセルを実行でき、Observer と Lite ユーザーはできません。ユーザー権限の表には、担当者ごとの金額上限は見当たりませんでした。レビューステップに最も近いのは、マクロアクションが入力欄の下に表示され、担当者が送信前にプレビュー、編集、削除できる点です。Gorgias でマネージャーを関与させたいなら、それはロール設計とチームの規範の問題で、返金チケットにタグを付けてリードが確認するようにするGorgiasルールで支えられます。
HubSpot はこのグループで最も洗練された承認UIを持ち、レコード上に Approve、Reject、Request changes がありますが、対象は案件と見積です。チケットは HubSpot の承認対象オブジェクトの一覧にありません。Service Hub Professional のチケットパイプラインのルールは、特定のステージでチケットを編集できる人を制限できますが、スーパー管理者、ワークフロー、API は回避できます。サポート側で何を自動化できるかはHubSpot Service Hub向けAIのガイドにまとめています。
金額の上限は決済レイヤーにも置く
ヘルプデスクで上限を強制できないとき、決済システムなら可能な場合があります。私が見つけた中で最も明快な標準の返金承認は Stripe のもので、「Refund is created」に対する二者承認ルールに、任意の金額しきい値を組み合わせられます。ユーザーは自分のリクエストを承認できず、未承認のリクエストは14日で失効します。詳しくは Stripe の二者承認のドキュメントをご覧ください。
Shopify のオンライン管理画面では、返金権限はオンかオフかで、金額の上限はありません。Shopify POS は別で、返金、割引、ストアクレジットを「Approval required」に設定でき、マネージャーが PIN を入力して承認します。POS のカスタムロールは POS Pro の機能です。
AIの返信とアクションを承認する
ここまでの内容は、人間の担当者が依頼し、人間が承認することを前提にしています。キューにAIエージェントがいると、その上にもう一層加わります。AIが作業を準備し、それがお客様やシステムに届く前に人が承認します。ある Hacker News のコメンターは、ほとんどのベンダーが提供を始めるずっと前に、この構成をうまく言い表していました。
"Now if AI agents are free to issue refunds or discounts by their own? Great, let's do that and suddenly most people are on board. But get ready for rampant abuse. Best solution would be an AI cyborg system where it readies a recommendation and a human swings by and approves or denies it without wasting time talking to people."
これは、各ベンダーが今それぞれの形で提供しているものに近いです。
- Zendesk の auto assist（Copilot アドオンの一部）は、実行前に担当者が承認するアクションを提案します。管理者はアクションを事前承認済みにでき、返金のような書き込み操作は担当者承認のままにするのが Zendesk 自身の指針です。設定はauto assistのアクションのガイドにあります。
- Front の Autopilot ルールには、送信せずに下書きを作成する「Hold reply for review」フィールドがあり、Front は完全自動化の前にまずそこから始めるよう勧めています。
- Help Scout の AI Drafts は、送信前に担当者が確認・修正する前提で書かれており、Plus と Pro で使えます。
- Gorgias の AI Agent には「Customer confirmation」設定がありますが、誰が承認するかに注意してください。確認するのは購入者であり、マネージャーではありません。注文のキャンセルのような元に戻せないアクションでは自動的にオンになります。
- Stripe は、エージェントタグ付きの API キーで作成された返金に既定の承認ルールを適用します。決済レイヤーでさえ、AIが起こした返金を別のアクターとして扱っています。
AIが関わる返金依頼で私が目指すフローは次のとおりです。
人々が過小評価しているのは、レビュー担当者がAIの下書きで実際に何をするかです。ECサイトの Zendesk 受信トレイでの実トラフィックによる試験では、振り分けの精度は93%でしたが、担当者がAIの下書きをそのまま送ったのは12%だけでした。パターンは、ざっと見て書き直す、というもので、8〜15文の下書きが1〜3文に削られていました。書き直しの約65%は長さとトーンの調整で、チームが実際に送った返信で学習させれば直せる類のものでした。AIの事実誤りは約5%にとどまりました。
キューの側から得た教訓が2つあります。第一に、YesかNoのボタンだけでは足りません。ある Freshdesk のお客様は、そのまま承認するか却下するかしかないとコピー&ペーストを強いられるため、送信前にAIの下書きを編集する必要があると話していました。第二に、編集した版が実際に送信されるか確認してください。チームメイトが以前、編集した下書きが元の未編集版のまま送られていた Freshdesk のお客様を報告したことがあり、修正されるまでそのワークフローは使い物になりませんでした。信頼する前に、その経路をテストしてください。
AIコパイロットツールを比較しているなら、この2点はどんなデモよりも多くを物語ります。Freshdesk 自身の下書きへの取り組みはFreshdeskのAI下書き返信の記事で扱っています。
eesel で承認先行のAIを運用する方法
eesel のAIチームメイトは、新入社員を迎えるときと同じように設計されています。初日に自律のスイッチは渡されず、確認された作業を通じて自律を獲得します。実際には、Actions and Approvals のドキュメントにあるとおり、エージェントごとに選ぶアクション単位の設定ひとつに集約されます。
- Auto： 自動で実行されます。ただし、特定の状況では先に確認するよう指示で定めている場合を除きます。
- Needs approval： エージェントがアクションを準備し、何かが起きる前に人が承認または拒否します。
- Disabled： エージェントはそのアクションをまったく使えません。
アクションは Read と Write にグループ化されているので、Read を Auto、Write の大半を Needs approval にし、社内メモのようなリスクの低いアクションは Auto にするのが一般的な出発点です。
アクションが承認を必要とするとき、承認者は正確な返信テキストか返金額（またはタグ）を確認し、3つのボタンから選びます。Approve は今すぐ実行します。Always allow は実行したうえで、そのアクションを以後 Auto に移します（そのエージェントのみ）。Deny はスキップし、エージェントはそれなしで続行します。この「Always allow」ボタンが卒業のステップです。ストアのエージェントの返金を5回承認し、問題なさそうなら、任せてしまいます。
承認は、承認者がすでに作業している場所に届きます。冒頭で引用した Zendesk 管理者は、見張るタブをもう1つ増やしたくなかったので、これが重要です。承認は、eesel のダッシュボード、実行の起点となった Slack スレッド内のカード、メールやヘルプデスクのメモ内のリンク、そしてターミナルに表示されます。
新規のお客様を設定するときに私が頼りにしているルールをいくつか挙げます。
- 例外ポリシーは平易な言葉で書きます。 返信を Auto のままにして「返金に関するものには返信前に確認する」と書けば、エージェントはそのケースでだけ確認します。ドキュメントには、100ドルを超える返金はすべてエスカレーションする、50ドル未満の破損クレームでは写真の依頼を省く、といったまさにそのためのテンプレートがあります。あるサポート管理者はこの方法で、新人を指導するように修正して「解約の前にトラブルシューティングする」というルールをエージェントに教えました。
- 承認できるのは Editors だけです。 Owners と Editors が判断します。Viewers は承認を見られますが操作はできず、Slack ではクリックした人がメールアドレスで Editor と照合されます。
- タイムアウトで自動承認されることはありません。 保留中のアクションは保留のままで、エージェントは人がフォローアップするというメモを残します。すべての判断は Activity ページに、誰がいつ判断したかが表示されます。
- オートメーションを作成するまで何も実行されません。 Zendesk を接続しても、エージェントが誰かに返信することはありません。
ターミナルで作業するチームや、Claude Code、Codex、Cursor に承認を管理させたいチームには、eesel CLI がダッシュボードと同じエージェントを操作します。eesel approvals は待機中のものを一覧表示し、eesel approvals approve <id> --always は承認とアクションの卒業を一度に行い、eesel integrations zendesk actions はすべてのアクションを承認設定つきで出力します。CLI の書き込みも同じ権限に従うため、Viewer の書き込みは常に Editor のために保留されます。
これらがお客様に触れる前に、私はまずシミュレーションを依頼します。ヘルプデスクを接続すると、エージェントは過去の実チケットを再現し、自分の回答をチームが送った内容と比較します。ドキュメントの例では、抽出した20件のチケットのうち17件が一致し、テーマ別のスコアと優先順位つきの改善リストが出ます。これにより、どのアクションが Auto に移せる状態か、どれが承認の後ろに残すべきかが分かります。全体像はAIチームメイトとAIヘルプデスクエージェントの記事をご覧ください。
承認ワークフローでよくある失敗
- 何でも承認させる。 すべての返金にマネージャーが必要なら、マネージャーがキューになります。ほとんどのチケットが一番下の段で止まるまで、担当者の上限を引き上げてください。
- 薄い依頼。 「これを返金してよいですか？」では、承認者がチケットを再構築する羽目になります。5行のカードを使ってください。注文、依頼内容、ポリシーの行、推奨、期限です。
- リマインダーも代理承認者もない。 Zendesk と Jira のドキュメントには、承認のリマインダー設定は見つかりませんでした。お使いのツールにもないなら、承認に社内のSLAを設定し、代理を指名してください。
- 記録が残らない。 DM での承認は次の担当者には見えません。決定をチケット上に残し、例外ログと今後のポリシー変更に活かしてください。
- AIを早く卒業させすぎる。 アクションを自動に移すのは、よくできたデモの後ではなく、確認された作業の後にしてください。ほかに設定する価値のある制限はAIガードレールの項目で扱っており、返金アクションに特別な注意が必要な理由はプロンプトインジェクションにあります。
- エスカレーション先を忘れる。 承認とエスカレーションは親戚のようなものです。承認が拒否されたら、エージェントには明確な道筋が必要で、それを扱うのがAIエスカレーションとチーム横断のエスカレーションです。
ポリシーが変わったら、承認ルールも同じ日に更新してください。担当者、マクロ、AIへの指示を同期させる方法はポリシー変更管理のガイドに、AIの席を含め各席が触れる範囲を絞る方法はサポート担当者のアクセス制御にあります。
キューで承認先行のAIを eesel で試す
Zendesk、Freshdesk、Gorgias、またはeesel が接続できるほかのヘルプデスクをお使いなら、eesel のAIヘルプデスクチームメイトは、新人に返金を任せ始めるときと同じやり方で始められます。AIが返信や返金を下書きし、あなたが Slack、チケット、ダッシュボードから承認します。何度も正しい結果を出すアクションには「Always allow」を与え、お金がかかるものは、望む限りあなたの承認の後ろに置いておけます。レポート画面では、承認、却下、保留中のアクション数をツール別に確認できます。
承認に追加費用はかかりません。チケットまたはチャットは、返信やアクションが何回あっても1クレジットで、席数は無制限です。無料プランには100クレジットがあり、カードは不要です。有料プランは月額299ドルで500クレジットからです。すべての返信を Needs approval にして、ご自身のキューで eesel を試して、そのまま送ったであろう数を確かめてください。