안과 병원 CRM 온보딩 사례 | 해외 환자 국가별 스프레드시트에서 문의·상담·수술 파이프라인과 SEO 결합까지

병원 CRM 이야기를 시작하기 전에 하나만 여쭤보겠습니다.
이번 달에 들어온 문의 중, 아직 답장을 못 한 게 몇 건인가요?

이 질문에 바로 답할 수 있는 병·의원은 생각보다 적습니다.
상담 주기가 긴 병원은 B2C라도 문의·상담·예약·내원을 단계별로 관리해야 데이터가 남습니다.

이 글은 해외 환자 비중이 높은 한 안과의 허브스팟 온보딩 기록을 바탕으로 재구성했습니다.
도입 전 이 병원의 고객 정보는 언어권별 스프레드시트로 나뉘어 있었습니다.
상담은 여러 메신저에 흩어져 있었고, 유입 경로는 상담할 때 구두로 묻는 데 의존했죠.

그래서 해당 병원 온보딩의 주 목표는 흩어진 기록을 한 사람 단위로 다시 묶는 일이었습니다.
이번 글에서는 흩어진 기록을 어떻게 묶을 수 있는지,
실제 허브스팟 세팅 화면과 함께 따라가보도록 하겠습니다.

본문에 나오는 ‘경성아이안과’는 실제 병원이 아닌 가칭이고,
세팅 화면도 전부 가상 데이터로 만든 샌드박스 계정입니다.

또한 글에 나온 세팅은 고객사의 설정과 똑같지는 않게 일부 변형되어 있지만,
실제 설계 흐름은 비슷하기에 도움이 되실 것입니다.

해외 환자를 받는 병원의 고객관리가 어려운 이유

병원은 B2C 영업 구조입니다.
하지만, 해외 환자의 구매 과정은 B2B에 가깝습니다.

해외 환자는 주로 검색으로 병원을 알게 되고, 정보를 비교하고,
메신저로 묻고, 일정을 조율하고, 입국해서 내원합니다.
결정까지 몇 주에서 몇 달이 걸리는 ‘고관여·장기 비교형 의사결정’에 해당하죠.

이렇게 구매 여정이 길면 고객 한 사람의 이력이 여러 곳에 흩어지고,
그 빈자리를 결국 담당자의 기억으로 메우게 됩니다.
이는 다른 병원의 사례도 마찬가지입니다.

병원 CRM 도입을 검토하는 곳에서 주로 나타나는 문제는 대체로 네 가지입니다.

• 문의 누락 : 폼·메신저·이메일이 각각 다른 곳에 남아, 누가 답했는지 서로 확인해봐야 압니다.
• 이력 단절 : 같은 사람이 두 번째 문의를 할 때 첫 상담에서 무슨 이야기를 했는지 찾기 어렵습니다. 맥락이 연결되지 않습니다.
• 예약 관리의 편차 : 안내 시점이 담당자마다 달라, 어떤 환자는 예약 관리가 잘 되고 어떤 환자는 관리가 잘 되지 않습니다.
• 성과 불투명 : 어떤 채널에서 실제 내원으로 이어졌는지 수치로 확인하지 못하고, 감으로 판단하게 됩니다.

이와 같은 문제는 모두 환자·상담·예약·내원 이력이
한 데이터베이스에 모여 있지 않기 때문에 발생합니다.
이것이 바로 병원 CRM이 필요한 이유이기도 합니다.

 

도입 전 상태 : 언어권별로 나뉜 스프레드시트와 메신저

병원 CRM 온보딩의 첫 시간에는 바로 기능 소개로 들어가기보다,
현재의 프로세스를 전체적으로 확인하는 시간이 필요합니다.

고객사의 프로세스를 기준으로 내용을 정리한 표는 아래와 같습니다.

이렇게 전체 내용을 정리해보니 문제가 분명해졌습니다.
데이터가 없는 게 아니라, 한 화면에 모이지 않는 것이 문제였죠.

[화면 1] 도입 전 관리 방식을 재현한 스프레드시트 : 영어권·중국어권·일본어권으로 시트가 나뉘어 있고, 같은 항목인데도 열 이름이 ‘이름/성함’, ‘예약일/방문 예정일’처럼 제각각이다. 가상 데이터로 재현한 화면.

