Commerce
WooCommerce と WordPress
WooCommerce — 双方向、統制つき
ワンクリックの連携、深い商品インポート、本物の書き戻し。お客様が選ぶ項目単位の所有権、操作ごとのリハーサルモード、目に見える競合の台帳のもとで動きます。詳しい話は Commerce のページ。
ページ全体WordPress プラグイン
チャットウィジェットを自社サイトに埋め込み、署名付きの SSO トークンを発行します。ログイン済みの顧客は再登録なしでチャット上で認識されます。注文情報も含めてです。
ページ全体Google と Meta のショッピングフィード
Google スキーマのトークン化された商品フィード（Meta Commerce Manager も同じものを読みます）が、広告のカタログを同期し続けます。経路に App Review はなく、手作業の再アップロードもありません。
Shopify 近日
土台は本物です。Shopify の顧客識別情報はすでに連絡先へ集約されており、今日の時点で Shopify ストアは API と Webhook で接続できます。WooCommerce と同じ形のネイティブな双方向同期はロードマップ上にあり、このバッジは出荷した時点で変わります。その前ではありません。
ページ全体サポートとチケット
Zendesk — 移行途中のチームのための橋
Push：チケットを送出
ConnectWiz のチケット会話が Zendesk のチケットを作り、返信をコメントとして反映します。まだ Zendesk で暮らしているチームも、尋ねずに作業の様子を見られます。
ページ全体Pull：担当者の返信を戻す
Zendesk のトリガーが、担当者のコメントを ConnectWiz のスレッドへ投稿し返します。共有シークレットで保護され、ループガードもあるので、2つのシステムがコメントを永遠に打ち合うことはありません。
包み隠さない適用範囲
これはチケットの橋です。作成、返信、どちらの向きも切り替え可能。Zendesk のヘルプセンター、マクロ、SLA のインポートではありません。段階的に移行するために使い、済んだらオフにするものです。
CRM
Estesoft Stella — 会話から見える、自社の CRM
プロバイダ非依存の CRM ポートにおける最初のプロバイダです。Stella を使うクリニックは CRM をそのままに、それをきちんと理解する会話レイヤーを手に入れます。
リアルタイムの文脈を、本人に紐づけて
Stella の予約、見積、残高、メモ、書類が会話上に表示されます。AI も、まさにこの顧客ぶんに限って読めます。ID を推測することはありません。
予約は元のシステムに書き戻る
チャットで取った予約は Stella の台帳に入ります。ベンダーの API が運べない項目があるときは、黙って落とすのではなく、何を落としたかを同期が伝えます。
意図的に断る設計
医療の治療記録を読むことも表示することもなく、ベンダー自身のライフサイクルのラベルを上書きすることもなく、完全な双方向ミラーがあるふりもしません。線引きは設計上の判断であり、書き残してあります。
Estesoft Stella — ページ全体 · 別の CRM を使っていますか。このポートは設計上プロバイダ非依存です — 使っている CRM を教えてください。そして、古いシステムを完全に離れる準備ができたら、下の 移行エンジンが 履歴を運び込みます。
マーケティングとプロバイダ
プロバイダは持ち込み — これが当社の思想です
AI：自社のキー、プロバイダ5社
Wiz は、5社の AI プロバイダーと数十のモデルにわたって、自社のプロバイダーキーで動きます。トークンへの上乗せはなく、用途ごとにモデルを選べ、どのベンダーからも離れられます。詳しくは AI ページ。
プッシュ：自社の OneSignal
訪問者向けの Web プッシュは、自社のドメイン上にある自社のプッシュアプリを通ります。Web プッシュの実際の仕組みがそうなっているからで、違うふりをすれば初日に壊れます。
広告とコンプライアンス
会話と広告プラットフォームと規制当局をつなぐ内部の仕組み
Meta Conversions API
成約した商談は、そのチャットを生んだ広告へ報告されます。チャネルごとに正しく識別子を照合した購入イベントとして、そして CRM のファネルから得られるリードの質のシグナルとともに。データセットもトークンも自社のもので、既定はオフです。イベントが出ていく前には4つのゲート（同意を含む）があり、何が送られ、何が拒否され、その理由は何かを示す状態パネルもあります。
ページ全体この節での正直さのルール
広告と法令対応の連携は、必ず同意のゲートの後ろでしか動きません。拒否されたイベントはすべて、理由とともに記録されます。番号を確信をもって照合できない場合、推測はしません。誤った識別は、他人のプライバシーを消費するからです。
移行
古い CRM を離れ、履歴は残す。
本物の移行エンジン
対応している移行元のシステムについては、連絡先、予約履歴、見積もり、受注、売掛、メモを、キュー方式で途中から再開できるエンジンが取り込みます。実行は当社のチームと一緒に行います。CRM の乗り換えに必要なのは、ボタンではなく運用者だからです。
スキップは名前つきで報告
エンジンは値をでっち上げることを拒みます。通貨や日付が欠けているレコードはスキップされ、件数として数えられます。だから「移行完了」が、まだ旧システムに残っているレコードを隠すことはありません。
所有権の切り替えは最後
データの所有権が移るのは、取り込みが自ら正しさを示したあとの最後の手順です。自社がそうでないと決めるまで、正本は旧システムのままです。
OpenAPI の契約は1つ
プラットフォーム全体が、1つの OpenAPI 3 ドキュメントで仕様化されています。当社の Web パネルとモバイルアプリが型を生成しているのと同じ契約です。隠しエンドポイントも、ドキュメントのずれもありません。
スコープ付きの Commerce API キー
テナントが発行する、明示的なスコープ付きのキーです。カタログ読み取り、注文読み取り、注文書き込み。当社のカタログと注文のエンジンの上で、自社のストアフロントやアプリを動かせます。
受信 Webhook を保護
外部のシステムはどれでも自動化を起動できます。起点になるのは フロー — その Webhook トリガーには、それぞれ固有の URL、固有のシークレット、HMAC 検証、リプレイ防止があります。ペイロードはデータであって、命令ではありません。
送信：フローが呼び出す
REST の手順は、キャンバス上で描いたとおりの瞬間に自社のシステムを呼び出します。すべてを購読する汎用の Webhook フィードは、まだ実装していません。営業の場で気づいていただくのではなく、ここに書いておきます。