워크플로우
매일 퇴근 전, 데스크 직원이 내일 예약 있는 고객들에게 리마인드 카카오톡을 보냅니다. 5명이면 5분, 20명이면 20분. 매일 반복되는 일입니다.
이 업무를 시스템이 대신 하게 만드는 것이 워크플로우입니다.
워크플로우란
워크플로우는 고객, 예약, 채팅 등의 이벤트를 감지해 액션을 실행하는 자동화 기능입니다. 사람이 "데이터를 보고 → 기준에 따라 → 행동한다"는 과정을 시스템이 대신합니다.
병원 업무를 시스템 형태로 바꿔보면 모두 같은 구조입니다.
- 예약 날짜를 보고, 내일이면, 리마인드 카톡을 보낸다
- 시술 기록을 보고, 오늘 완료됐으면, 사후 안내 문자를 보낸다
- 고객 이력을 보고, 3개월 이상 미방문이면, 안부 연락을 한다
구성 요소
워크플로우는 "언제, 어떤 조건에서, 무엇을 할지"를 정의합니다.
| 구성 요소 | 역할 |
|---|---|
| 워크플로우 | 전체 자동화 규칙을 하나로 묶는 단위 |
| 트리거 | 언제 실행할지: 감시 대상(고객/예약/채팅)과 이벤트(생성/수정) |
| 필터 조건 | 어떤 경우에 실행할지: changed_to, eq 등 조건 연산자 |
| 스텝 | 무엇을 할지: send_message, http_request, update_field, sleep |
| 템플릿 메시지 | 메시지 발송 시 어떤 내용을 보낼지: 변수(#{이름}, #{날짜}) 포함 |
워크플로우 없이 템플릿만 있으면 수동 발송만 가능합니다. 템플릿 없이 워크플로우만 있으면 보낼 메시지가 없습니다.
트리거
감시할 대상과 이벤트를 설정합니다.
| 대상 | 이벤트 |
|---|---|
| 고객 | 생성, 수정 |
| 예약 | 생성, 수정 |
| 채팅 세션 | 생성, 수정 |
"생성 시(insert)" 트리거는 CRM 동기화로 유입된 데이터에도 반응합니다. 이미 확인된 예약에 중복 메시지가 발송될 수 있으므로 "수정 시(update)" + changed_to 필터 조합이 더 안전합니다.
필터 조건
트리거가 발동될 때 추가로 어떤 경우에만 실행할지를 좁힙니다.
지원 연산자: eq, neq, in, not_in, changed, changed_to, changed_from, is_null, is_not_null, contains
조건 그룹: all (모두 충족) 또는 any (하나 이상 충족)
필터 조건이 비어 있으면 모든 변경에 반응합니다. 의도치 않은 대량 발송의 가장 흔한 원인입니다.
스텝
조건이 충족되면 실행할 작업을 순서대로 정의합니다. 하나가 실패하면 이후 스텝은 실행되지 않습니다.
| 타입 | 설명 |
|---|---|
send_message | 알림톡 / 친구톡 / RCS / SMS 발송 |
http_request | 외부 API 호출 (웹훅, 슬랙 등) |
update_field | 데이터베이스 필드 수정 |
sleep | 대기 (최대 30초) |
실행 흐름 예시
예약 확정 알림이 어떻게 자동으로 발송되는지 따라가 보겠습니다.
활성화 전 체크리스트
워크플로우를 활성화하기 전에 확인해야 할 사항입니다.
- 필터 조건: 의도한 이벤트에만 반응하는지 (필터 없으면 모든 변경에 반응)
- 메시지 유형: 정보성/광고성을 올바르게 구분했는지
- 변수 매핑: 템플릿 변수(
#{이름},#{날짜})가 올바르게 연결되었는지 - 기존 EMR/CRM 연동: "생성 시" 트리거라면 기존 EMR/CRM 동기화 데이터에도 반응한다는 점을 인지했는지
- 테스트: 테스트 예약/고객으로 실제 메시지 수신을 확인했는지
다음 단계
워크플로우가 메시지를 발송할 때 어떤 내용을 담을지 결정하는 것이 메시지 템플릿입니다. 정보성과 광고성 메시지의 분류 기준을 다음에서 살펴봅니다.