[화면 2] 허브스팟으로 옮긴 뒤의 연락처 목록 : 언어권으로 나뉘어 있던 사람들이 하나의 목록에 모였다. 여기서부터 검색·필터·리포트가 같은 기준으로 동작한다.

 

설계 ① 회사(Company)를 쓰지 않기로 한 결정

허브스팟의 기본 구조는 회사(Company)–연락처(Contact)–거래(Deal)입니다.
B2B에서는 이 구조가 자연스럽지만, 개인 환자가 주 고객인
병원 CRM에서는 회사 속성을 계속 비워두게 됩니다.

이렇게 화면에 빈 칸이 많으면 입력할 의욕이 떨어지게 됩니다.
따라서 회사 객체를 운영에서 빼고, ‘연락처(사람)’와 ‘거래(진행 건)’ 두 가지로 단순화했습니다.

허브스팟에서 기본 객체를 완전히 삭제할 수는 없습니다.
다만 레코드 레이아웃과 메뉴에서 감출 수 있기에 실무자가 보는 화면에서는 사라지는 것과
마찬가지가 됩니다. 병·의원이 필요로 하는 수준은 대체로 이 범위에서 해결되죠.

대신, 연락처 한 명에 거래가 여러 건 붙는 구조를 썼습니다.
그러면 재방문, 추가 상담, 다른 진료로 이어진 거래,
해당 환자가 소개해준 환자의 거래까지 모두 같은 사람의 이력 아래에 쌓입니다.

예를 들어, 소개로 온 환자는 거래 하나에 환자와 소개인까지 두 명의 연락처를 연결합니다.
그리고 연결 라벨로 ‘환자’와 ‘소개인’을 구분하는 방식입니다.

[화면 3] 연락처 레코드 : 왼쪽에 응대 언어·유입 경로·상담 기본 정보, 가운데에 활동 기록, 오른쪽에 연결된 거래가 놓인다. 같은 사람의 문의 두 건이 한 화면에서 이어진다.

[화면 4] 소개로 들어온 거래 : 거래 하나에 연락처 두 명을 연결하고, 오른쪽 카드에 ‘환자’와 ‘소개인’ 라벨을 달아 역할을 구분했다.

[화면 5] 데이터 모델 빌더의 연결 레이블 설정 : 거래–연락처 연결에 ‘환자’와 ‘소개인’ 두 레이블을 만들어 두면, 레코드마다 같은 기준으로 붙일 수 있다.

이처럼, 허브스팟의 기본 구조를 항상 그대로 쓸 필요는 없습니다.
그 중에서도 ‘실제 우리 업무에 필요한 세팅’만 남기는 것이 더 중요합니다.

 

설계 ② 국적이 아니라 언어로 고객을 나눈 이유

앞에서 소개드렸듯이, 이 병원은 해외 환자 비중이 높습니다.
따라서 처음에는 ‘국적’을 기준으로 고객을 나누자는 의견이 나왔습니다.

하지만, 실무 기준으로 보니 국적은 잘 맞지 않았습니다.
같은 국가 안에서도 응대하는 언어가 다르고,
국적과 상관없이 영어로 응대하는 경우도 있었기 때문입니다.

결국 담당자 배정과 안내 메일 발송을 좌우하는 실제 기준은 ‘어떤 언어로 응대하는가’였습니다.
그래서 언어를 연락처의 입력 속성(드롭다운)으로 두고,
국적은 선택 입력하게 하여 참고 정보로 두었습니다.

기준을 언어로 통일하자, 자동 응대 메일 발송과 담당자 배정의 조건이
언어를 기준으로 묶였습니다.

[화면 6] ‘응대 언어’ 속성을 만드는 화면 : 연락처 개체 아래 ‘연락처 정보’ 그룹에 두어, 담당자가 상담 중 바로 보고 채울 수 있는 자리에 놓았다.

[화면 7] 필드 유형 선택 : 자유 입력이 아니라 드롭다운으로 지정했다. 표기가 하나로 고정되어야 자동화 분기와 리포트 집계가 어긋나지 않는다.

[화면 8] 드롭다운 옵션 : 영어·중국어·일본어 세 가지만 두었다. 옵션을 늘리는 대신 실제로 응대 가능한 언어만 남겼다.

