ConnectWiz 연동
쓰시는 도구를 연결하고, 실제로 하는 일 그대로 설명합니다.
연동 페이지는 보통 로고를 늘어놓습니다. 이 페이지는 동작을 늘어놓습니다. 무엇이 동기화되는지, 어느 방향으로 가는지, 누구 소유인지, 솔직한 경계는 어디인지. “X와 연동됩니다”는 스티커가 아니라 깊이에 관한 주장이기 때문입니다.
Commerce
WooCommerce와 WordPress
WooCommerce — 양방향, 통제된 동기화
클릭 한 번으로 연결하고, 상품을 깊이 가져오고, 실제로 되씁니다. 직접 고르는 필드 단위 소유권, 작업별 예행 모드, 눈에 보이는 충돌 원장까지 함께합니다. 전체 내용은 Commerce 페이지.
전체 페이지Google과 Meta 쇼핑 피드
Google 스키마를 따르는 토큰 기반 상품 피드가 광고 카탈로그를 계속 맞춰 줍니다. Meta Commerce Manager도 같은 피드를 읽습니다. 중간에 앱 심사도, 수동 재업로드도 없습니다.
Shopify 준비 중
바탕은 이미 깔려 있습니다. Shopify 고객 신원은 벌써 연락처로 묶이고, 지금도 Shopify 스토어는 API와 Webhook으로 연결됩니다. WooCommerce 수준의 네이티브 양방향 동기화는 로드맵에 있고, 이 배지는 그것이 출시될 때 바뀝니다. 그전에는 아닙니다.
전체 페이지지원과 티켓
Zendesk — 이전 중인 팀을 위한 브리지
Push: 티켓 내보내기
ConnectWiz 티켓 대화가 Zendesk 티켓을 만들고 답장을 코멘트로 미러링합니다. 아직 Zendesk에서 일하는 팀도 따로 묻지 않고 진행 상황을 봅니다.
전체 페이지Pull: 상담원 답장 가져오기
Zendesk 트리거가 상담원 코멘트를 ConnectWiz 스레드로 되돌려 보냅니다. 공유 시크릿으로 보호하고, 루프 가드가 있어 두 시스템이 코멘트를 영원히 주고받는 일이 없습니다.
솔직한 적용 범위
티켓 브리지입니다. 생성과 답장, 양방향을 따로 켜고 끕니다. Zendesk 도움말 센터나 매크로, SLA를 가져오는 도구가 아닙니다. 팀은 이것으로 천천히 옮겨 간 다음 꺼 버립니다.
CRM
Estesoft Stella — 대화에서 바로 보이는 자사 CRM
제공사에 얽매이지 않는 CRM 포트의 첫 번째 제공사입니다. Stella를 쓰는 병원은 CRM을 그대로 둔 채, 그 CRM을 실제로 아는 대화 계층을 얻습니다.
실시간 맥락을, 본인 확인과 함께
Stella의 예약, 견적, 잔액, 메모, 문서가 대화 화면에 드러납니다. AI도 딱 이 고객의 것만 읽고, ID를 찍어 맞히는 일은 없습니다.
예약은 원래 시스템에 기록됩니다
채팅에서 잡은 예약은 Stella 다이어리에 들어갑니다. 공급사 API가 담지 못하는 항목이 있으면 동기화가 무엇을 빠뜨렸는지 말해 줍니다. 조용히 버리지 않습니다.
일부러 거절합니다
의료 진료 기록은 읽지도 보여 주지도 않고, 공급사 자체의 생애주기 라벨은 덮어쓰지 않으며, 완전한 양방향 미러를 하는 척하지도 않습니다. 이 경계는 문서로 남긴 설계 결정입니다.
Estesoft Stella — 전체 페이지 · 다른 CRM을 쓰고 계신가요? 이 포트는 설계부터 제공사에 얽매이지 않습니다 — 쓰시는 것을 알려 주세요. 그리고 기존 시스템을 완전히 떠날 준비가 되면, 아래의 마이그레이션 엔진 쪽에서 히스토리를 그대로 옮겨 옵니다.
마케팅과 제공사
제공사는 직접 가져오세요 — 이 집의 철학입니다
AI: 자사 키, 제공사 5곳
Wiz는 AI 제공사 다섯 곳과 수십 개 모델에서 자사 제공사 키로 돌아갑니다. 토큰에 마진을 붙이지 않고, 용도마다 모델을 고르며, 어느 업체든 떠날 자유가 있습니다. 전체 내용은 AI 페이지.
Push: 자사 OneSignal
방문자 웹 푸시는 자사 도메인의 자사 푸시 앱을 통해 나갑니다. 웹 푸시가 실제로 그렇게 동작하기 때문이고, 아닌 척하면 첫날에 깨집니다.
광고와 규제 대응
대화와 광고 플랫폼, 규제 기관 사이의 내부 구조
Meta Conversions API
성사된 거래는 그 채팅을 시작하게 한 광고로 되돌아가 보고됩니다. 채널마다 제대로 신원을 매칭한 구매 이벤트로 보내고, 자사 CRM 퍼널에서 나온 리드 품질 신호도 함께 보냅니다. 데이터셋도 토큰도 고객사 것이고 기본값은 꺼짐입니다. 이벤트가 나가기 전에 관문 네 개(수신 동의 포함)를 지나며, 무엇이 나갔고 무엇이 왜 거절됐는지 상태 패널에서 볼 수 있습니다.
전체 페이지이 섹션의 정직 규칙
광고와 규제 대응 연동은 오직 수신 동의 관문 뒤에서만 작동하고, 거절된 이벤트는 모두 이유와 함께 기록됩니다. 번호를 확신을 갖고 매칭할 수 없으면 추측하지 않습니다. 잘못된 신원은 남의 프라이버시를 대가로 치르기 때문입니다.
마이그레이션
쓰던 CRM은 떠나고, 히스토리는 지키세요.
진짜 마이그레이션 엔진
지원되는 원본 시스템이라면 연락처, 예약 이력, 견적, 판매 주문, 미수금, 메모를 대기열에 올려 이어서 돌릴 수 있는 엔진으로 가져옵니다. 저희 팀과 함께 돌립니다. CRM을 갈아타는 일에는 버튼이 아니라 운영자가 필요하기 때문입니다.
건너뛴 것은 이름으로 보고
엔진은 값을 지어내지 않습니다. 통화나 날짜가 빠진 레코드는 건너뛰고 세어 둡니다. 그래서 “마이그레이션 완료”가 아직 옛 시스템에 남아 있는 레코드를 감추는 일이 없습니다.
소유권은 마지막에 넘어갑니다
데이터 소유권은 가져오기가 스스로를 증명한 뒤 마지막 단계에서 넘어갑니다. 고객사가 달리 결정하기 전까지는 옛 시스템이 계속 기준입니다.
OpenAPI 계약 하나
플랫폼 전체가 OpenAPI 3 문서 하나에 규정돼 있습니다. 저희 웹 패널과 모바일 앱이 타입을 생성해 쓰는 바로 그 계약입니다. 숨은 엔드포인트도, 문서와 실제가 어긋나는 일도 없습니다.
범위가 지정된 Commerce API 키
테넌트가 발급하는 키에 카탈로그 읽기, 주문 읽기, 주문 쓰기 같은 범위를 명시합니다. 이 키로 저희 카탈로그·주문 엔진 위에 자사 스토어프런트나 앱을 올릴 수 있습니다.
수신 Webhook 보호
외부 시스템은 무엇이든 자동화를 시작할 수 있습니다. 각 플로우 Webhook 트리거는 자체 URL과 자체 시크릿, HMAC 검증, 재전송 방지를 갖습니다. 그리고 페이로드는 명령이 아니라 언제나 데이터로만 다룹니다.
발신: 플로우가 고객사를 호출합니다
REST 스텝이 캔버스에 그린 바로 그 순간에 고객사 시스템을 호출합니다. 전부 구독하는 범용 Webhook 피드는 아직 만들지 않았습니다. 영업 상담에서 뒤늦게 알게 되지 않도록 여기에 적어 둡니다.