castomo 제품군 안에서
고객이 여덟 명의 고객이 아니게 되는 지점
이미 dash-b, castomo, clickSomo 또는 FABLS를 쓰고 계시다면 현대의 통합 문제를 겪어보셨을 겁니다: 모든 것이 모든 것과 연결되고, 같은 사람이 여덟 곳에서 조금씩 다르게 표기된 채 여덟 번 존재하게 되며, 각 여덟 곳은 자기가 유일한 권위라고 믿습니다.
흔한 해결책은 동기화 작업이지만, 그건 두 개의 거짓말을 일치시키는 것이 전부인 목적을 가진 기계입니다. 실행 중에 한쪽이 수정되기 전까지는 잘 작동하고, 그 순간 세 번째 거짓말과 지원 티켓이 생깁니다.
iKonekt는 제품군과 통합된 것이 아닙니다. 제품군 안에 있습니다. 같은 로그인, 같은 계정, 그 아래 같은 플랫폼 — 그래서 고객 기록을 제품 간에 조율할 필요가 없습니다. 하나뿐이니까요.
그 아래 castomAPI
제품군의 모든 제품이 돌아가는 플랫폼 계층입니다: 계정 하나, 지갑 하나, 인증·결제·청구·예약 서비스를 한 세트로 제공해요. 커넥터가 대작이 아니라 짧게 끝나는 이유가 바로 이것이에요.
clickSomo, 양방향
메시징 자동화는 그것이 잘하는 곳 — clickSomo에 그대로 있어요. 오가는 것은 대화와 결과뿐이라서, 시퀀스는 사람이 대화를 넘겨받았을 때를 알고, 판매자는 시퀀스가 이미 무엇을 말했는지 볼 수 있어요.
FABLS, 상단을 채우다
블로그와 소셜은 독자를 만들고, 독자는 문의를 만들고, 문의는 그 출처가 된 글과 함께 여기에 도착해요. 스프레드시트를 거치지 않고 루프가 닫혀요.
castomUI의 폼
castomUI가 생성한 사이트와 랜딩 페이지에는 여기로 바로 도착하는 폼이 실려 있어요 — 이메일로도, 직접 관리하는 웹훅으로도 아니에요. 페이지와 수신함은 같은 제품군에서 만들어졌어요.
dash-b, 지켜보다
같은 계정에서 읽어오는 대시보드라서, 벽에 붙은 숫자와 CRM 속 숫자가 서로 어긋날 수 없어요 — 의외로 드문 특성이에요.
castomo, 집
이미 갖고 계신 계정이에요. 제품군의 무엇이든 로그인해 보셨다면 이미 여기에도 로그인하신 거예요 — 두 번째 가입도, 잃어버릴 두 번째 비밀번호도 없어요.
"양방향"의 실제 의미
양방향이라는 말은 남용되었으니, 구체적인 버전을 말씀드릴게요. 이 제품군의 커넥터는 매일 밤의 내보내기가 아니에요. clickSomo가 시퀀스를 보내고 고객이 답장하면, 그 답장은 iKonekt 스레드에 남고, clickSomo는 발송을 멈춰야 한다는 것을 알아요 — 이제 사람이 대화 중이니까요. 판매자가 여기서 건을 마감하면, 관련 제품들이 한 번에, 순서대로 통지받고 그에 따라 움직일 수 있어요.
기능은 옮겨가지 않아요. clickSomo는 계속 메시징 제품이고, iKonekt는 계속 대화 제품이에요. 선을 넘는 것은 양쪽이 실제로 필요로 하는 작은 사실들뿐이고, 어느 쪽도 추측하지 않아도 되도록 믿을 수 있게 전달돼요.
구축 과정에서 얻은 인사이트: 통합에서 어려운 부분은 데이터를 전송하는 것이 아닙니다. 한 제품의 "연락처"가 다른 제품에서는 "잠재 고객"이고 세 번째 제품에서는 "고객"인 것처럼, 어떤 데이터가 무엇인지 합의하는 것입니다. 하나의 제품군이라는 것은 그러한 논의가 내부적으로 단 한 번만 이루어지며, 고객님의 문제가 되지 않음을 의미합니다.
계정 하나, 그리고 그 밖으로 나가는 길 하나
제품들에 걸쳐 하나의 계정을 쓰면, 누군가 자신의 데이터를 지우고 싶어 할 때 어떻게 되는지가 당연한 질문으로 떠오르죠. 이 제품군에서 삭제 요청은 메일함 규칙이 아니에요 — 무엇이든 보유한 제품들에 퍼져 나가고, 각자 자기 몫에 답해요. 폼 하나 만드는 것보다 훨씬 어려운 작업이고, 아무도 안 읽는 정책 문서가 아니라 여기서 언급할 가치가 있는 이유예요.
"그럼 이걸 다른 것들과 전부 동기화해야겠네요."
동기화할 것이 없어요.
제품군 전체에서 계정 하나, 그 아래 고객 기록 하나. 동기화 작업은 두 개의 거짓말을 일치시키는 것이 전부인 기계예요. 여기에는 대신 진실이 하나 있어요.
플랫폼 보기 →