이처럼, 조건 분기의 속성을 무엇으로 잡느냐가 자동화 전체 분기의 기준이 됩니다.
그러니 자동화를 설정하기에 앞서 속성 설계가 먼저 이루어져야 합니다.

 

설계 ③ 수술과 외래, 두 개의 파이프라인

진행 중인 거래는 크게 두 가지로 나뉩니다. 바로 수술과 외래입니다.
수술 건은 상담이 길고 일정 조율이 필요했고, 외래 건은 훨씬 짧게 끝났습니다.

소요 기간이 다른 두 흐름을 한 파이프라인에 넣으면 단계별로 머무는 시간이 섞입니다.
그래서 파이프라인을 둘로 나누되, 단계 구성은 동일하게 유지했습니다.
단계 이름이 같으면 두 파이프라인을 합쳐서 볼 수도, 따로 볼 수도 있기 때문입니다.

[화면 9] 파이프라인 단계 설정 : 기본 단계 이름을 병원 업무 순서로 바꾸고 단계별 확률을 다시 잡았다. 오른쪽의 ‘논리 규칙’ 표시가 그 단계에 필수값이 걸려 있다는 뜻이다.

[화면 10] 수술 파이프라인 보드 : 상담 접수부터 내원 완료까지 진행 건이 단계별로 놓인다. 환자 이름과 상담 종류가 카드 제목에 들어간다.

[화면 11] 외래 파이프라인 보드 : 단계 이름은 수술과 똑같고 건만 다르다. 구성이 같아서 두 파이프라인을 합쳐 볼 수도, 따로 볼 수도 있다.

 

단계를 넘기기 전에 받는 정보

거래의 단계를 옮기는 일 자체는 스프레드시트로도 할 수 있습니다.
허브스팟이 다른 점은 단계마다 ‘이건 채우고 넘어가라’는 규칙을 걸 수 있다는 점이죠.

보통 급해서 그냥 넘길 때, 데이터에 공백이 생긴 채로 단계가 넘어가게 됩니다.
그러니 해당 단계에서 확정되는 값은 필수 입력값으로 지정합니다.

• 담당자 배정 단계 → 담당자
• 예약 완료 단계 → 예약 확정 날짜
• 사후 안내 완료 단계 → 진행이 끝난 날짜

만약, 앞 단계에서 아직 알 수 없는 값을 필수 입력으로 걸면 담당자는 아무 값이나 넣게 됩니다.
따라서 ‘이 단계에서 확정되는 값만 받게 하는 것’이 필수 입력값 설계의 기준입니다.

[화면 12] 단계별 필수값 설정 : 거래 단계가 ‘예약 완료’가 되면 예약 확정일 칸이 나타나고, 별표가 붙어 필수로 바뀐다. 담당자가 잊어도 화면이 먼저 물어본다.

 

같은 값을 연락처와 거래 양쪽에 두는 문제

여기서 예상하지 못한 벽을 만났습니다.
단계별 필수값 규칙은 ‘거래’ 레코드 화면에서 작동한다는 것입니다.
그러면 조건으로 걸 수 있는 속성도 ‘거래 속성’뿐입니다.

그런데 상담에서 받는 정보는 대부분 사람에게 붙는 값입니다.
따라서 응대 언어나 상담 내용은 ‘연락처’에 저장되는데,
이 값은 거래 단계의 필수 조건으로 고를 수 없습니다.

예를 들어, ‘상담 중’ 단계로 넘길 때 ‘응대 언어’를 반드시 채우게 하고 싶어도,
응대 언어가 연락처 속성이면 필수값 규칙을 설정할 때 아예 목록에 나타나지 않는다는 거죠.

그래서 연락처 속성을 단계를 넘기는 조건으로 쓰기 위해,
같은 값을 ‘거래’에도 하나 더 두기로 했습니다.
해결 방법은 두 가지였습니다.

1. 연락처 속성을 복제해서 같은 이름의 거래 속성을 만든다 : 드롭다운의 옵션 표기가 한 글자라도 다르면 값이 옮겨지지 않기 때문에, 새로 속성을 만들지 않고 복제합니다.
2. 두 속성을 양방향으로 동기화하는 워크플로우를 걸어 둔다 : 거래가 상담 단계에 들어오면 연결된 연락처 속성의 값을 가져옵니다. 한 쪽에서 값이 수정되면 반대쪽에도 자동 반영됩니다.
   
   

