B2B eCommerce & Operationsシリーズの一部
完全ガイドを読むOdoo ヘルプデスク: プロフェッショナルな発券システムを構築する
カスタマーサポートは顧客維持の最前線です。ハーバード ビジネス レビューの調査によると、問題がすぐに解決された顧客は、まったく問題がなかった顧客に比べてロイヤルティを維持する可能性が 2.4 倍高いことがわかりました。ただし、これは解決が顧客の期待の範囲内であった場合に限られます。 Odoo 19 Enterprise Helpdesk は、SLA 施行、インテリジェントなチケット ルーティング、セルフサービス カスタマー ポータル、定型応答、チーム間エスカレーション ワークフローなど、迅速で一貫したサポートを提供するために必要なすべてを提供します。 Odoo Helpdesk を使用している企業は、最初の応答時間が平均 45% 短縮され、顧客満足度スコアが 30% 向上したと報告しています。
このガイドでは、初期セットアップから 3 人のサポート チームから 100 人のエージェントの運用まで拡張する高度な自動化まで、Odoo 19 のプロフェッショナルなチケット発行システムの完全な構成について説明します。
重要なポイント
- 応答と解決の期限を強制するエスカレーション ルールを使用して SLA ポリシーを構成する
- ラウンドロビン、負荷分散、またはスキルベースのルーティングを使用して自動チケット割り当てを設定する
- ユーザーがチケットを送信、追跡、評価できるカスタマー ポータルを構築する
- 受信メールを整理されたチケットに変換するメール エイリアスを作成する
- 一般的な問題に対して定型応答を導入して、処理時間を 40 ~ 60% 削減します
- Tier 1、Tier 2、エンジニアリング間のエスカレーション パスを備えたマルチチーム サポートを設計する
- SLA コンプライアンス、エージェントのパフォーマンス、顧客満足度を追跡するレポート ダッシュボードを構築する
- ヘルプデスクをナレッジベース、CRM、およびセールスと統合して、完全な顧客コンテキストを実現
ヘルプデスク チームのアーキテクチャ
効果的なサポートの基盤は、適切に設計されたチーム構造です。 Odoo ヘルプデスクは、それぞれが独自の構成、SLA ポリシー、割り当てルールを持つ複数のチームをサポートします。
サポートチームの作成
[ヘルプデスク] > [構成] > [ヘルプデスク チーム] に移動し、サポート モデルに基づいてチームを作成します。
| チーム | 目的 | SLA 目標 | 割り当て方法 |
|---|---|---|---|
| レベル 1 - 一般 | すべてのお問い合わせの最初の連絡先 | 応答: 1 時間、解決: 8 時間 | ラウンドロビン |
| Tier 2 - 技術 | 複雑な技術的問題 | 応答: 2 時間、解決: 24 時間 | スキルベース |
| Tier 3 - エンジニアリング | バグ修正と開発 | 応答: 4 時間、解決: 5 日 | マニュアル |
| 請求サポート | 請求書と支払いの問題 | 応答: 2 時間、解決: 4 時間 | ラウンドロビン |
| エンタープライズサポート | プレミアム顧客のみ | 応答: 30 分、解決: 4 時間 | 専任エージェント |
チーム構成オプション
各チームには包括的な構成パネルがあります。
電子メール エイリアス: 一意の電子メール アドレスを割り当てます (例: [email protected]、[email protected])。このアドレスに送信されるすべての電子メールは、送信者が顧客、件名がチケットのタイトル、電子メールの本文が説明であるチケットを、対応するチームに自動的に作成します。
ウェブサイト フォーム: 「ウェブサイト フォーム」を有効にして、チケット送信フォームをカスタマー ポータルに追加します。フォームに表示するフィールドを構成します。チケットの種類、優先度、製品のドロップダウン選択を含めて、自動ルーティングを有効にします。
ライブ チャット: Odoo ライブ チャットをヘルプデスク チームに接続します。ライブチャットの会話が終了すると、オペレーターはワンクリックで会話をチケットに変換できます。チャットの記録全体がチケットの説明となり、コンテキストが維持されます。
終了ステージ: SLA 計算のためにチケットを「終了」としてマークするステージを定義します。通常、「解決済み」と「キャンセル済み」は最終段階です。
SLA ポリシーの構成
SLA ポリシーはサービスのコミットメントを定義し、サポート チーム内に説明責任をもたらします。
SLA ポリシーの定義
[ヘルプデスク] > [構成] > [SLA ポリシー] に移動し、各チームのポリシーを作成します。
| ポリシー | チーム | 状態 | ターゲット | 優先順位 |
|---|---|---|---|---|
| 重大な対応 | すべて | 優先度 = 緊急 | 30 分以内に最初の応答 | 最高 |
| 標準応答 | ティア 1 | すべてのチケット | 最初の応答は 1 時間以内 | 高 |
| 技術的な解決策 | 階層 2 | タイプ = テクニカル | 24 時間以内に解決 | 中 |
| 請求の解決 | 請求 | タイプ = 請求 | 4 時間以内に解決 | 高 |
| エンタープライズ SLA | エンタープライズ | 顧客タグ = エンタープライズ | 応答: 15 分、解決策: 2 時間 | 最高 |
SLA の段階と測定
各 SLA ポリシーは、チケット ステージを通じて進行状況を追跡します。 「到達」ステージを構成する - チケットが目標時間内に定義されたステージに到達すると、SLA が満たされます。たとえば:
- 初回対応 SLA: チケットの作成から最初の公開返信 (顧客へのメッセージ) まで測定されます。
- 解決 SLA: チケットの作成から「解決済み」段階に到達するまで測定されます。
- エスカレーション SLA: チケットの作成から、しきい値内で解決されなかった場合のエスカレーション アクションまでの期間で測定されます。
SLA エスカレーションの自動化
SLA 期限が近づいた場合の自動エスカレーションを構成します。
- SLA 残り時間の 50% 時点: 割り当てられたエージェントに内部通知を送信します (「チケットが SLA 期限に近づいています」)
- SLA 残り時間の 80% 時点: チーム リーダーに通知し、カンバン ビューでチケットを強調表示します。
- SLA 違反時: 自動的にチーム リーダーに再割り当てされ、サポート マネージャーにアラートが送信され、優先度が「緊急」に変更されます。
- SLA 時間の 2 倍: 部門長に通知し、毎日のエスカレーション レポートに追加します
これらは、SLA 期限フィールドに関連する時間ベースのトリガーを備えた Odoo 自動アクションを使用して実装します。
自動チケット割り当て
チケットを手動で割り当てると、ボトルネックが発生し、作業負荷が不均一になります。 Odoo は複数の自動割り当て戦略をサポートしています。
ラウンドロビン割り当て
最も単純な方法は、チーム メンバー全員にチケットを均等に配布します。チームの設定で割り当て方法として「バランス」を選択して有効にします。 Odoo は、各エージェントの現在のオープン チケット数を追跡し、最も少ないオープン アイテムを持つエージェントに新しいチケットを割り当てます。
スキルベースのルーティング
テクニカル サポート チームの場合、スキルベースのルーティングにより、チケットが適切な専門家に確実に届きます。 [ヘルプデスク] > [構成] > [スキル] でスキルを構成し、チーム メンバーに割り当てます。
| スキル | エージェント | ルーティング条件 |
|---|---|---|
| オドゥテクニカル | アリス、ボブ | チケット タイプ = "テクニカル - ERP" |
| 請求と財務 | キャロル、デイブ | チケットタイプ = "請求" |
| API/統合 | ボブ、イブ | タグには「API」または「統合」が含まれています。 |
| モバイルアプリ | アリス、フランク | タグには「モバイル」が含まれています。 |
条件が一致するチケットが到着すると、Odoo は現在のワークロードのバランスを考慮して、対応するスキルを持つエージェントにチケットをルーティングします。
顧客固有の割り当て
プレミアム顧客の場合は、専用エージェントの割り当てを構成します。顧客の連絡先レコードに、「専用サポートエージェント」フィールドを設定します。通常のルーティング キューをバイパスして、この顧客からのチケットを専用エージェントに直接割り当てる自動アクションを作成します。
営業時間と空室状況
チーム設定でチームごとの営業時間を構成します。 SLA タイマーは営業時間内のみカウントされます。金曜日の午後 5 時に 4 時間の SLA で作成されたチケットは、月曜日の午後 1 時まで違反しません (月曜から金曜の 9 時から 5 時の営業時間と仮定)。チームが複数のタイムゾーンにまたがる場合は、太陽の後を確実にカバーできるように、個々のエージェントのスケジュールを構成します。
カスタマーポータルとセルフサービス
カスタマー ポータルは、顧客が独自に答えを見つけて問題を追跡できるようにすることで、チケットの量を減らします。
ポータル構成
[ヘルプデスク] > [構成] > [設定] でカスタマー ポータルを有効にします。お客様は次のことを行うことができます。
- 添付ファイル、優先順位の選択、製品/カテゴリのドロップダウンを使用して Web フォーム経由でチケットを送信
- ステータスの更新、割り当てられたエージェント名、SLA の進行状況をリアルタイムで追跡チケット
- 電子メールを送信せずに、添付ファイルを含むメッセージをチケットに追加することで コミュニケーション
- 過去のすべてのチケットの履歴を表示。ステータス、日付、カテゴリで検索およびフィルタリング可能
- チケット終了後の満足度アンケートで解決策を評価 (1 ~ 5 つ星とコメント)
ナレッジベースの統合
ヘルプデスクをナレッジ アプリに接続して、セルフサービス記事を提供します。顧客がチケットの件名を入力し始めると、Odoo はチケットを送信せずに問題を解決できる可能性のある関連ナレッジベース記事を提案します。この偏向メカニズムにより、一般的な問題のチケット量を 15 ~ 30% 削減できます。
チケットのカテゴリに基づいてナレッジ記事の提案を構成します。顧客がチケット タイプとして「パスワード リセット」を選択した場合は、フォームに記入する前にすぐにパスワード リセット ガイドを表示します。
ポータルのカスタマイズ
[Web サイト] > [構成] > [カスタマイズ] で、ブランドに合わせてポータルの外観をカスタマイズします。ロゴ、ブランドカラー、カスタム CSS を追加します。チケット送信フォーム、ナレッジ ベースの検索、FAQ セクション、連絡先情報、営業時間を含むサポート センターのランディング ページを作成します。
返信定型文と返信テンプレート
定型返信は、エージェントがワンクリックで選択する事前に作成された返信であり、一貫性を維持しながら応答時間を大幅に短縮します。
返信定型文ライブラリの構築
[ヘルプデスク] > [設定] > [定型応答] に移動し、最も一般的なチケット タイプの応答を作成します。
| 返信定型文 | 使用例 | 時間の節約 |
|---|---|---|
| ご挨拶 + 情報リクエスト | 詳細を尋ねる最初の応答 | 2~3分 |
| パスワードのリセット手順 | セルフサービスのパスワード リセット手順 | 5~7分 |
| 返金ポリシー | 標準的な払い戻し条件とプロセス | 3~5分 |
| エスカレーション通知 | Tier 2 へのエスカレーションをお客様に通知 | 2~3分 |
| 解決策の確認 | 解決した問題の確認 + 満足度調査 | 3~4分 |
| 機能リクエストの承認 | 製品チーム向けの機能リクエストの記録 | 2~3分 |
| バグレポートテンプレート | 再現手順の収集 | 4~6分 |
| 請求書の訂正 | 請求書調整の説明 | 3~5分 |
動的プレースホルダー
返信定型文は、各メッセージをパーソナライズする動的なプレースホルダーをサポートしています。
${ticket.partner_id.name}— 顧客名${ticket.name}— チケット参照番号${ticket.user_id.name}— 割り当てられたエージェント名${ticket.team_id.name}— サポート チーム名${ticket.sla_deadline}— SLA 目標日
定型応答には、「$\\{ticket.partner_id.name\\} 様、$\\{ticket.team_id.name\\} にお問い合わせいただきありがとうございます。あなたのチケット $\\{ticket.name\\} は $\\{ticket.user_id.name\\} に割り当てられており、$\\{ticket.user_id.name\\} が SLA コミットメント内で調査して対応します。カスタマー ポータルでいつでも進捗状況を追跡できます。」
キーボード ショートカット
ショートカット トリガー (: の後に応答ショートコードを入力) を使用して定型応答を挿入するようにエージェントをトレーニングします。これは、経験豊富なエージェントの応答リストを参照するよりも高速です。ショートコードを論理的に編成します。挨拶には :greet、パスワードのリセットには :reset、返金ポリシーには :refund を使用します。
マルチチームエスカレーションワークフロー
複雑なサポート業務には、チーム間でのスムーズなエスカレーションが必要です。
エスカレーション パスの設計
Customer → Tier 1 (General)
↓ Cannot resolve in 4 hours
Tier 2 (Technical)
↓ Requires code change
Tier 3 (Engineering)
↓ Impacts billing
Billing Support
エスカレーションの構成
各チームのパイプラインに「エスカレーション」ステージを作成します。エージェントがチケットをこのステージに移動すると、自動アクションは次のようになります。
- チケットを宛先チームにコピーします (すべての履歴と添付ファイルを保持します)。
- エスカレーションの理由と試行内容を記載した内部メモを追加します。
- 宛先チームリーダーに通知
- エスカレーションを説明するメッセージを顧客に伝えます。
- 現在のチームの SLA タイマーを一時停止し、宛先チームのタイマーを開始します。
チーム間の可視性
Tier 1 エージェントが Tier 2 にエスカレーションしたチケットのステータスを確認できるように、共有ビューを構成します。これにより、顧客がステータス更新のために Tier 1 に問い合わせた場合に、問題を再度説明する必要がなくなります。 Odoo の「フォロー」メカニズムを使用します。エージェントがエスカレーションすると、宛先チームのチケットを自動的にフォローします。
レポート作成とパフォーマンス分析
エージェント パフォーマンス ダッシュボード
[ヘルプデスク] > [レポート] でエージェントのパフォーマンス追跡を構築します。
| メトリック | ターゲット | 測定方法 |
|---|---|---|
| 平均初回応答時間 | <1 時間 | 作成から最初の公開メッセージまでの時間 |
| 平均解決時間 | 8 時間未満 | 作成から「解決」段階までの時間 |
| SLA遵守率 | >95% | SLA 内で解決されたチケット / チケット合計 |
| 顧客満足度 (CSAT) | >4.2/5 | 決議後のアンケートへの回答 |
| 1 日あたりのチケット | 15-25 | エージェントごとに 1 日にクローズされたチケットの合計 |
| 再開率 | <5% | チケットが解決済みからオープン ステージに戻りました |
トレンド分析
一定の期間にわたってメトリクスを追跡して、パターンを特定します。
- 曜日別のボリューム: スタッフに応じて (多くの企業では月曜日の急増が見られます)
- チケット タイプ別のボリューム: サポート負荷が最も高い製品分野を特定します
- カテゴリ別の解決時間: より適切な文書化により処理時間を短縮できる領域を見つけます
- エージェントによる CSAT: コーチングの機会を特定し、成績優秀者を表彰します
- エスカレーション率: Tier 1 チケットの 20% を超えるエスカレーションがある場合、トレーニングまたはナレッジ ベースのギャップが存在します。
自動化された週次レポート
毎週のサポート メトリックをコンパイルし、毎週月曜日の朝にサポート マネージャーに送信するスケジュールされたアクションを構成します。含まれるもの: 作成、クローズ、オープンされたチケットの合計。 SLA準拠率。平均 CSAT スコア。トップ 5 のチケット カテゴリ。最高のパフォーマンスと最低のパフォーマンスを持つエージェント。そしてエスカレーション率。
他の Odoo モジュールとの統合
ヘルプデスク + CRM
ヘルプデスク チケットを CRM 機会にリンクします。見込み客 (有効な機会を持つ人) からサポート チケットが届くと、Odoo は営業担当者に警告します。これにより、未解決の技術的問題が原因で取引が停滞するのを防ぎます。営業担当者は、商談チャットからサポートのやり取りを確認できます。
ヘルプデスク + セールス
チケットビューから顧客の購入履歴を表示します。このコンテキストは、エージェントが適切なサポートを提供するのに役立ちます。返金リクエストを処理するエージェントは、アプリケーションを切り替えることなく、元の注文、支払い方法、配送状況を即座に確認できます。
ヘルプデスク + ナレッジ
ナレッジ統合は双方向で機能します。エージェントはチケットに応答しながらナレッジ ベースを検索でき、チケット解決から直接新しいナレッジ記事を作成できます。エージェントが新しい問題を解決するときは、[記事の作成] をクリックして、解決策を今後の参照のためにナレッジ ベースのエントリに変換します。
ヘルプデスク + タイムシート
ヘルプデスク チケットのタイムシート追跡を有効にして、実際のサポート コストを測定します。エージェントはチケットに時間を直接記録し、プロジェクトのタイムシートと請求書に反映されます。これは、サポート時間を請求したり、顧客ごとのサポートコストを追跡する必要があるサービス会社にとって特に有益です。
よくある質問
ヘルプデスク チームはいくつ作成する必要がありますか?
実際のサポート構造を反映するために必要な最小限から始めます。ほとんどの組織では 2 ~ 3 のチーム (一般/Tier 1、技術/Tier 2、およびオプションで請求) が必要です。チームを作成しすぎるとサポート データが断片化され、レポート作成が困難になります。明確な SLA 要件または分離が必要な特殊なスキルがある場合にのみ、チームを追加します。
顧客はチケットの内部メモを確認できますか?
いいえ。Odoo ヘルプデスクでは、「メッセージの送信」(顧客に表示) と「ログノート」(内部のみ) を区別しています。内部メモはサポート エージェントとマネージャーのみに表示されます。エスカレーションのコンテキスト、トラブルシューティングの手順、エージェント間のコミュニケーションについては、内部メモを使用します。
営業時間外に到着したチケットはどのように処理すればよいですか?
営業時間外に作成されたチケットは通常キューに入れられますが、SLA タイマーは翌営業日まで開始されません。受信を確認し、期待値を設定する自動返信メール テンプレートを構成します。「チケットを受信しました。当社のサポート チームは月曜から金曜の午前 9 時から午後 5 時 (EST) まで営業しています。翌営業日の 1 営業時間以内に返信します。」
顧客セグメントごとに SLA パフォーマンスを追跡できますか?
はい。連絡先レコードで顧客に「Enterprise」、「Standard」、または「Free」のタグを付けます。セグメントごとに個別の SLA ポリシーを作成します。次に、SLA コンプライアンス レポートを顧客タグでフィルタリングして、階層ごとのコミットメントをどの程度満たしているかを確認します。これは、エンタープライズ サポート層のプレミアム価格を正当化するために不可欠です。
Odoo Helpdesk は Zendesk や Freshdesk とどう違うのですか?
Odoo Helpdesk は、コア機能 (チケット発行、SLA、ポータル、レポート) において同等であり、統合の深さにおいて優れています。チケットは、サードパーティのコネクタを使用せずに CRM、販売、請求、およびナレッジにネイティブに接続します。 Zendesk と Freshdesk には、より充実したスタンドアロン サポート機能 (コミュニティ フォーラム、高度なチャットボット ビルダー) がありますが、ビジネス データと接続するには高価な統合が必要です。すでに他の機能に Odoo を使用している組織にとって、ヘルプデスクはコスト効率が大幅に高く、データが豊富です。
同じ顧客の重複したチケットを結合できますか?
はい。リストビューで複数のチケットを選択し、「結合」アクションを使用します。 Odoo は、すべてのメッセージ、添付ファイル、内部メモを 1 つのチケットに結合します。古いチケット番号が保存され、マージがメモに記録されます。これは、顧客が同じ問題についてポータル チケットを電子メールで送信して送信する場合によく発生します。
チケットをクローズした後に満足度アンケートを設定するにはどうすればよいですか?
ヘルプデスク チームの設定で「顧客満足度」を有効にします。チケットが「解決済み」ステージに達すると、Odoo は評価スケール (1 ~ 5 つ星またはスマイリーフェイス) を含むアンケート電子メールを自動的に送信します。結果はチケットに記録され、満足度レポートに集計されます。アンケートの遅延を設定します。多くのチームは、顧客に修正を確認する時間を与えるために、閉店後 1 時間待ちます。
ECOSIRE でワールドクラスのサポートを構築
ヘルプデスクは単なるコストセンターではなく、顧客のニーズを理解し、顧客離れを減らし、製品改善の機会を特定するための最も直接的なチャネルです。 Odoo Helpdesk を流れるサポート データは、適切に構成および分析されると、戦略的資産になります。
ECOSIRE の Odoo サポートおよびメンテナンス チーム は、SaaS 企業、メーカー、プロフェッショナル サービス会社、電子商取引企業向けにヘルプデスク システムを導入しています。当社の実装には、チーム アーキテクチャの設計、SLA ポリシーの構成、定型応答の開発、ポータルのカスタマイズ、ナレッジ ベースのセットアップ、エージェントのトレーニングが含まれます。
ヘルプデスク システムの評価については ECOSIRE にお問い合わせ、または Odoo 実装サービス を参照して、ヘルプデスクを顧客業務全体に統合する方法を確認してください。
関連書籍:
執筆者
ECOSIRE TeamTechnical Writing
The ECOSIRE technical writing team covers Odoo ERP, Shopify eCommerce, AI agents, Power BI analytics, GoHighLevel automation, and enterprise software best practices. Our guides help businesses make informed technology decisions.
関連記事
Odoo フォーム ビューにカスタム ボタンを追加する方法 (2026)
Odoo 19 フォーム ビューにカスタム アクション ボタンを追加します: Python アクション メソッド、ビューの継承、条件付き可視性、確認ダイアログ。製造テスト済み。
Studio を使用せずに Odoo にカスタムフィールドを追加する方法 (2026)
Odoo 19 のカスタム モジュールを介してカスタム フィールドを追加します: モデル継承、ビュー拡張、計算フィールド、ストア/非ストアの決定。コードファースト、バージョン管理。
外部レイアウトを使用して Odoo にカスタム レポートを追加する方法
web.external_layout: QWeb テンプレート、paperformat、アクション バインディングを使用して、Odoo 19 でブランド化された PDF レポートを構築します。印刷ロゴ + フッターのオーバーライド付き。
B2B eCommerce & Operationsのその他の記事
B2B E コマース戦略: 2026 年に卸売オンライン ビジネスを構築する
卸売価格設定、アカウント管理、クレジット条件、パンチアウト カタログ、Odoo B2B ポータル構成の戦略を使用して B2B e コマースをマスターします。
ケーススタディ: ECOSIRE の ERP ソリューションで卸売業者が 3 倍の成長を達成
B2B ディストリビューターが、バーコード スキャン、B2B ポータル、Power BI を備えたレガシー システムから Odoo ERP に最新化して、年間 20 万ドルを節約した方法。
Faire Wholesale と Odoo ERP の統合: 段階的なセットアップ
Faire 卸売市場と Odoo ERP を統合するための完全なガイド。 B2B の注文、在庫の同期、小売業者の管理を自動化します。
ECOSIRE サポート プラン: どのレベルのサポートが必要ですか?
ECOSIRE のサポート プランの完全ガイド。各層の対象範囲、応答時間の仕組み、運用に適したサポート レベルの選択方法を理解します。
卸売・流通向けERP:受注・在庫・物流
ERP システムが注文管理、複数の倉庫在庫、ルート計画、顧客価格管理を通じて卸売および流通業務を最適化する方法。
ホールセール ERP 導入: EDI、B2B ポータル、ルート プランニング
EDI 統合、B2B 顧客ポータルの設定、倉庫管理、ルート計画をカバーする、卸売流通における ERP の導入に関する包括的なガイドです。