VTIGER CRM OSS STANDARD GUIDE
Webサイトから届く相談を、
次の対応につながるリードへ。
「問い合わせメールを見て、顧客情報をCRMへ転記している」「相談は届いたのに、担当者への引き継ぎが遅れてしまう」。Webサイトの受付と顧客管理が分かれていると、入力や確認が重複しやすくなります。
Vtiger CRM OSSのWebフォーム（Webforms）は、Webサイトのフォームから送信された情報を、指定したモジュールのレコードとして登録する標準機能です。この記事では、資料請求や導入相談をリード（見込み客）へ登録する使い方を中心に解説します。
この記事でわかること
Webフォームの役割、登録先・項目・担当者の設定、生成HTMLの設置、送信結果とCRM登録の確認、登録後の対応を図解します。
対象：Vtiger CRM OSS 8.4系の標準Webforms。画面名・翻訳・利用できる項目や操作は、導入・有効状態・設定により異なります。図・会社名・フォーム名は説明用です。記事中のフォーム図に送信機能はありません。
1. Webフォームでできること
Webフォームは、訪問者が入力するWebサイトと、社内で情報を管理するCRMをつなぐ入口です。入力内容をCRMの項目へ受け渡し、担当者が確認できる形へ整えます。
Webサイト
相談・資料請求を受け付ける訪問者が必要な情報を入力し、
フォームから送信する。
CRMのリード
見込み客情報として登録氏名、会社名、連絡先、
相談内容等を項目に残す。
担当者の対応
内容を読み、次の行動を決める連絡・資料送付・確認を進め、
予定やタスクを残す。
標準では、リードのほか、顧客担当者・顧客企業・案件・問い合わせ・仕入先等に対応する対象があります。今回は、新しい相談の受付をリードへ残す例です。既存顧客のサポート受付なら、問い合わせ等の別の登録先も、運用の目的に合わせて検討します。
Webフォームからリードを作ることと、顧客企業・担当者・案件へ顧客化することは別です。受付後に状況を確認し、必要な段階でリードの変換や案件管理へ進めます。
2. 登録先と入力項目を決める
最初に、何の受付か、何を聞くか、誰が確認するかを決めます。社内で使う項目を、そのまますべて訪問者へ入力してもらう必要はありません。
| 決めること | 例・確認する内容 |
|---|---|
| フォームの目的 | 導入相談、資料請求等。フォーム名は管理者が見分けられる名前にする。 |
| 登録先モジュール | 今回はLeads（リード）。訪問者の入力を、どのレコードに残すか。 |
| 入力してもらう項目 | 姓・名、会社名、メール、電話、相談内容等。対象モジュールで選べる項目から決める。 |
| 必須項目 | CRM側の必須と、受付に必要な連絡先等を確認。入力時点でわかる情報へ絞る。 |
| 担当者 | 受付を確認する担当を指定する。複数人へ順番に割り当てる場合は、ラウンドロビンの対象も確認する。 |
| 戻りURL | 送信後に戻すWebページ。成功・失敗時の案内も含めて考える。 |
| 上書き値・非表示 | 訪問者に入力させず、リード情報源等の値を設定する場合に使う。何を固定するかを決める。 |
| 公開サイトでの案内 | 入力の目的、連絡方法、利用目的の案内先等を、自社のWebサイトの方針に合わせて整理する。 |
たとえば、Webサイトでは会社名・姓・メール・相談内容を受け付け、社内の担当者はフォーム設定で割り当てる、と分けられます。訪問者が知らない社内の担当区分まで入力させない形にしましょう。
「上書き値（Override Value）」は、空欄を補うだけの値とは分けて考えます。
参照した標準の受信処理では、Webフォームに設定した上書き値が優先されます。訪問者の入力を残したい項目へ固定値を入れ、内容が置き換わらないように確認します。
必要なカスタム項目は、登録先のモジュールへ先に用意し、Webフォームの項目候補に出るかを確認します。すべての項目型が同じ入力方法で使えるとは限りません。
3. CRMでWebフォームを作成する
管理者がCRMのWebフォーム設定を開き、登録先・担当者・項目の組み合わせを作成します。
- Webフォームの設定画面を開く
CRM設定の「Webforms」「Webフォーム」等から追加操作を開きます。メニューがない場合は、標準モジュールの導入・有効状態や設定権限を確認します。
- フォーム名と登録先を決める
「Web導入相談」等の管理用の名前を付け、対象をリードにします。説明欄へ用途を残しておくと、複数のフォームを見分けやすくなります。
- 担当者・戻りURL・有効状態を設定する
誰が受付を確認するかを決めます。ラウンドロビンを使う場合は対象者と割り当て結果を確認します。公開前に、フォームを使える状態かも見直します。
- 項目を選び、必須・順序・上書き値を確認する
訪問者が入力する項目と、固定値として渡す項目を分けます。非表示にする必須項目には登録に必要な値を用意し、空欄のまま隠していないか確認します。
- 保存して、フォームのHTMLを取得する
詳細画面の「Show Form」「フォームを表示」等から生成されたコードを確認・コピーします。実際のWebサイトへの設置は、次の作業として進めます。
導入のご相談
- 姓 必須
- 山田
- 会社名
- 青葉製作所
- メール
- yamada@example.com
- 相談内容
- 顧客対応の情報を共有したい。
リード：山田さん
- 会社・連絡先
- 入力された値を対応項目へ
- 相談の説明
- 顧客対応の情報を共有したい。
- 担当者
- フォーム設定で指定した鈴木
- リード情報源の例
- 上書き値で「Webサイト」を指定
4. 生成HTMLをWebサイトへ設置する
標準のWebフォームは、CRMが生成したHTMLをWebサイトへ置いて使います。見た目だけでなく、送信先とCRM項目への受け渡しを保つことが大切です。
- 生成コード全体を確認する
フォームの送信先、識別用の値、項目名、必要なスクリプト等を含むコードを取得します。見える入力欄だけを抜き出して設置しないようにします。
- サイト側の対応する場所へ設置する
HTMLや必要なスクリプトを扱える編集機能・テンプレート等を使います。WordPress等で要素が除去される場合は、サイト管理者が設置方法を確認します。
- 案内文・入力の見やすさを整える
項目の説明、必須の表示、送信後の案内、スマートフォンでの見え方を確認します。装飾を変える際も、送信に使う項目名や識別情報を保ちます。
- 公開サイトからCRMへ送れるかを確認する
外部から届く正しい送信先URLになっているか、通信やサイト側の制約がないかを確認します。HTTPSの公開ページでは、送信先や読み込むものも含め、実際の動作を見直します。
既存の問い合わせフォームやフォームプラグインが、見た目を似せるだけで自動的にCRMへ接続されるわけではありません。既存フォームを使うなら、送信先・識別情報・項目名等を対応させる方法を別に確認します。
また、CRM側で項目や必須条件を変えても、Webサイトへ置いたHTMLが自動で差し替わるとは限りません。変更後はコードを再取得するなど、掲載側との整合を確認し、送信テストを行います。
CAPTCHAを有効にする場合は、reCAPTCHAのキー・対象ドメイン・CRM側の設定・スクリプトの動作を確認します。チェックを入れるだけで公開サイトの設定がすべて完了するものではありません。
5. 送信結果とリード登録を確認する
テストでは、Web側の結果、CRM側の登録、担当者が確認できることを分けて見ます。表示上は送信できたように見えても、登録結果まで確認して完了にしましょう。
Web側の結果
入力と案内必須の入力、送信結果、
成功・失敗時の案内を見る。
CRM側の登録
値と担当リードが作成されたか、
項目・固定値・担当を確認する。
担当者の確認
その後の対応対象を参照できるか、
連絡・次の確認へ進めるかを見る。
| 試す場面 | 確認する内容 |
|---|---|
| 通常の送信 | 日本語・メール・電話・相談内容が、意図したリードの項目へ保存されるか。 |
| 必須項目が空欄 | 必要な入力の案内と、CRM側で登録される・されない結果。表示だけで判断しない。 |
| 上書き値・非表示項目 | 固定する値が正しいか。訪問者の回答を意図せず上書きしていないか。 |
| 担当の割り当て | 指定先か、ラウンドロビンの設定どおりか。担当者が対象を参照できるか。 |
| 再送信・同じメール | 新規作成・重複防止・エラー等の結果を確認する。自動更新されると思い込まない。 |
| 戻り先・エラー | 成功と失敗を適切に案内できるか。戻り先の表示とCRMの結果が一致するか。 |
| CAPTCHA・スマートフォン | 有効にした認証が機能するか。公開サイトの端末・ブラウザで入力と送信ができるか。 |
「戻り先が表示された」だけで、登録成功とは判断しません。
標準には、成功・エラーの結果を付けて戻り先へ返す処理があります。サイト側で結果に合う案内を行い、CRMに対象レコードができているかも確認します。
届かない場合は、フォームの有効状態、掲載コードの送信先・識別情報、必須項目、上書き値、CAPTCHA等を順に確認します。サイト表示とCRM受信のどちらで止まっているかを分けると、見直す場所を絞りやすくなります。
6. 登録後の確認と対応を決める
Webフォームを使う目的は、転記を減らすことに加えて、届いた相談へ確実に対応できる状態を作ることです。登録された後の仕事も合わせて決めましょう。
| 決めること | 例 |
|---|---|
| 確認する担当と頻度 | 担当者別の一覧やフィルター等から、受付分をいつ確認するか。 |
| 最初の連絡 | 相談内容を読み、誰が返信・電話・資料送付を行うか。 |
| 通知と自動返信 | 担当者への通知と、訪問者への受付メールを別に整理する。ワークフローやメール設定も確認する。 |
| 重複・再送への対応 | 既存リードや顧客との照合、同じ相談の再送をどう扱うか。 |
| 次の予定・タスク | 追加確認、打ち合わせ等を、担当・期限付きの仕事として残す。 |
| フォームの変更・停止 | CRM設定と掲載HTMLを誰が更新するか。無効化時のサイト表示や、古い設置先をどう見直すか。 |
Webフォームの受信処理はレコードの作成を行います。同じメールアドレスの送信を、いつでも既存情報の更新や統合として扱う仕組みだと考えず、重複防止の設定や実際の結果を確認します。
担当者への割り当てと、通知メール・受付完了メール・タスク作成も別です。必要なものは標準ワークフロー等の設定を確認し、「登録されたが誰も気付かなかった」を防ぐ確認の流れを整えましょう。
CRM内部の選択肢や依存関係、項目の表示条件が、掲載HTMLにもすべて同じように反映されるとは限りません。入力経路がWebへ変わる場合は、使う項目の候補と保存結果も確認します。
7. よくある質問
Q. 既存の問い合わせフォームを、そのまま使えますか？
標準が生成したHTMLを設置する方法と、既存フォームを接続する方法を分けて考えます。既存フォームでは、送信先・フォーム識別情報・項目名等を対応させる方法を確認します。
Q. 同じメールアドレスなら、既存のリードを更新しますか？
標準の受信はレコード作成を行います。同じメールなら必ず更新・統合されるとは限りません。重複防止の設定と、再送時の作成・エラー等を実際に確認します。
Q. 戻りURLを設定すれば、登録成功が確認できますか？
戻り先へ移動したことと、登録成功は別です。成功・エラーの結果に合った案内を用意し、CRM側のレコードと担当を確認します。
Q. 必須項目を、訪問者に見せずに登録できますか？
固定値で登録する場合は上書き値等を設定し、非表示にする項目にも必要な値を用意します。必須欄を空のまま隠す方法としては扱わず、受信結果を確認します。
Q. CAPTCHAを有効にすれば、そのまま使えますか？
標準にはreCAPTCHAの処理がありますが、キー・対象ドメイン・CRM側の設定・掲載側スクリプトの動作確認が必要です。公開サイトで認証と送信を試します。
Q. 受付完了メールや担当者への通知も、自動で送られますか？
Webフォームへの登録設定だけで、必要なメールがすべて送られるとは考えないようにします。担当割り当て、通知、訪問者への自動返信を分け、メール設定やワークフローを確認します。
Q. ファイルを添付するフォームも作れますか？
OSS 8.4系の標準にはファイル欄と、登録したレコードへ文書を関連付ける処理があります。必要な場合は、対応形式・容量・サーバ設定・サイト側の設置方法を確認し、少量のファイルで結果を試します。
8. Webの受付を、顧客対応の流れへ
Webフォームの第一歩は、目的に合う項目を選び、送信内容を正しい登録先と担当者へ渡すことです。そこから内容を読み、連絡し、次の仕事を残すところまで揃えると、Webの受付を顧客対応へつなげやすくなります。
受付とCRMをつなぐ
訪問者が入力する情報と、社内で管理する項目・分類・担当を整理します。
登録後の動きをそろえる
受付確認、初回連絡、重複の確認、次の予定やタスクまでの流れを決めます。
vtplusは、Vtiger CRM OSSを基盤に、自社の業務に合わせた活用を支援するサービスです。まず標準のWebフォーム・リード・活動管理で整理できる範囲を確認し、既存サイトとの接続、部門ごとの受付と割り当て、通知・返信、重複の扱い、対応状況の見える化などは、要件に合わせて対応方法を検討できます。
「フォームの内容を毎回転記している」「Webの相談が担当者へ届くまで時間がかかる」。そんな課題から、自社の受付と顧客対応のつなぎ方を一緒に整理してみませんか。
NEXT STEP
Webサイトの相談を、
担当者が動ける見込み客情報へ。
「何をフォームで聞く？」「誰へ割り当てる？」「登録後の連絡をどう進める？」。自社のWeb受付と対応の流れを整理するところから、相談できます。