[화면 13] 연락처 → 거래 값 동기화 워크플로우 : 연락처의 상담 기본 정보와 응대 언어가 바뀌면, 연결된 모든 거래의 같은 속성에 그대로 반영된다. 반대 방향도 짝으로 만들어 두었다.

이렇게 하면 같은 값을 입력하는 칸이 두 개로 늘어난 것처럼 보이지만,
실제로 담당자는 어느 쪽에서 입력하든 값을 한 번만 채우면 됩니다.

이처럼 자동으로 값을 맞춰 두면 담당자가 추가로 신경 쓸 일은 없어집니다.
두 속성은 중복처럼 보이지만, 사람에게 붙는 값과 건에 붙는 값은
쓰이는 자리만 다르기 때문입니다.

이렇게 동기화된 연락처의 값은 환자 이력을 볼 때,
거래의 값은 단계를 넘기는 조건으로 각각 쓰입니다.

 

설계 ④ 예약 전 리마인드와 무응답 알림

자동화는 크게 두 종류로 나눴습니다.
환자에게 나가는 안내와 내부 담당자에게 가는 알림입니다.

안내 메일은 언어별로 내용을 나눠 두고, 연락처의 언어 값으로 분기시켰습니다.
같은 워크플로우 안에서 갈라지기 때문에 언어가 늘어나도 규칙을 새로 만들지 않아도 됩니다.

[화면 14] 접수 안내 메일의 언어 분기 : 응대 언어 값에 따라 영어·중국어·일본어로 갈라지고, 값이 없으면 아무 메일도 나가지 않고 종료된다. 규칙은 하나, 본문만 세 가지다.

[화면 15] 방문 리마인드의 등록 조건 : 예약 확정일이 채워진 거래만 워크플로우에 들어온다. 날짜가 없는 건이 섞이지 않게 입구에서 거른다.

[화면 16] 방문 리마인드 전체 구조 : 언어로 먼저 갈라지고, 각 줄이 ‘기다렸다 보내기’를 반복한다. 언어가 늘어나도 줄만 하나 더 붙이면 된다.

[화면 17] 리마인드 반복 구간 : 지연과 이메일이 번갈아 놓여 2주 전·1주 전·3일 전·전날 네 번의 안내가 나간다. 담당자 기억이 아니라 날짜가 기준이 된다.

 

‘24시간 안에 연락’을 추적 가능한 조건으로 바꾸기

내부 규칙 중에는 담당자가 배정되면 24시간 안에 연락한다는 규칙이 있었습니다.
이건 사람끼리는 통하는 규칙이지만, 시스템은 연락했다는 내용을 확인할 수 없습니다.
메신저 대화는 CRM 밖에서 오가는 경우가 많기 때문입니다.

그래서 연락 여부 대신, ‘담당자 배정 단계에 머무른 시간’을 기준으로 바꿨습니다.
그러면 정해진 시간이 지나도 다음 단계로 넘어가지 않으면
담당자에게 알림이 가고, 휴진일은 조건에서 제외됩니다.

[화면 18] 지연 알림 워크플로우 : 하루를 기다린 뒤 아직 ‘담당자 배정’ 단계에 그대로 있는 건만 골라 담당자에게 알림을 보낸다. ‘연락했는가’가 아니라 ‘단계가 움직였는가’를 본다.

[화면 19] 휴진일 예외 설정 : 지정한 날짜에는 작업이 실행되지 않도록 일시 중지를 켰다. 휴진일에 알림이 울려 규칙이 무시되는 일을 막는다.

이처럼, 설계 단계에서는 고객사의 요구 사항을 그대로 옮기기보다
시스템이 안정적으로 운영될 수 있는 방식으로 세팅하는 것이 중요합니다.

설계 ⑤ 문의가 들어오기 전 : SEO 교육을 먼저 한 이유

이 온보딩에는 순서상 특이한 점이 하나 있습니다.
CRM 구조를 다루기 전에 검색 유입(SEO) 교육을 먼저 진행한 것입니다.

