ConnectWiz + Estesoft Stella
已上線的整合Stella 仍然是您的 CRM。對話終於認得它。
我們那個不綁供應商的 CRM 介面，第一個接上的就是它：每一段對話裡都帶著來自 Estesoft Stella 的即時客戶資訊，預約也會寫回 Stella 的日程——另外還有一份白紙黑字、刻意為之的拒絕清單，說明一個溝通產品永遠不該碰哪些東西。
CRM
它到底能做什麼
即時上下文，綁定身分
這位客戶的預約、報價、未結餘額、備註和文件，會直接浮上對話——AI 也讀得到，但只限這一位客戶，身分是從對話本身解析出來的，絕不靠猜一組 ID。
預約會寫回原系統
在聊天裡成立的預約，會落進 Stella 的日程——遇到供應商 API 承載不了的細節，同步會把漏掉的部分講出來，而不是安靜地丟掉。
AI 只讀，絕不寫
整個 CRM 介面的長期規則：讀取綁定身分，寫入留給真人——一個會把餘額看錯的 AI，只是另一個會幫錯病患掛號的 AI 的廉價預演。
要不要移轉，您說了算
一套走佇列、可續跑的引擎，把預約、報價、銷售、應收帳款和備註匯進 ConnectWiz——跳過的資料會逐筆具名回報，資料歸屬權則等到最後一步才切換。
收款與訂單會寫回去
在 ConnectWiz 裡記一筆收款或建一張訂單，可以同步寫進 Stella——這要由擁有者明確決定才會開啟，而且和其他寫入一樣，要過同樣的四道關卡和預演模式。
增量同步，不是鏡像
變更輪詢的用途是補抓漏掉的事件——不是替診所的帳本留第二份副本。這條界線一鬆，快取就變成資料庫，所以我們把它寫下來。
技術細節
寫入路徑：四道關卡，加一次預演
預設關閉，而且逐項關閉
每一種寫入出廠都是關的，而且七種操作——備註、預約、取消、客戶、報價、訂單、收款——各有各的開關。這裡的安全是一種缺席：只要有一道關卡沒過，根本就不存在可以呼叫的寫入物件。
歸屬權大過開關
逐項開關之上，還壓著資料歸屬權：只要某個領域的資料歸您的工作區所有，不論開關怎麼設，都不會往 Stella 寫出去。關卡的順序是固定的，也寫在文件裡。
預演走的是正式那條路
乾跑模式會組出正式寫入會送出的那一份 payload，只在傳輸那一步停下來——走另一條程式路徑的預演什麼都證明不了，所以我們沒做那種東西。
寫入會自己驗自己
每次寫入之後，整合都會把剛建立的東西讀回來比對。對不上就跳一則警告給真人看——絕不自動修正，因為供應商的 API 沒有冪等鍵，自動修正並不安全。
移轉的順序有講究
預約先匯——這是刻意的，因為日程是唯一能在整個租戶範圍內把人找齊的地方。每一筆被跳過的資料都會具名計數：不在時間範圍、格式無法辨識、對不到聯絡人。
AI 的讀取上了三道鎖
AI 的 CRM 工具只會列出您的工作區真正擁有的動作，呼叫當下再驗一次，客戶身分則從對話本身解析出來——幻想出來的選項或猜出來的 ID，都活不到傳輸那一步。
設定方式
串接方式
串接 Stella
填入 Stella 的憑證；連接器會先打正式 API 驗過，才會存下任何東西。
帶著資訊做事
對話上會顯示客戶的 CRM 卡片；客服人員和 AI 都照事實回答，不是憑印象。
要移轉，隨時可以
跑一次輔助移轉把完整歷史搬進來——在您切換歸屬權之前，舊系統仍然是權威來源。
安全與保證
無聊但管用的保證
健康資料：絕不讀取
依 KVKK，診療紀錄屬於特種資料。把它讀進客服畫面，等於把處理這些資料的人從診所的醫師擴大到整個團隊——所以那些端點存在，而我們白紙黑字拒絕使用。
沒有看不見的手
我們不會去結掉診所的待辦、不會改它的分眾、不會動它的會計帳本——每一項都是寫在文件裡的拒絕，因為從一個聊天視窗去自動化別人的業務流程，是這類產品代價最高的一種錯誤。
token 不會出現在網址裡
供應商提供了一個檢查 token 的端點，它把憑證放在網址裡——那是日誌和代理伺服器看得到的地方。我們從不呼叫它。憑證怎麼處理，是逐個端點決定的。
刪除：不提供
供應商用來刪除客戶、潛在客戶、帳單和報價的端點，我們一律不用——軟刪除還是硬刪除沒驗證過，而且「刪掉一筆病患資料」不出現在任何我們願意承擔的使用情境裡。
不加修飾的細則
邊界，寫清楚
刻意為之的拒絕
診療紀錄絕不讀取、也絕不顯示，供應商的生命週期標籤絕不覆寫，也不會假裝做得到完整的雙向鏡像——每一項拒絕都是寫在文件裡的設計決定，不是還沒補上的缺口。
其他 CRM
這個介面在設計上就不綁供應商——Stella 是第一個接上的，不是最後一個。您用的是別套？告訴我們，這會影響排程順序。