課題
SNSやメッセージの接点が増えると、会話と顧客情報、担当者、商談、注文が別々になりやすい。どの窓口から来た相談でも、対応の経緯と次に行う仕事を確認できる基盤が必要だった。

顧客情報・商談・メッセージ・受注連携を扱うTIXIMAXのCRM
開発範囲を整理した概念図です。実際のシステム画面・構成図ではありません。
SNSやメッセージの接点が増えると、会話と顧客情報、担当者、商談、注文が別々になりやすい。どの窓口から来た相談でも、対応の経緯と次に行う仕事を確認できる基盤が必要だった。
Social Inbox、顧客プロフィール連携、商談パイプライン、注文ドラフト、キャンペーンを構成。Facebook・Instagram・WhatsApp・Zaloなどの接続・メッセージ処理を用意し、会話から顧客の確認、商談管理、受注側への引き継ぎをつないだ。
チャネルごとの会話に担当者と商談を関連づけ、顧客情報や注文の文脈を確認できる構成に。商談成立後も、注文の下書きをスタッフが確認して受注側へ渡す。各チャネルの提供範囲はAPI権限・審査・接続設定によって異なる。
Facebook、Instagram、WhatsApp、Zaloなどに分かれた会話。その窓口をまとめるだけでなく、顧客情報、担当者、商談、注文の下書きへつなぐTIXIMAXのCRM開発を紹介します。
複数のSNSやメッセージアプリで問い合わせを受けると、会話の履歴がチャネルごとに分かれます。担当者が交代した際に、誰の相談で、何を確認し、次に何をすればよいかがわからなければ、返信できる状態でも顧客対応は進みません。
TIXIMAXのCRMで扱うのは、この会話の前後にある仕事です。Social Inboxによる会話管理、顧客プロフィールとの関連づけ、商談パイプライン、注文ドラフト、キャンペーンを構成し、問い合わせを営業や受注の流れに接続します。
「すべてのSNSを同じ画面に並べる」ことだけを目的にしていません。どのチャネルからの相談であっても、担当する人が顧客と業務の文脈を確認できることを重視しています。
Social Inboxには、チャネル接続、受信Webhook、メッセージの振り分け、担当者の割当、返信、添付メディアを扱う構成があります。Facebook・Instagram、WhatsApp、Zaloなどの接続・処理を備え、外部の窓口を会話管理へつなぎます。
一方、利用するAPIやアカウントの種類、送信できる内容はチャネルごとに異なります。WhatsAppの送信、Zaloのメディア処理、Meta系チャネルの識別を、同じ接続設定だけで済ませることはできません。共通の会話管理と、チャネル固有の処理を分けた構成になっています。
TikTokについてもBusiness Messagingのコードがありますが、ソースには実APIでの検証待ちが明記されています。本記事では、これをFacebookなどと同じ条件で稼働している実績としては扱いません。また、紹介しているのは主に顧客対応・メッセージ連携であり、すべてのSNSへの動画投稿や広告運用を一律に自動化するという説明ではありません。
チャネル上のアカウントと、事業で扱う顧客は同じ単位とは限りません。相談を受けた時点では顧客が特定されていない場合もあれば、一人の顧客が複数の連絡先や住所を持つ場合もあります。
顧客プロフィールの基盤では、複数の役割、住所、法人に関する情報などを管理します。CRMはプロフィール側への検索・照合・関連づけの接点を持ち、Social Inboxの連絡先と顧客の情報をつなぎます。
会話が届いたことと、誰の相談かが確認できたことを分けて扱うことで、対応の文脈を整理します。顧客情報をすべて会話の中に書き込むのではなく、プロフィールと会話がそれぞれの役割を持つ構成です。
問い合わせのすべてが、すぐに注文になるわけではありません。相談中、見込み、検討、フォローという経過があり、成約だけでなく失注もあります。会話が続いていることと、商談がどこまで進んだかは、別の情報です。
CRMには、顧客に紐づく商談と段階の変更履歴を管理するパイプラインがあります。担当者による操作に加え、設定に応じたフォローや状態更新の自動処理も持ちます。会話と商談を関連づけることで、対応する画面から営業上の進捗を確認できる構成です。
ここでの自動化は、顧客の意思を自動で推測して成約を確定するという意味ではありません。状態や経過に基づく処理と、担当者が判断して進める操作を組み合わせています。
商談が成立しても、商品、価格、配送先などの情報がすべて揃っているとは限りません。会話の内容だけから無条件に正式な注文を作ると、その後の業務に不完全な情報を渡すおそれがあります。
実装には、商談成立を受けて関連する注文ドラフトを作る橋渡しがあります。これは必要な情報が完成した正式注文ではなく、下書きの骨組みです。スタッフが商品や価格を入力し、確認を経て受注側へ引き継ぎます。
会話から商談へ、商談から注文の下書きへ、確認して受注へ。 この段階を分けることで、営業担当者の仕事と受注システムの責任範囲をつないでいます。再度同じ連携を受けたときに、下書きを重複させないための扱いも設計に含まれます。
個別の会話に加え、キャンペーンには作成、配信予定、開始・停止、配信処理、集計と流入元の関連づけがあります。配信したという事実だけでなく、どの取り組みから相談につながったかを扱うための接点を備えています。
この開発領域が示すのは、チャット、顧客台帳、営業管理、注文を別々の便利な道具として終わらせない設計です。担当者が途中で文脈を失わず、必要な情報を次の仕事へ渡す。そのために、共通化できる部分と、チャネルや業務ごとに分ける部分を整理しています。
荷物を受け付けてから梱包・輸送・到着へ進める管理については、TIXIMAXの物流開発事例をご覧ください。事業の公開情報は tiximax.jp と tiximax.net で案内されています。
このプロジェクトで担当した
5つのシステム・領域。
受信Webhook、会話の振り分け・担当割当、返信、添付メディア、会話の状態を管理する。
チャネル上の連絡先と顧客情報を関連づけ、複数の住所・役割を持つ顧客の文脈を確認する。
相談・見込み・検討・フォロー・成約・失注を扱い、担当者の操作と自動処理による状態変更を記録する。
会話や商談から注文の下書きを作り、商品・価格の入力と確認を経て受注側へ引き継ぐ。
キャンペーンの作成、配信予定、開始・停止、配信処理と集計・流入元の関連づけを扱う。
海外購入代行から国際配送までを案内するTIXIMAX。お客様が利用するサービスの裏側には、荷物を動かす物流基盤と、問い合わせ・商談をつなぐ顧客対応基盤があります。
ここでは、その事業背景が伝わるよう、日本向け・グローバル向けの公式サイトをご紹介します。
TIXIMAX JAPAN tiximax.jp ↗
TIXIMAX GLOBAL tiximax.net ↗TIXIMAX公式サイトの公開画面(2026年9月撮影)。物流・CRM管理画面ではありません。
御社の業務やデータ、既存システムの条件に合わせて、実現方法を検討します。
この事例について相談する ↗
CASE 01 ベトナム料理店 Betoya(ベト屋)
お客様・ホール・キッチン・レジが同じ注文を扱い、本部側から商品や店舗ごとの運営情報を管理できる構成を整備した。注文変更、分割会計、厨房への伝票出力、在庫移動や棚卸まで、飲食店の日々の業務を支える。導入範囲や外部決済の利用条件は店舗ごとに異なる。