VTIGER CRM OSS ／ STANDARD FUNCTION GUIDE
問い合わせを、受けた人だけの
仕事にしない。
「あの問い合わせ、誰が対応している？」「お客様への回答は済んだ？」「前にも同じ質問があったはず」。電話やメールが担当者ごとに分かれていると、対応の途中経過が見えにくくなります。
Vtiger CRM OSSの問い合わせ（HelpDesk／Tickets）は、問い合わせ内容、顧客、社内担当者、状態、解決策をまとめる標準モジュールです。一件ずつ対応を記録し、引き継ぎや次回の回答に役立てられます。
この記事では、受付から担当者への割り当て、対応状況の共有、解決・FAQへの活用までを、図解と具体例で整理します。
この記事でわかること
問い合わせに残す情報／担当者と状態の管理／やり取りと解決策の記録／対応漏れを減らす確認方法／FAQへの活用
対象：Vtiger CRM OSS 8.4系の標準機能。画面名・項目名・選択肢は、日本語化や設定によって異なります。図は仕組みを説明する模式図で、実際の操作画面ではありません。クラウド版専用機能は含めていません。
1. 問い合わせは「一件の対応」をまとめる場所
顧客企業は会社の情報、顧客担当者はお客様側の窓口、問い合わせは個別の質問や不具合への対応を整理する場所です。同じ会社から複数の相談を受けても、対応ごとに分けて記録すると、何が進行中かを確認しやすくなります。
誰から、何についての問い合わせかを関連付ける
顧客企業
どの会社か取引先の会社情報と、過去の対応をたどる起点。
顧客担当者
お客様側の窓口問い合わせた方や、回答・確認の連絡先。
商品
何についてか対象の商品を確認し、調査や回答につなげる。
たとえば、青葉製作所の山田さんから「端末で帳票を印刷できない」という相談を受けたら、一件の問い合わせとして登録します。別の日に「利用者を追加したい」という質問が来た場合は、別件として管理する方が、それぞれの担当や完了を判断しやすくなります。
一件の区切りをそろえる
一つの問題についての追加連絡は同じ問い合わせに残し、別の問題は分ける。このように社内の登録ルールを決めると、件数と実際の対応がずれにくくなります。
2. 「誰が困っていて、何が起きているか」を残す
短い件名だけでは、別の担当者が状況をつかめません。お客様から聞いた内容と、社内で判断するための情報を、標準項目に沿ってそろえましょう。
| 情報 | 何を表すか | 記録のポイント |
|---|---|---|
| 件名・問い合わせ番号 | どの対応かを識別する情報 | 「印刷できない／営業用端末」など、内容を見分けられる件名にします。 |
| 顧客企業・顧客担当者 | 問い合わせ元の会社と窓口 | 社内の対応担当者と、お客様側の担当者を区別します。 |
| 社内担当者 | 対応を受け持つユーザーやグループ | グループで受ける場合も、誰が着手するかを社内で決めます。 |
| 状態 | 受付・対応中・回答待ち・完了などの進行状況 | 実際の進行に合わせて更新します。 |
| 優先度・重大度・分類 | 対応の順番、影響の大きさ、問い合わせの種類 | 選択する基準をチームでそろえます。 |
| 商品 | 問い合わせの対象 | 関連する商品がある場合に選びます。型番や利用環境も説明に補います。 |
| 説明 | 受付時の内容や発生状況 | いつから、どこで、何をすると、どうなるかを記録します。 |
| コメント・解決策 | 途中のやり取りと、最終的な対応内容 | 調査の経緯と、何をして解決したかを分けて残します。 |
標準項目の構成は公開ソースで確認しています。画面の配置、必須項目、選択肢は導入環境で確認してください。[2][3]
説明は、次の人が調査できる内容にする
「動かない」だけでなく、「本日9時ごろから、営業用端末Aで印刷を実行するとエラーが出る。ほかの端末では印刷できる」と書くと、確認する範囲が絞れます。受付後にまとめて登録する場合は、実際に受けた日時や連絡手段も説明に残しておきましょう。
3. 受付から、次の担当者が動けるところまで
最初の目標は、問い合わせを登録することだけではありません。担当と次の対応を決め、受けた人以外も状況を確認できるようにすることです。
- 既存の問い合わせがないか確認する
会社・担当者・件名などで検索し、同じ問題への追加連絡か、新しい相談かを判断します。重複して登録すると、別々の担当者が同じ調査を始めることがあります。
- 件名・顧客・発生状況を登録する
問い合わせ元、対象商品、困っている内容を整理します。不明な内容は推測で埋めず、確認が必要な点として残します。
- 担当者・状態・優先度を決める
受け持つユーザーやグループを設定し、状態と優先度を確認します。グループへの割り当てだけで終わらせず、最初に確認する人を決めておきます。
- 確認事項と、次の連絡を残す
追加情報を依頼する、調査結果を連絡するなど、次に行うことを明確にします。期限がある仕事は予定・タスクも使って管理します。
- 対応が進んだら、経緯と状態を更新する
調べたこと、連絡した内容、回答待ちになった理由を残します。担当が変わるときは、未確認の点と次にすることも引き継ぎます。
割り当てと、引き継ぎの完了は別
担当者の項目を変更しても、相手が内容を理解して着手したとは限りません。担当変更時の確認方法や、対応中の案件を確認するタイミングも決めておきましょう。
4. 状態は「今どこか」、優先度は「どれからか」
状態と優先度は、表していることが違います。「対応中だから優先度が高い」とは限らず、「回答待ちだから確認しなくてよい」とも限りません。二つを分けて使うと、一覧で判断しやすくなります。
内容と担当を確認する
調査・回答を進める
解決内容を確認して締める
誰からの、何の回答を待っているかを記録。返答が来たら対応を再開し、来なければ決めた時期に確認します。
優先度：どれから対応するか
急いで確認すべきか、通常の順番でよいか。お客様との約束や影響範囲も踏まえ、社内の基準で決めます。
重大度：どの程度の影響か
一部の作業に支障があるのか、業務全体が止まっているのか。現象と影響を確認して判断します。
たとえば、同じ「印刷できない」でも、一台だけの問題と、全拠点で発生している問題では影響が異なります。分類名だけで判断せず、説明に影響範囲も残しておくと、担当を替えた後も状況が伝わります。
毎日見る一覧を決める
「自分の未完了」「回答待ち」「優先度が高いもの」など、担当者や状態で絞り込む一覧を用意します。権限の範囲内で確認できる情報を使い、長く止まっている対応も見直しましょう。
5. 対応の経緯と、次の仕事をつなぐ
問い合わせの履歴には、「何をしたか」と「次に何をするか」の両方が必要です。コメントや説明に調査・連絡の経緯を残し、期限のある対応は予定・タスクでも追えるようにします。[2]
- 社内担当者
- サポート担当・佐藤さん
- 現在の状態
- 回答待ち
- 確認できたこと
- ほかの端末では印刷できる
- 待っている情報
- 端末Aのエラー画面と設定内容
「回答した」と「解決した」を区別する
対処方法をメールで送っただけでは、実際に問題が解消したかはわかりません。お客様の確認が必要なら、その結果を待つ状態として残します。完了にするときは、何をして解決したかと、確認できた結果を解決策（Solution）にまとめましょう。
今回の例なら、「端末Aの出力先を修正し、山田さんにテスト印刷の成功を確認した」と記録します。別の担当者が後で読んでも、実施内容と結果がわかる形にします。
添付資料と、外部への連絡も確認する
エラー画面や手順書などは、関連する文書としてまとめられます。また、問い合わせからメールを作成する操作もあります。利用できる操作は権限やモジュール設定によって異なります。[2]
登録・更新に伴う通知は、メール送信設定やワークフロー等によって動作が変わります。コメントをすべて社内専用メモと考えず、どの内容が誰に通知・表示されるかを確認したうえで運用します。
6. 解決内容をFAQにして、次の回答に役立てる
同じ質問が繰り返し来る場合は、過去の問い合わせを毎回読み直すより、質問と回答を整理しておくと対応しやすくなります。標準の問い合わせには、FAQへ変換する操作があります。表示にはFAQの作成権限等が必要です。[2][5]
| 整理する内容 | 問い合わせの記録 | FAQでの書き方 |
|---|---|---|
| 質問 | 青葉製作所の端末Aで印刷できない | 特定の端末だけ印刷できない場合、何を確認するか |
| 回答 | 今回実施した設定変更と確認結果 | 確認する順番、対処方法、解決しない場合の連絡先 |
| 対象・前提 | 問い合わせた顧客の利用環境 | 適用できる商品・環境・条件を明記する |
| 記載範囲 | 個別のやり取りや調査経緯 | 再利用に必要な情報を選び、顧客固有の内容を見直す |
変換では、件名・商品・解決策等がFAQへ引き継がれます。参照した実装では、コメントも回答へ取り込まれ、FAQの状態は下書き（Draft）として設定されます。変換後のFAQを開き、質問と回答を読み直して整えましょう。[5]
変換した内容を、そのまま共有・公開しない
個別の会社名や連絡先、顧客固有の設定、途中のコメントが混ざっていないかを確認します。誰向けのFAQかと、適用できる条件を整理してから利用します。
問い合わせは「今回の対応の記録」、FAQは「次の人も使える答え」です。両方を使うことで、対応を終えるだけでなく、回答の品質をそろえる土台にできます。
7. 問い合わせ管理で、よくある疑問
電話で受けた問い合わせも登録できますか？
手動で登録できます。問い合わせ元、受けた内容、担当者、状態を残します。電話を受けた時刻と登録時刻が異なる場合は、実際の受付日時や連絡手段も説明に記録しておきましょう。
メールやWebフォームから、自動で登録されますか？
問い合わせモジュールを使い始めるだけで、すべての受信経路がつながるわけではありません。メール連携、フォーム、顧客ポータルなどの設定・構成と、重複時の扱いを確認します。まずは手動登録の基本運用をそろえると、必要な連携も整理しやすくなります。
グループへ割り当てれば、全員が確認できますか？
グループは担当先として利用できますが、レコードの閲覧・編集はロールや共有設定等にも従います。利用者の権限で表示を確認し、グループ内の誰が対応を始めるかも決めておきます。
「回答待ち」にすれば、対応漏れを防げますか？
状態だけでは、次の確認日は決まりません。何の回答を待っているかを記録し、確認用のタスクや一覧の確認ルールを組み合わせましょう。返答が来た後は、状態と次の対応も更新します。
優先度を上げると、自動で通知やエスカレーションが行われますか？
優先度の項目と、自動通知・担当変更・期限管理の仕組みは別です。必要な場合は、ワークフロー等の設定と、実行条件・送信先を確認します。SLAの自動計算や複雑なエスカレーションを一律に標準機能として扱わず、要件に合わせて検討します。
解決したら、問い合わせを削除してもよいですか？
通常は完了の状態にし、解決策と経緯を残すと、後から確認したり同じ問題に対応したりするときに役立ちます。保存期間や削除の判断は、社内の情報管理ルールに合わせて決めます。
最初に何を決めるとよいですか？
一件の区切り、受付時の必須情報、最初に見る担当、状態の更新タイミング、完了にする条件を決めましょう。よくある問い合わせ一件で、受付から解決までを通して試すのがおすすめです。
8. 問い合わせの記録から、対応がつながる仕組みへ
問い合わせを登録できるようになると、「部門をまたぐと止まる」「回答待ちを追い切れない」「同じ質問を何度も調べている」といった、仕事のつなぎ目が見えてきます。ここで必要なのは、入力項目を増やすことだけではありません。
vtplusは、Vtiger CRM OSSを基盤に、自社の業務に合わせた活用・改善を考えるためのサービスです。受付窓口、担当の決め方、連絡のタイミング、解決後の情報共有を整理し、標準機能で進める部分と、追加アプリ・個別開発等を検討する部分を分けるところから相談できます。[6]
標準機能で、まず整える
顧客との関連、担当者、状態・優先度、コメント・解決策、予定・タスク、FAQの使い方をそろえます。
自社の流れに、合わせる
複数窓口からの受付、部門間の引き継ぎ、期限通知、独自の分類・確認画面など、必要な対応方法を検討します。
普段の問い合わせと、受付から解決までの流れをもとに、止まりやすい場面を一つずつ確かめていきましょう。現場の言葉で課題を整理することが、使い続けられる仕組みづくりにつながります。
NEXT STEP
一件の問い合わせを、
チームで答えられる仕事へ。
「誰が受ける？」「いつ確認する？」「解決した内容をどう残す？」。自社の問い合わせ対応を整理するところから、相談できます。