顧客からの問い合わせが、いくつの経路で入ってきているでしょうか。
代表メールアドレス。営業担当者の個人メール。電話。Webの問い合わせフォーム。そして最近では、担当者個人のチャット。
経路が増えるほど、抜けが起きます。
そして抜けたことに気づくのは、たいてい相手から催促が来たときです。「先週お送りした件、いかがでしょうか」という連絡で、初めて対応漏れが分かる。
問い合わせ対応の問題は、件数ではありません。 誰が対応しているか、いつまでに返すかが決まっていないことです。
この記事では、Odoo（オドゥー：オープンソース由来の統合業務アプリ群）のヘルプデスクを、機能の各論として整理します。
⚠️ このアプリはEnterprise版限定です
Odooのヘルプデスクアプリは、有償の Enterprise版 が対象と案内されています。無料の Community版では利用できません。代替の考え方は第7章で扱います。
抜けが起きる構造
まず、なぜ抜けるのかを見てください。
専門用語の整理：ここでいう「チケット」とは、1件の問い合わせを表す記録のことです。受付から解決までを1枚のカードで追いかけるもの、と考えてください。
ヘルプデスクでできること
Odoo公式ドキュメントによれば、次のような構成になっているとされています（2026年8月確認）。
チームとパイプライン
- 複数のチームを作り、1つの画面で管理できる
- チームごとに、独立したチケットのパイプラインを持つ
- パイプラインの段階（ステージ）は自由に設定できる
- チームの説明文は、顧客が使う問い合わせフォームに表示される
チームの説明文には、社内向けの情報を書かないでください。 公開されるためです。公式ドキュメントにも同じ注意が記載されています。
SLA（対応期限のルール）
Odoo公式ドキュメントによれば、次のような設定ができるとされています。
- チームごとにSLAのポリシーを設定する
- 優先度やタグを条件にして、適用するチケットを絞る
- 到達すべき段階と、そこまでの時間を設定する
- 一部の段階を、時間の計算から除外できる（回答待ちの期間など）
- 期限は、会社の就業時間にもとづいて計算される
期限を過ぎたチケットは、目印が赤くなるとされています。また、SLAの達成状況を分析するレポートがあると案内されています。
顧客からの評価
- チケットの解決後に、顧客に評価を依頼できる
- 評価の依頼メールを、特定の段階に紐づけて設定できる
対応後の処理
公式ドキュメントは、チケットからつながる処理として次を挙げています。
- 返金や返品の手続き
- 修理への引き渡し
- 現地対応の作業を作成する
- 一定期間動きのないチケットを自動的に閉じる
- 顧客自身にチケットを閉じてもらう
SLAは「一次応答」と「解決」を分けて設計する
ここが設計の要点です。
なぜ2つに分けるのか
解決までの期限だけを設定すると、その間ずっと連絡がない状態が生まれます。
顧客の立場では、対応が始まっているのかどうかも分かりません。不満は、遅いことより「分からないこと」から生まれます。
一次応答の期限を別に設けておくと、受け付けたことが早く伝わります。そのうえで解決に時間がかかっても、多くの場合は許容されます。
SLAを厳しくしすぎないでください
期限を短くすれば対応が速くなる、わけではありません。
守れない期限を設定すると、赤い表示が常態化します。 そして誰も見なくなります。
まずは現状の実績を測ってから、少しだけ厳しい値を設定してください。 理想の数字から始めないことが大事です。
除外する段階を活用してください
顧客の返事を待っている間まで期限に含めると、自社の努力では守れない期限になります。
公式ドキュメントによれば、特定の段階を計算から除外できます。「顧客回答待ち」の段階を作り、除外に設定してください。
件数を減らすのは、仕組みではありません
正直に書きます。
ヘルプデスクを入れても、問い合わせの件数は減りません。
減るのは、抜けと、探す時間と、催促への対応です。件数そのものを減らすには、原因に手を入れる必要があります。
件数を減らす方法
| 手段 | 内容 |
|---|---|
| 同じ質問を公開する | よくある問い合わせを、自社サイトで読める形にする |
| 製品や手順を直す | 同じ問い合わせが続くなら、そこに設計の問題がある |
| 案内の文面を直す | 納品時の説明が足りないと、後から問い合わせになる |
2つ目がいちばん効きます。
チケットが記録に残っていると、「何についての問い合わせが多いか」が分かります。 その情報を、製品や手順の改善に渡してください。
記録を集めることが目的ではありません。 集めた記録を、原因の側へ返すことが目的です。
対応履歴が顧客の記録につながる意味
Odooのヘルプデスクは、顧客データと同じ場所にあります。これが実務で効きます。
- 営業が訪問する前に、その顧客の問い合わせ履歴を確認できる
- クレームの直後に、新しい提案を持っていく事故を避けられる
- 契約更新の判断材料に、対応の実績を使える
別のツールで管理していると、この接続が切れます。
営業が知らないまま「ご機嫌いかがですか」と連絡してしまう。これは実際に起きる事故です。
CRMとの関係は OdooのCRM（顧客管理）でできること にまとめています。
時間の記録と請求
Odoo公式ドキュメントによれば、チケットにかかった時間を記録し、請求につなげる機能があると案内されています。
有償の保守契約を結んでいる場合、次のような運用ができます。
- あらかじめ購入してもらった時間から、対応した分を差し引く
- 契約外の対応を、別途請求する
サポートを無償で提供し続けている会社にとっては、判断材料になります。
「どの顧客にどれだけ時間を使っているか」が分かると、契約条件の見直しにつながります。工数の考え方は Odooの工数管理（Timesheets） をご覧ください。
Community版とEnterprise版の違い
Odooには、無料の Community版 と有償の Enterprise版 があります。
Community版はオープンソースとして無料で使えます。ただし、サーバの用意・アップデート・障害対応は自社の責任になり、公式サポートの対象外です。
ヘルプデスクアプリは、Enterprise版が対象です。Community版では利用できないと案内されています。
Community版での代替
プロジェクト管理アプリを、問い合わせ管理として使う方法があります。
| 機能 | ヘルプデスク | プロジェクトでの代替 |
|---|---|---|
| チケットの段階管理 | ✅ | ✅ タスクの段階として設定可 |
| チーム別のパイプライン | ✅ | ✅ プロジェクトを分ける |
| SLAの自動判定 | ✅ | ❌ 期限は手動で管理 |
| 顧客からの評価依頼 | ✅ | ❌ |
| 対応時間の請求連携 | ✅ | 一部可 |
代替できるのは「見える化」まで、と考えてください。 SLAの自動判定が要るかどうかが、判断の分かれ目です。
プロジェクト管理の各論は Odooのプロジェクト管理（Project） をご覧ください。
どの機能がどちらの版で使えるかはバージョンによって変わります。 検討時には必ず対象バージョンで確認してください。詳しくは Odoo Community版とEnterprise版の違い をご覧ください。
他のアプリとのつながり
| アプリ | つながり方 |
|---|---|
| CRM | 顧客の記録に問い合わせ履歴が残る |
| プロジェクト管理 | 開発や改修が必要な案件へ引き渡す |
| 工数管理 | 対応にかかった時間を記録し、請求につなげる |
| アンケート | 解決後の満足度を集める |
| シフト・リソース計画 | 現地対応が必要な場合の作業手配 |
詳細はそれぞれの記事にまとめています。
- OdooのCRM（顧客管理）でできること
- Odooのプロジェクト管理（Project）
- Odooの工数管理（Timesheets）
- Odooのアンケート機能（Surveys）
- Odooのフィールドサービス（FSM）の現在地
よくある質問
Q1. メールで来た問い合わせを自動でチケットにできますか？
問い合わせ用のメールアドレスを設定して、受信をチケットにする運用ができます。
ただし、返信のやり取りが同じチケットにまとまるかは、設定と運用で変わります。 実機で確認してください。
Q2. 何人くらいの規模から必要ですか？
人数より、対応する人が2人以上いるかどうかです。
1人ですべて受けているなら、その人の受信箱がいちばん速い管理台帳です。複数人で分担した瞬間に、抜けが始まります。
Q3. SLAを設定すると、担当者が追い詰められませんか？
設定の仕方によっては、そうなります。
守れない期限を置かないこと、顧客回答待ちを計算から除外すること。この2つを守ってください。
SLAは担当者を評価する道具ではなく、優先順位を決める道具です。 ここを社内で説明してから始めてください。
Q4. 顧客自身に状況を確認してもらえますか？
顧客向けの画面から、自分のチケットを確認できる運用ができます。
ただし、社内向けのやり取りが見えない設定になっているかを、必ず確認してください。 公開範囲の確認は、開始前に行う作業です。
Q5. 過去の問い合わせ履歴を取り込めますか？
取り込みは可能ですが、優先度は高くありません。
問い合わせ対応で価値があるのは、直近の履歴です。これから作る記録から始めることをおすすめします。
まとめ
Odooのヘルプデスクが解くのは、問い合わせの件数ではありません。
誰が対応していて、いつまでに返すのかが決まっていない状態です。
経路が増えるほど抜けは起きます。そして抜けに気づくのは、たいてい相手から催促が来たときです。すべてをチケットとして1つの流れに集めると、件数と滞留が見えるようになります。
設計でいちばん大事なのは、SLAを2つに分けることです。
一次応答の期限と、解決の期限。顧客の不満は、遅いことより「分からないこと」から生まれます。 受け付けた事実を早く伝えれば、解決に時間がかかっても許容されることが多いはずです。
そして、期限を厳しくしすぎないでください。 守れない期限を置くと、赤い表示が常態化して誰も見なくなります。現状の実績を測ってから、少しだけ厳しい値にしてください。顧客回答待ちは、計算から除外してください。
正直にお伝えします。この機能を入れても、問い合わせの件数は減りません。
減るのは、抜けと、探す時間と、催促への対応です。件数を減らすには、記録から「何についての問い合わせが多いか」を読み取り、製品や手順の側に返す必要があります。
なお、Community版では利用できません。プロジェクト管理アプリで代替できるのは「見える化」までです。SLAの自動判定が必要かどうかが、判断の分かれ目になります。
もう少し詳しく知りたい方へ
ベンチャーネットは、ERP導入支援を手がける会社です。SAP・NetSuite・Odoo・AIスクラッチ開発という4つの選択肢を扱っているため、特定の製品に偏らない立場でご提案できます。
「まず現状の対応時間を測る」ところからご相談を承っています。
あわせて読みたい記事
