VTIGER CRM OSS STANDARD GUIDE
受信箱に届くメールを、
担当者が動ける情報へ。
「問い合わせメールをCRMへ転記している」「返信が届くたびに、どの問い合わせの続きか探している」。受信箱とCRMが分かれていると、受付や履歴の整理に手間がかかります。
Vtiger CRM OSSのメールコンバーター（Mail Converter）は、設定したメールボックスを読み取り、条件に合うメールを問い合わせの作成・更新や、顧客情報へのメール関連付けなどの処理へつなげる標準機能です。
この記事でわかること
受信からCRM処理までの流れ、メールボックス・フォルダー・ルールの設定、新しい受付と返信の使い分け、手動スキャンと定期実行、運用時の確認点を図解します。
対象：Vtiger CRM OSS 8.4系の標準実装。画面名・翻訳・利用できる操作は、導入環境や設定により異なります。図は仕組みを説明する概念図で、実際の画面ではありません。
1. メールコンバーターの役割
基本は、どのメールを読むか、何を条件にするか、CRMで何をするかの三つです。たとえば、サポート用の受信箱を対象にし、件名などの条件に合うメールを問い合わせとして登録できます。
受信を確認する
メールボックス・フォルダー処理したい受信箱と、
対象となるメールを決める。
ルールで判定する
差出人・宛先・件名・本文登録した条件を順に確認し、
実行する処理を決める。
CRMへ反映する
作成・更新・メール関連付け問い合わせや顧客の情報へ、
受信内容をつなげる。
| 機能 | 主な役割 |
|---|---|
| メールコンバーター | メールボックスをスキャンし、受信内容を条件にCRMの処理へつなげる。 |
| Mail Manager等のメール画面 | 利用者がメールを確認・操作する。受信メールをルールで処理する設定とは分けて考える。 |
| Webフォーム | Webサイトのフォームから送信された項目をCRMへ登録する。 |
| ワークフロー | CRMレコードの保存等を起点に、条件とタスクを実行する。メールコンバーターで作成・更新した場合の連動も確認する。 |
まずは「サポート受付を問い合わせへ残す」など、一つの用途から始めると、条件と結果を確認しやすくなります。
2. 標準で選べる主な処理
参照したOSS 8.4系の標準には、次の処理があります。レコードを作ること、既存の問い合わせへ追記すること、メールを関連付けることを分けて理解しましょう。
| 処理 | 主な動き・確認点 |
|---|---|
| 問い合わせの作成 Create Ticket | 件名を問い合わせのタイトル、本文を説明へ反映する。担当はルールで指定。差出人に対応する顧客担当者を探し、見つからない場合に作成する処理もある。 |
| 問い合わせの更新 Update Ticket | 件名等から対象を特定し、差出人との関係も確認して、本文をコメントとして追加しメールを関連付ける。対象が見つからなければ、この処理だけで必ず新規作成されるわけではない。 |
| リード・顧客担当者・顧客企業の作成 | 差出人情報や本文を利用して登録する。同じ対象モジュールに差出人のメールが見つかる場合、既存レコードへメールを関連付ける処理がある。 |
| 既存情報へのメール関連付け Add to … [FROM] / [TO] | 差出人または宛先のメールアドレスから、既存の顧客担当者・顧客企業・リードを探し、メールを関連付ける。顧客のすべての項目を書き換える処理とは異なる。 |
FROMは差出人、TOは宛先です。顧客から届いたメールを顧客側へ残したいときは、どちらのメールアドレスで探すかを確認します。社内の受付アドレスを対象にして、意図しない顧客へ関連付けないようにしましょう。
「問い合わせを作るときの顧客情報」も確認します。
参照した標準の作成処理には、顧客担当者を新しく作る動きがあります。初めての差出人、社名だけの表示名、共有アドレス等で、名前や関連先がどのように保存されるかを試しておきます。
メール内の署名から会社名・役職・電話番号等がすべて正しく整理されるとは考えず、実際の作成値を確認します。添付ファイルを保存・関連付ける処理もありますが、形式・容量・保存先・閲覧権限を導入環境で確認してください。
3. メールボックスと対象を設定する
設定画面を開く前に、処理する受信箱とフォルダーを絞ることから始めます。個人の受信箱全体よりも、用途を決めた受付用のメールボックスを使うと、運用を整理しやすくなります。
- メールコンバーターの設定を開く
管理者がCRM設定の「Mail Converter」「メールコンバーター」等を開き、メールボックスを追加します。表示されない場合は、導入状態や設定権限を確認します。
- メールサーバーへの接続情報を設定する
管理用の名前、サーバー、ユーザー名、認証情報、接続方式等を設定します。メールサービスが認める接続・認証方法と、導入した標準機能が対応する方法が合うかを確認します。
- 読み取り対象のフォルダーを選ぶ
受信箱やサポート用フォルダーなど、処理する場所を選択します。メール側の振り分けで別フォルダーへ移動したものも、対象に含める必要があるかを見直します。
- 対象メールとスキャン後の扱いを確認する
未読等の対象条件、スキャン後の既読・未読等の扱い、タイムゾーン、有効状態を確認します。対象の選択肢や名称は実際の画面に合わせます。
- ルールを作り、少数のテストメールで試す
接続できたことと、目的のCRM処理ができたことを分けて確認します。本番の大量メールを対象にする前に、処理範囲と結果を確かめましょう。
IMAP等の接続機能と、Web画面・定期実行側で必要なサーバー機能を確認します。画面に接続欄があることだけで、すべてのメールサービスや認証方式への対応を判断しないようにします。
4. 条件と処理をルールにする
ルールでは、対象とするメールの条件と、一つの実行アクションを組み合わせます。差出人・宛先、件名・本文等を使い、複数条件なら「すべてに一致（AND）」か「いずれかに一致（OR）」を決めます。
| 設定 | 考え方 |
|---|---|
| 差出人・宛先 | 特定の受付先や差出人を対象にする。転送・共有アドレスでは、実際に届くヘッダーを確認する。 |
| 件名・本文 | 「含む」「等しい」等の条件を選ぶ。件名には正規表現やチケット番号に関する条件もある。 |
| AND / OR | 受付先と件名の両方を条件にするならAND。ORにすると対象が広がるため、テストメールで確認する。 |
| 処理・担当 | 作成、問い合わせ更新、メール関連付けから目的に合う処理を選ぶ。新規作成時の担当も確認する。 |
| 優先順 | 既存の問い合わせへの返信など、先に判定したい具体的なルールを上位へ置く。 |
既存の問い合わせへの返信
件名の識別情報と、差出人・関連先等を確認する。
新しいサポート受付
新規受付として扱う条件に合うかを確認する。
広い条件の「問い合わせを作成」を先に置くと、返信まで新規受付として扱われる可能性があります。ルールの一致だけでなく、どの処理が成功し、どこで判定が止まるかを含めて試しましょう。
返信は「件名に数字がある」だけで結び付きません。
問い合わせ番号等を見つける条件と、既存レコードの照合を分けて確認します。「Has Ticket Number」は特定の書式を探す実装のため、自社で付けた番号が何でも使えるわけではありません。必要に応じて件名の統一や正規表現を検討します。
差出人や件名の条件を決めることと、本文から項目値を取り出すことも別です。まずは基本のアクションが保存する内容を確認し、本文の定型化や項目への振り分けが必要なら、追加の設定・対応範囲を切り分けます。
5. 手動スキャンと定期実行を確認する
手動の「Scan Now」「今すぐスキャン」等は、接続とルールの結果を試す入口です。継続して自動処理するには、CRM側のスケジューラーと、サーバー側のcronによる起動も確認します。
メール側
対象を読めるか接続、対象フォルダー、
未読等の条件を確認する。
CRM側
意図した処理になったか新規・更新・関連先、
保存内容と担当を確認する。
定期実行
人が操作しなくても動くかジョブの有効状態、
実行間隔と実行結果を見る。
| 試す場面 | 確認する結果 |
|---|---|
| 初めての差出人 | 問い合わせ、必要に応じた顧客担当者、名前・メール・説明・担当がどのように作られるか。 |
| 既存顧客からの新しい相談 | 顧客の照合と関連先、新規問い合わせとしての登録が意図どおりか。 |
| 既存問い合わせへの返信 | 新規作成ではなく、対象のコメント・メールへ反映されるか。件名変更や別アドレスからの返信も試す。 |
| 条件に合わないメール | 不要なレコードが作られないか。既読等の状態とスキャン済み記録の扱いも確認する。 |
| 添付・日本語・転送 | 件名・本文・添付・差出人が、実際のメール形式でも正しく扱われるか。 |
| 次の定期実行 | 新しく届いたメールを自動処理できるか。処理済みメールを重複して登録しないか。 |
「既読になった」ことと「CRM処理が成功した」ことは別です。
参照した標準には、条件不一致等でレコードが作られない場合にも、スキャン済みの記録やスキャン後のメール状態を更新する処理があります。CRM側の結果まで確認してください。
ルール変更後に「同じ古いメールで試したが動かない」ときは、未読条件、最終スキャン時点、処理済み記録、再スキャン対象等を見直します。まず新しいテストメールで結果を分けて確認すると、原因を絞りやすくなります。
6. 登録後の対応と運用を整える
受付が自動化されても、対応の完了まで自動になるわけではありません。誰が確認し、いつ連絡し、どの情報を残すかまで決めておくと、受信内容をチームの仕事へつなげやすくなります。
| 確認すること | 運用の例 |
|---|---|
| 受付の確認 | 担当者別の問い合わせ一覧やフィルターから、新規・未対応をいつ確認するか決める。 |
| 担当と関連先 | 新規作成の割り当てと、既存問い合わせの担当を区別する。同じメールを複数顧客が使う場合の照合も見直す。 |
| 返信と完了の扱い | 返信コメント、次の連絡、状態の更新を確認する。参照した標準では、閉じた問い合わせが返信処理でOpenへ戻る動きもある。 |
| 通知・自動返信 | 登録・コメント追加・状態変更のそれぞれで、誰に何を送るか決め、送信設定と実際の動作を確認する。 |
| 条件から漏れたメール | 受信箱に残る未処理分を確認する担当と、ルール変更の窓口を決める。 |
| 接続・実行の見直し | 認証情報やフォルダーの変更、定期処理の停止に気付けるよう、定期的に実行状況を確認する。 |
特に、問い合わせの更新を、通常画面での保存と同じものだと決めつけないことが大切です。コメント・メールの追加や直接の状態更新を行う処理があるため、期待するワークフロー通知が発火するかを、実際のメールで確認します。
まずは受付の転記を減らし、次に担当者への引き継ぎ、返信履歴の共有、未対応の確認へと広げると、運用を定着させやすくなります。
7. よくある質問
Q. メールを受信した瞬間にCRMへ登録されますか？
標準ではメールボックスをスキャンして処理します。自動運用にはスケジューラーとサーバー側のcronを確認し、受信から反映までの時間も実環境で確かめます。
Q. すべての受信メールを問い合わせにできますか？
対象フォルダーと条件を広げる設定はできますが、案内メールや自動返信等まで登録されないように範囲を決めます。最初は用途を絞った受信箱と条件から始めると確認しやすくなります。
Q. 返信を同じ問い合わせへ追加できますか？
問い合わせ更新の処理があります。件名の識別情報、既存レコード、差出人との関係等を照合できることが必要です。件名が変わった返信や別アドレスからの送信も試します。
Q. 「顧客に追加」は、顧客情報の上書きですか？
Add to Contact等の関連付けは、FROMまたはTOのメールアドレスで既存レコードを探し、メールを関連付ける処理です。氏名や住所等を一律に上書きする機能としては扱いません。
Q. 同じメールをもう一度スキャンすると、必ず重複しますか？
標準にはスキャン済みの記録と再処理を判定する仕組みがあります。ただし、再スキャンの設定、転送等で別のメールになった場合、複数の処理経路等を含めた重複防止まで一律には保証できません。実際の運用経路で確認します。
Q. 通知メールや受付完了メールも、自動で送れますか？
CRMへの反映とメール送信を分けて設計します。メール設定やワークフロー等を確認し、新規作成・返信による更新の両方で、必要な相手へ意図した通知が届くかを試してください。
Q. 添付ファイルもCRMに残せますか？
標準に保存・関連付けの処理があります。少量のファイルで、文書・メール等のどこへ関連するか、容量や日本語名、担当者からの閲覧を確認します。添付内容の読解やOCRまでを表すものではありません。
8. 受信の自動化を、対応の流れへ
メールコンバーターの第一歩は、受信する場所、条件、CRMでの処理をそろえることです。そのうえで、担当者の確認、返信、次の予定、対応完了までを整えると、メールの受付をチームで進める仕事へつなげられます。
受信の条件を整理する
窓口・差出人・件名・新規と返信の違いから、処理の入口を整理します。
対応の進め方をそろえる
担当、通知、次の連絡、未対応の確認、完了までの流れを決めます。
vtplusは、Vtiger CRM OSSを基盤に、自社の業務に合わせた活用を支援するサービスです。まず標準のメールコンバーターと問い合わせ・顧客管理で整理できる範囲を確認し、窓口ごとの処理、担当への引き継ぎ、通知、定型メールの扱い、未対応の見える化等は、業務に合わせて対応方法を検討できます。
「メールを転記している」「同じ問い合わせの続きを探すのに時間がかかる」。そんな日々の作業から、自社に合う受付と対応の流れを整理してみませんか。
NEXT STEP
受信箱のメールを、
チームが動ける情報へ。
「どの窓口をCRMにつなぐ？」「返信をどうまとめる？」「担当者へどう引き継ぐ？」。自社のメール受付と対応の流れを整理するところから、相談できます。