이유는 단순합니다. 문의가 들어오지 않으면 병원 CRM에 쌓일 데이터 자체가 없기 때문입니다.
파이프라인을 아무리 잘 만들어도, 상담 접수가 들어오지 않으면 소용 없어집니다.

그래서 첫 회차의 주제는 상위 노출이 아니라
‘검색이 매출에 얼마나 기여하는지’로 잡았습니다.

허브스팟을 활용하면 검색의 매출 기여도를 확인할 수 있습니다.
검색으로 들어온 사람이 어떤 페이지를 보고 폼을 냈는지가 연락처에 남고,
그 데이터가 채널별 기여도 리포트에도 적용되기 때문입니다.

이렇게 콘텐츠로 사람을 데려오고 CRM으로 관계를 이어가는 흐름이 인바운드 마케팅입니다.
2026년, 허브스팟은 이 개념을 AI 시대에 맞게 루프 마케팅(Loop Marketing)으로 확장했죠.

허브스팟에서 블로그와 랜딩 페이지를 운영하는 방법은 따로 정리해 두었습니다.

[화면 20] 연락처의 활동 이력 : 이 사람이 언제 어떤 글을 읽었는지가 시간순으로 쌓인다. 유입 경로를 상담 중에 구두로 묻지 않아도 된다. 이 화면만 추적 코드가 설치된 실제 계정에서 가져왔고, 개인정보는 가렸습니다.

 

병원 CRM에서는 어떤 정보로 리포트를 만들까?

리포트에 너무 많은 정보를 담으려고 욕심내면 아무도 보지 않게 됩니다.
그래서 대시보드를 두 개로 나눴습니다.

• 실무용 : 담당자가 오늘 봐야 할 것. 담당자별 진행 건수, 예약이 임박한 건, 응답이 늦은 건.
• 보고용 : 월 단위 변화. 예약 확정 날짜 기준 월별 추이, 수술·외래 비중, 유입 경로 분포.

기준 날짜를 예약 확정일로 잡은 데는 이유가 있습니다.
문의가 들어온 날이 아니라 실제로 일정이 잡힌 날을 봐야,
마케팅을 바꾼 시점의 전후 비교가 가능해지기 때문입니다.

[화면 21] 실무용 대시보드 : 단계별 진행 건수와 담당자별 진행 건수를 나란히 두었다. 어디에 건이 몰려 있는지, 누가 많이 쥐고 있는지를 오늘 기준으로 본다.

[화면 22] 보고용 대시보드 : 예약 확정일 기준 월별 추이와 수술·외래 비중을 한 화면에 모았다. 문의가 들어온 날이 아니라 일정이 잡힌 날을 기준으로 해야 전후 비교가 된다.

리포트 구성은 허브스팟 리포트·대시보드 활용법에서 실제 화면과 함께 다룹니다.

 

문의 한 건을 먼저 돌려 보기

설계가 끝난 뒤에 전체 환자를 한꺼번에 옮기는 대신,
테스트하기에 좋은 문의 한 건만 처음부터 끝까지 자동화를 돌려봤습니다.

상담 접수부터 사후 안내까지 한 사이클을 돌리자 빠진 게 드러났습니다.
폼 제출 시점에는 거래가 아직 없어서,
거래 속성을 조건으로 쓴 워크플로우가 걸리지 않는다는 점이었습니다.

이 오류를 고치고 나서는 담당자별로 한 명씩 테스트 건을 늘렸습니다.
값을 입력하는 습관이 붙기도 전에 모두 자동화해버리면
규칙만 남고, 정작 데이터는 비어 있게 되기 때문입니다.

이전에 워크플로우를 설계하는 순서와 테스트 방법을 소개할 때,
‘한 건부터’ 돌려보라고 한 것도 같은 이유에서입니다.

병원 CRM을 도입할 때 체크포인트 6가지

CRM을 도입하기 전에 미리 정리해 두면 좋은 6가지입니다.

