Commerce
WooCommerce 與 WordPress
WooCommerce——雙向，而且有治理
一鍵配對、深度商品匯入、真正的寫回——全都在您自己選定的欄位層級歸屬權之下，每個操作都有演練模式，衝突也有一本看得見的帳本。完整的說明在 Commerce 頁面。
完整頁面Google 與 Meta 商品資料饋給
一份採 Google 結構、帶 token 的商品饋給（Meta Commerce Manager 讀的是同一份），讓您的廣告商品目錄保持同步——路徑上不必過應用程式審核，也不必手動重新上傳。
Shopify 即將
底子是真的——Shopify 的客戶身分已經可以聯合到聯絡人上，而現階段 Shopify 商店是透過 API 和 Webhook 串接。比照 WooCommerce 規格的原生雙向同步還在藍圖上，這個徽章會在它出貨那天翻轉，不會更早。
完整頁面客服與工單
Zendesk——給搬到一半的團隊用的一座橋
Pull：客服回覆收回來
Zendesk 的觸發器會把客服留言送回 ConnectWiz 的對話——以共用密鑰保護，並有迴圈防護，兩套系統不會把一則留言永遠彈來彈去。
不加修飾的適用範圍
它是一座工單橋——建立、回覆，兩個方向都可開關——不是 Zendesk 說明中心、巨集或 SLA 的匯入工具。團隊用它慢慢搬，搬完就關掉。
CRM
Estesoft Stella——您的 CRM，在對話裡就看得到
這是我們不綁供應商的 CRM 接口上第一家供應商：用 Stella 的診所可以留著原本的 CRM，再多一層真正認得它的對話層。
即時上下文，綁定身分
Stella 裡的預約、報價、餘額、備註和文件都會浮現在對話上——而 AI 只讀得到「就是這位客戶」的資料，絕不靠猜 ID。
預約會寫回原系統
在聊天裡成立的預約會寫進 Stella 的行程——而在供應商的 API 帶不動某個細節的地方，同步會說出它丟掉了什麼，而不是默默丟掉。
刻意為之的拒絕
醫療診療紀錄絕不讀取、也絕不顯示；供應商自己的生命週期標籤絕不覆寫；也不會假裝有完整的雙向鏡像——這些邊界都是寫下來的設計決定。
Estesoft Stella——完整頁面 · 用的是別套 CRM？這個接口在設計上就不綁供應商—— 告訴我們您用哪一套。而當您準備好要完全離開舊系統時，請往下看： 移轉引擎 ——會把您的歷史紀錄一起搬進來。
行銷與供應商
自己帶供應商來——這是我們的基本主張
Push：您自己的 OneSignal
訪客的網頁推播跑在您自己網域上、您自己的推播應用程式裡——因為網頁推播本來就是這樣運作的，裝作不是這樣，第一天就會壞。
廣告與合規
對話、廣告平台與主管機關之間的底層機制
Meta Conversions API
一筆贏下的交易，會回報給當初開啟這段對話的那則廣告——以購買事件的形式，並依管道做正確的身分比對——外加來自 CRM 漏斗的名單品質訊號。您的資料集、您的 token，預設關閉；事件離開之前要過四道關卡（包含同意），還有一面健康度面板，列出送出了什麼、拒絕了什麼以及原因。
完整頁面這一段的誠實守則
廣告和合規類的整合，一律只在同意關卡之後才會觸發，每一則被拒絕的事件都連原因一起記下。如果一個號碼沒辦法有把握地比對，就不會用猜的——認錯身分，花掉的是另一個人的隱私。
移轉
離開舊的 CRM。歷史紀錄留著。
一台真正的移轉引擎
支援的來源系統：聯絡人、預約歷史、報價、銷售訂單、應收帳款和備註，都經由一台可排隊、可續跑的引擎匯入——由我們的團隊陪著跑，因為換 CRM 這件事該有人操作，不是按一顆按鈕。
跳過的項目會指名回報
這台引擎拒絕憑空造值——缺幣別或缺日期的紀錄會被跳過並計數，所以「移轉完成」絕不會藏著還住在舊系統裡的資料。
歸屬權最後才翻轉
資料的歸屬權是在匯入自己證明過之後，作為最後一步才移轉——在您決定改變之前，舊系統仍然是權威來源。
一份 OpenAPI 合約
整個平台由單一份 OpenAPI 3 文件定義——我們的網頁後台和行動 App 也是從同一份合約產生型別的。沒有影子端點，文件也不會和實作分岔。
有範圍限制的 Commerce API 金鑰
由租戶自行核發、權限範圍明確的金鑰——商品目錄讀取、訂單讀取、訂單寫入——讓您自己的商店前台或 App 跑在我們的商品目錄與訂單引擎上。
出站：由 Flows 呼叫您
REST 步驟會在您於畫布上畫定的那個時間點呼叫您的系統。那種「訂閱全部」的通用 Webhook 事件流還沒做——寫在這裡，不必等業務電話裡才發現。