1. 상담 단계 정의 : 실제로 쓰는 단계 이름과 순서를 확정합니다. 단계가 너무 많으면 보드가 한 눈에 들어오지 않습니다.
2. 담당자 배정 기준 : 언어인지, 진료 구분인지, 순번인지에 따라 자동화 규칙이 달라집니다.
3. 예약 안내 시점 : 며칠 전에 몇 번 보낼지 미리 정합니다. 규칙 없이 늘리면 안내가 잦아져 스팸처럼 느껴집니다.
4. 기존 시트 항목 통일 : 시트를 옮기기 전에 열 이름과 값 표기를 맞춥니다. 데이터 정리는 데이터 이전에서 시간이 가장 많이 드는 부분입니다.
5. 개인정보 동의 항목 : 수집 동의를 폼 항목에 포함하고, 권한 설계를 함께 잡습니다.
6. 마케팅 발송 대상 관리 : 안내를 받을 대상만 마케팅 컨택으로 분류해 과금 대상 수를 관리합니다.
   

경성솔루션의 허브스팟 온보딩은 요구사항 정의 → 프로세스 구체화 → 기능 가이드 → 설계·구축 → 사용자 교육 → 리포트·안착의 6단계로 진행되며, 평균 4~8주가 걸립니다.

비용은 1 Set(4회차·8시간)을 단위로 산정하고,
데이터 이전과 사내 교육은 이 범위 안에서 함께 진행합니다.

자주 묻는 질문(FAQ)

Q1. 전자차트(EMR)가 있는데 병원 CRM이 또 필요한가요?

역할이 다릅니다. 전자차트는 내원한 뒤의 진료 기록을 다루고,
병원 CRM은 문의부터 내원까지, 그리고 그 이후의 관계를 다룹니다.
내원 전에 이탈한 사람은 전자차트에 남지 않기에 CRM이 필요합니다.

Q2. 환자 개인정보를 CRM에 넣어도 되나요?

수집 동의와 권한 설계를 함께 잡는 것을 전제로 합니다.
폼에 수집 동의 항목을 넣고 사용자별 권한으로 볼 수 있는 범위를 나누며,
이 두 가지는 온보딩 안에서 함께 설계합니다.

Q3. 여러 언어로 안내 메일을 따로 만들어야 하나요?

메일 본문은 언어별로 만들되 규칙은 하나면 됩니다.
연락처의 언어 값으로 분기시키면 한 워크플로우 안에서 갈라집니다.

Q4. 메신저 상담 내용도 남길 수 있나요?

연동이 되는 채널은 받은 편지함에 연결해 대화를 연락처에 쌓을 수 있습니다.
다만 모든 메신저가 연동되지는 않으니, 연동이 어려운 채널은
담당자가 요약 메모를 남기는 방식으로 운영합니다.
어떤 채널이 연동되는지는 도입 전에 확인하는 편이 좋습니다.

Q5. 어떤 허브가 필요한가요?

폼과 이메일은 마케팅 허브, 파이프라인과 자동화는 세일즈 허브가 담당합니다.
단계별 필수값이나 워크플로우처럼 플랜에 따라 제공 범위가 달라지는 기능이 있으니,
도입 전에 허브스팟 공식 문서에서 현재 등급별 범위를 확인하시는 게 좋습니다.
무료 체험판으로 폼과 파이프라인을 먼저 만들어 본 뒤 정식 버전으로 넘어가셔도 됩니다.

병원 CRM을 처음 도입할 때 다양한 기능을 많이 적용할 필요는 없습니다.
파이프라인 하나와 리마인드 두 기능만 활용해도 문의 누락은 줄어듭니다.

우리 병원의 상담 흐름을 어떻게 옮길지 궁금하시거나,
허브스팟 온보딩을 고민하고 계시다면 편하게 문의해 주세요.

경성솔루션은 무조건 다 된다는 무모한 약속은 하지 않습니다.
정확한 진단을 바탕으로 ‘솔직한 제안’을,
남들에게도 똑같이 제공하는 일괄적인 설명이 아니라 우리 조직만의 정답을 찾아드립니다.

[ 1시간 무료 진단 신청하기 ]

[ 허브스팟 온보딩 알아보기 ]

함께 읽으면 좋은 글

---

► 글로벌 의료기기 제조사 허브스팟 온보딩 사례
► 허브스팟 온보딩 완벽 가이드 | 도입 첫 30일 로드맵과 체크리스트
► 허브스팟 CRM 데이터 구조 설계
► 허브스팟 도입 문