미수금 연령 대시보드 및 자동 알림 시퀀스

이 대시보드가 해결하는 문제와 그 중요성

미수금(AR) 연령은 간단한 아이디어입니다: 송장이 얼마나 오래 미지급 상태인지 보여줍니다. 평평한 목록을 보는 대신, 기한(또는 송장 날짜) 이후 경과 일수에 따라 0–30일, 31–60일 등으로 묶어 보여 줍니다. 그 한 화면으로 매일 두 가지 질문에 빠르게 답합니다: 무엇이 위험해지고 있는가, 그리고 오늘 누가 조치가 필요한가.

대부분의 알림 시스템은 수동으로 남아 있을 때 실패합니다. 누군가는 목록을 확인하고, 보낼 내용을 결정하고, 고객 이메일을 복사하고, 전송 버튼을 눌러야 합니다. 바쁜 주에는 후속 조치가 빠지고, 한가한 주에는 지나치게 많이 보내거나 이미 회신한 사람을 잊게 됩니다. 결과는 톤과 타이밍의 불일치이고, 이는 성실한 고객을 귀찮게 만들 수 있습니다.

미수금 연령 대시보드는 가시성과 일관된 후속 조치를 결합해 이를 해결합니다:

• 가시성: 모든 사람이 동일한 사실을 봅니다 — 총 연체액, 서서히 밀리는 고객, 멈춘 송장 등.
• 일관된 후속 조치: 알림은 여러분의 정책에 맞는 예측 가능한 일정으로 발송됩니다, 기분에 따라 달라지지 않습니다.

좋은 설정은 팀이 중요한 몇 건에 집중하게 하고, “우리가 후속을 했나?”라는 추측을 줄이며, 송장이 실제 문제가 되기 전에 고객을 재촉하고, 신뢰할 수 있는 고객과 반복 연체자를 다르게 다룹니다.

“결제 시 자동 중지” 기능은 당혹스러운 상황을 막아 줍니다. 결제가 기록되거나 송장이 Paid로 표시되는 순간 시스템은 해당 송장에 대한 남은 알림을 취소합니다. 그래서 오늘 아침에 결제한 고객이 밤에 ‘최종 통보’ 문자를 받지 않습니다.

긴 엔지니어링 프로젝트 없이 이걸 구축하려면 AppMaster가 현실적인 옵션입니다: 송장과 결제를 모델링하고, 연령 뷰를 만들고, 실제 결제 상태에 따라 일시중지하거나 중단되는 알림 시퀀스를 실행할 수 있습니다.

AR 테이블부터 시작하세요: 실제로 필요한 데이터

알림은 데이터만큼만 좋습니다. 화면이나 자동화를 만들기 전에, 모든 뷰와 알림 시퀀스가 신뢰할 수 있는 하나의 깔끔한 AR 테이블을 정의하세요.

무엇이 얼마인지, 누구에게서 받아야 하는지, 언제인지 한 문장으로 답하는 최소 필드부터 시작하세요.

• 인보이스 번호(또는 인보이스 ID)
• 고객(계정명과 고유 고객 ID)
• 미수 금액(원래 청구 총액이 아닌 현재 오픈 잔액)
• 기한(due date)
• 상태(Open, Partially paid, Paid, Disputed, Written off)

이게 작동하면 수동 추적을 줄이고 인수인계를 명확히 하는 필드만 추가하세요:

• 배정된 담당자(사람 또는 팀)
• 결제 기록 날짜(잔액이 0이 된 시점)
• 마지막 전송된 알림(날짜/시간 및 채널)
• 다음 예정 알림(날짜/시간)
• 메모 또는 사유 코드(예: Disputed, Awaiting PO 같은 짧고 통제된 옵션)

부분 결제와 크레딧: 초기에 결정을 내리세요

부분 결제와 크레딧은 워크플로우를 뒤엉키지 않게 하려면 초반에 정책을 정해야 합니다.

간단한 접근은 인보이스 레코드에 인보이스 총액을 저장하고, 별도의 “거래(transactions)” 테이블에서 자금 이동(결제, 크레딧 메모, 조정)을 추적하는 것입니다. AR 레코드는 계산된 오픈 잔액과 “Partially paid” 상태를 저장할 수 있습니다. 이렇게 하면 히스토리를 변경하지 않고 감사 추적(audit trail)을 유지할 수 있습니다.

“결제됨(paid)”의 하나의 출처를 선택하세요

결제가 언제 기록되는지에 대해 하나의 출처를 합의하세요.

• 회계 시스템이 권위적이라면, 앱은 그 시스템을 미러로 취급해 업데이트를 반영하세요.
• 앱 내에서 결제를 기록한다면 누가 Paid로 표시할 수 있는지 권한을 잠그고, 기록된 금액과 날짜를 요구하세요.

AppMaster에서는 데이터베이스 규칙과 간단한 Business Process Editor의 승인 단계를 통해 이를 강제할 수 있으므로, 알림이 항상 올바른 이유로 중지됩니다.

팀 방식에 맞는 연령 버킷

좋은 AR 연령 보고서는 사람들이 실제로 연체 송장에 대해 이야기하는 방식과 일치해야 합니다. 팀이 이미 “31–60 구간에 있다”고 말하면 대시보드도 그걸 그대로 반영해야 합니다. 그래야 인수인계가 깔끔하고 문제를 빠르게 발견할 수 있습니다.

대부분의 팀은 다음으로 잘 작동합니다:

• Current(기한 전 또는 당일)
• 1–30일 연체
• 31–60일 연체
• 61–90일 연체
• 90일 이상 연체

송장을 버킷에 넣으려면 경과 일수(days past due) 를 계산하세요:

Days past due = (오늘 날짜) - (기한 날짜)

결과가 음수면 아직 기한이 아닙니다. 많은 팀은 이를 Current와 분리해 둡니다. Current는 보통 오늘 기한이거나 곧 기한인 것을 의미하고, “Not yet due”는 아직 한참 남은 것을 뜻합니다. 이 작은 구분 하나가 시간이 남아 있는 고객에게 부적절한 알림이 가는 것을 막아 줍니다.

기한 기준 연령 vs 송장 날짜 기준 연령

한 방법을 선택하고 모든 곳에서 동일하게 사용하세요: 대시보드, 알림 로직, 보고서.

• 기한 기준(Age by due date): 결제 조건과 공정성을 맞추려면 보통 이 방식을 사용합니다. 대부분의 AR 연령 대시보드는 이 방식을 택합니다.
• 송장 날짜 기준(Age by invoice date): 즉시 결제를 기대하는 비즈니스나 기한 정보가 신뢰할 수 없을 때 사용합니다.

실용적인 타협은 두 필드를 모두 저장하되, 버킷화는 기한을 기준으로 하는 것입니다. 기한이 없으면 송장 날짜로 대체하고 누군가가 데이터를 고치도록 플래그를 달아 두세요.

별도 상태가 필요한 특수 사례

버킷만으로는 충분하지 않습니다. 팀이 잘못된 대상을 추적하지 않도록 연령을 무시하는 상태도 필요합니다.

• Disputed: 고객이 문제를 제기한 경우, 해결될 때까지 알림을 일시중지.
• On hold: 내부 보류(예: 수정된 PO 대기).
• Promise to pay: 고객이 결제 날짜를 약속한 경우 다음 재촉을 지연.
• Paid, not posted: 결제는 받았지만 아직 기록되지 않은 경우 중복 연락을 피함.

이런 상태들을 AR 테이블에 모델링하여 대시보드와 컬렉션 자동화가 표준 큐에서 자동으로 필터링하도록 하세요. AppMaster 같은 도구에서는 상태 필드를 추가하고 뷰와 비즈니스 로직에서 이를 확인하면 됩니다.

대시보드 뷰: 요약, 담당자 큐, 고객 상세

좋은 대시보드는 한 가지를 잘합니다: 한 번에 지금 당장 주의가 필요한 것을 알려 주고 송장 하나하나를 들여다보게 하지 않습니다. 대부분의 팀에는 전체 그림, 일일 작업 큐, 단일 고객 타임라인의 세 가지 뷰가 충분합니다.

1) 요약 뷰(현재 상황 화면)

요약은 매번 열 때 같은 질문에 답해야 합니다: 얼마나 오픈되어 있는가, 얼마나 연체되어 있는가, 누가 위험을 초래하는가.

간단하게 유지하세요:

• 총 오픈 잔액과 총 연체 잔액
• 연령 버킷별 연체 분포(예: 1–30, 31–60, 61–90, 90+)
• 금액 기준 상위 연체 고객
• "지난주 이후 새로 연체된 금액" 같은 빠른 수치로 새 문제를 조기에 포착

이 뷰는 관리자와 회의 전 간단히 확인하는 사람들을 위한 것입니다.

2) 담당자 큐(오늘 내가 할 일 화면)

담당자 큐는 보고서를 할 일 목록으로 바꿉니다. 각 사람은 자신이 소유한 계정만 보고, 다음 행동이 명확히 표시되어야 합니다.

"반드시 조치해야 할" 필드에 집중하세요: 고객, 총 연체액, 가장 오래된 연체 송장, 마지막 접촉 날짜, 다음 단계, 그리고 “Reminder 2 scheduled” 또는 “Call needed” 같은 간단한 상태.

AppMaster로 만든다면 계산된 필드(예: 경과 일수, 다음 알림 날짜) 몇 개와 함께 깔끔한 테이블 뷰가 충분한 경우가 많습니다.

3) 고객 상세(상황 파악 화면)

누군가가 “이미 결제했어요”라고 말하면, 팀은 빠르게 맥락을 알아야 합니다. 고객 상세 뷰는 송장과 커뮤니케이션을 한 곳에 결합해야 합니다: 오픈 송장, 결제 이력, 메모, 마지막 접촉, 다음 예정 단계.

몇 가지 필터를 편리하게 두어 사람들이 빠르게 집중할 수 있게 하세요(예: 지역, 고객 유형, 금액 임계값 — 예: $1,000 초과 연체만 보기, 기한 범위, 담당자).

간단한 시나리오: Maria는 40개 계정을 담당합니다. 그녀의 큐는 본인 배정 계정으로 필터되어 있고 우선순위로 정렬되어 있어 우선 순위가 높은 일부터 낭비 없이 처리합니다.

그녀는 한 고객을 클릭하면 두 개의 오픈 송장, 새로운 PO 번호 요청 메모, 내일 예정된 이메일 알림을 즉시 확인합니다. 메모를 업데이트하고 다음 단계를 “PO 대기”로 설정하면 나중에 누가 이어받아도 기록이 깔끔합니다.

알림 시퀀스: 무엇을 언제 보낼지

좋은 알림 시퀀스는 공격적이지 않고 일관되게 느껴집니다. 목표는 결제를 쉽게 하고 예측 가능하게 만들며, 팀에는 명확한 후속 경로를 주는 것입니다. 대시보드와 통합되면 각 메시지는 현재 송장이 필요로 하는 것에 맞춰 보낼 수 있습니다.

단계를 단순하게 유지하세요:

• 친절한 알림(Friendly reminder): 기한 전이나 바로 기한 후의 가벼운 재촉
• 강한 후속(Firm follow-up): 명확한 다음 행동과 구체적 기한 제시
• 최종 통보(Final notice): 수동 처리로 전환하기 전 마지막 시도

채널 선택은 문구만큼 중요합니다. 이메일은 송장, 영수증, 문맥 전달에 적합하고, SMS는 짧은 재촉에 더 잘 읽힙니다. 가능하면 고객 선호(이메일만, SMS만, 둘 다)를 저장하고, 문자 수신 동의가 없으면 기본으로 이메일을 사용하세요.

타이밍 규칙은 누구나 설명할 수 있을 정도로 단순해야 합니다. 일반적인 설정은: 기한 3일 전(친절), 기한 3일 후(강경), 그다음 30일 연체까지 주간 간격. 고액 송장은 기한 이후 간격을 줄이고, 장기 고객은 더 여유를 줍니다.

메시지는 짧고 공손하며 구체적이어야 합니다. 각 알림은 세 가지 질문에 답해야 합니다: 무엇이 연체되었는가, 언제 기한이었는가, 어떻게 결제하는가.

간단한 콘텐츠 체크리스트:

• 명확한 제목 또는 첫 문장: “Invoice #1043 is now past due” 같은 문구
• 금액, 기한, 인보이스 번호
• 한두 가지 결제 옵션(카드, 은행 이체)과 연락처
• 비난 금지 — 실수로 놓쳤다고 가정
• 명확한 다음 단계(예: “금요일에 다시 연락드리겠습니다”)

AppMaster에서는 각 단계와 채널별 템플릿을 저장하고, 기한과 고객 선호에 따라 적절한 템플릿을 선택할 수 있습니다.

자동화 로직: 알림 예약과 결제 시 중지

목표는 단순합니다: 송장이 추심 가능해지는 순간 알림이 시작되고, 더 이상 추심 대상이 아닐 때 즉시 중지되어야 합니다. 자동화가 이 두 가지를 신뢰성 있게 하지 못하면 대시보드는 소음의 원천이 됩니다.

실용적인 트리거는 다음 중 하나입니다:

• 송장이 Open 상태로 생성될 때
• 송장이 Draft나 Pending에서 Open으로 변경될 때

두 번째 트리거는 송장이 처음에는 초안으로 시작하고 나중에 실체화되는 경우 중요합니다.

스팸을 피하면서 알림 예약하기

"매 X일마다 전송" 대신 기한과 현재 버킷에 메시지를 연결하세요. 이렇게 하면 송장 날짜가 바뀌어도 리듬이 유지되고 컬렉션 팀의 사고 방식과 일치합니다.

깔끔한 규칙 예시는 다음과 같습니다:

• 기한 전: 가벼운 알림(예: 기한 3일 전)
• 기한 1–7일: 1회 알림
• 기한 8–30일: 1–2회 알림(간격을 두고)
• 기한 31일 이상: 횟수는 줄이고 더 강하게 접근, 통화 작업으로 전환 고려
• 기한이나 상태가 변경되면 스케줄을 재계산

AppMaster에서는 송장 이벤트에서 실행되는 Business Process와 오늘 보낼 항목을 확인하는 예약 작업(scheduled job)에 이 규칙을 쉽게 매핑할 수 있습니다.

중지 조건과 안전장치

중지 규칙은 예약 시뿐 아니라 전송 직전에 반드시 확인해야 합니다. 그래야 다섯 분 전에 결제가 기록되었더라도 어색한 메시지가 발송되지 않습니다.

일반적인 중지 조건:

• 결제 기록(지불 금액이 잔액을 커버하거나 상태가 Paid가 됨)
• 송장이 종료되거나 탕감됨(written off)
• 분쟁 또는 보류 상태(사람에게 이관)
• 고객이 이메일/SMS 옵트아웃
• 연락처 정보 누락(이메일/전화번호 없음)

간단한 예: 송장이 연체 8일이 되어 시스템이 SMS를 예약합니다. 전송 시 잔액을 다시 확인해 결제가 게시된 것을 확인하면 남은 시퀀스를 삭제하고 "stopped: paid"로 기록해 팀이 무슨 일이 있었는지 신뢰할 수 있게 합니다.

엉망이 되지 않도록 하는 통제와 추적

알림이 나가기 시작하면, 가장 빨리 신뢰를 잃게 하는 것은 무슨 일이 왜 일어났는지 모르는 것입니다. 모든 송장은 명확한 히스토리를 가져야 하고, 모든 알림은 한눈에 설명 가능해야 합니다.

가벼운 감사 로그(audit trail)면 보통 충분합니다. 고객 경험을 바꾸는 이벤트만 추적하세요. 각 송장에 대해: 무엇이 변경되었는지, 누가 했는지, 무엇이 발송되었는지 답할 수 있는 타임라인을 유지하세요.

기본적으로 기록할 항목:

• 상태 변경(Open, In dispute, Promise to pay, Paid, Written off)과 사용자·타임스탬프
• 알림 전송(채널, 템플릿 이름, 시도 횟수, 결과)
• 결제 업데이트(금액, 날짜, 출처, 확인자)
• 주요 편집(금액, 기한, 고객 연락처 세부정보)
• 수동 작업(알림 일시중지, 시퀀스 중단, 사람에게 에스컬레이션)

전송 실패는 별도 처리 절차가 필요합니다. 바운스된 이메일이나 실패한 SMS를 무한 재시도로 방치하면 안 됩니다. 실패를 실패로 표시하고 이유를 저장한 뒤 누군가가 검토하도록 다음 단계를 만드세요.

실무적인 정책 예시:

• 일시적 실패에 대해서는 짧은 지연 후 1회 재시도
• 다시 실패하면 시퀀스를 일시중지하고 송장을 플래그
• 담당자에게 이메일/전화번호 확인을 요청
• 연락처가 업데이트되면 다음 단계부터 재개(1단계부터가 아님)
• 하드 바운스면 이메일 알림 중지하고 다른 채널로 전환

메모는 "사람의 진실(human truth)"이 기록되는 곳입니다. 보고서를 깔끔하게 유지하려면 빠른 구조화된 결과(약속 결제일, 시도된 통화, 고객이 송장이 틀리다고 말함, 부분 결제 합의, 분쟁 세부사항 등)를 추가하세요. 자유 입력란도 두되 필터링을 위해 드롭다운을 우선 배치하세요.

권한은 초기에 설정하세요. 모든 사람이 금액이나 기한을 바꿀 수 있어서는 안 되며, “알림 중지”도 감사 가능해야 합니다. AppMaster에서는 역할 기반 접근 제어와 민감한 편집은 승인된 역할만 가능하게 하는 Business Process로 이를 잘 구현할 수 있습니다. 담당자는 메모 추가나 결과 표시만 할 수 있도록 하고 재무 필드는 보호하세요.

고객 불만을 초래하는 일반적 실수와 방지 방법

고객이 이미 조치한 것을 무시하는 알림만큼 신뢰를 빠르게 잃게 하는 것은 없습니다. 자동화 관련 불만의 대부분은 알림 자체가 아니라 잘못된 데이터나 불명확한 규칙 때문입니다.

이미 결제된 송장에 알림을 보내는 경우

보통 결제 상태 업데이트가 지연되거나, 한 장소에서는 “paid”로 기록하고 다른 곳에서는 “open”으로 남아 있을 때 발생합니다. 하나의 필드를 진실의 출처로 정하고, 메시지 발송 직전에 최신 확인을 하도록 고치세요.

AR 연령 대시보드를 사용한다면 상태 업데이트를 알림과 별개의 사후 처리로 보지 말고 같은 워크플로의 일부로 처리하세요.

너무 많은 버킷과 단계

과공학은 소음을 만들고 고객은 스팸처럼 느낍니다. 대부분의 팀에는 3–5개 버킷과 2–3단계 알림이면 충분합니다. 더 필요한 경우 메시지 내용이나 소유권이 불분명한 게 원인인 경우가 많습니다.

명확한 소유자가 없음

누가 송장을 담당하는지 없으면 모두가 누군가가 처리할 것이라고 가정합니다. 고객·지역·송장 생성자별 간단한 할당 규칙으로 ‘유령 송장’을 방지하세요.

실무적 수정 사항

• 전송 직전에 송장 상태를 재확인하고 결제되면 즉시 시퀀스를 중지하세요.
• 버킷은 단순하게 유지(예: 1–7, 8–14, 15–30, 30+)하고 메시지는 2–3단계로 제한.
• 알림 시퀀스에 들어가기 전에 모든 송장에 담당자가 지정되어 있어야 함을 요구.
• 분쟁·크레딧·부분 결제의 "일시중지" 뜻을 명확히 정의.

분쟁, 크레딧, 부분 결제: 규칙을 명확히

부분 결제는 자동화가 흔히 깨지는 지점입니다. 알림이 남은 잔액을 대상으로 계속 가야 하는지, 아니면 사람이 확인할 때까지 일시중지할지 결정하세요.

분쟁의 경우 "On Hold - Dispute" 같은 명확한 상태를 사용해 알림이 자동으로 중지되도록 하세요.

AppMaster에서는 상태, 잔액, 보류 사유를 Business Process에서 전송 직전에 확인할 수 있는 필드로 만들면 규칙을 강제하기 쉽습니다.

알림을 켜기 전 빠른 체크리스트

자동 이메일·SMS 알림을 활성화하기 전에 현실적인 데이터로 짧은 드라이런을 하세요. 작은 설정 실수 하나가 유용한 재촉을 혼란스러운 메시지로, 또는 잘못된 수신자에게 가는 메시지로 만들 수 있습니다.

먼저 모든 오픈 송장이 처리 가능 상태인지 확인하세요. 기한이 없으면 시퀀스가 잘못된 시점에 트리거될 수 있습니다. 담당자가 없으면 아무도 책임지지 않습니다.

아래 체크리스트를 최종 게이트로 사용하세요:

• 모든 오픈 송장에 기한과 담당자가 지정되어 있는가. 둘 중 하나라도 없으면 해당 송장의 알림을 차단하세요.
• 연령 합계가 회계 합계와 일치하는가(합의된 규칙 기반). 부분 결제·크레딧·분쟁 처리 방식을 사전에 결정하고 검증하세요.
• 최소 하나의 중지 조건이 테스트되어 검증되었는가. "Paid" 외에도 "송장 취소", "탕감", "수금 이관" 등을 테스트하세요.
• 테스트 결제가 예약된 알림을 취소하는가. 샘플 송장을 만들고 알림이 예약된 뒤 결제를 기록해 이후 메시지가 나가지 않는지 확인하세요.
• 옵트아웃 및 우선 채널 규칙을 준수하는가. 고객이 SMS 선호 시 이메일만 보내면 안 되고, 옵트아웃 시 비필수 알림은 즉시 중지하세요.

전체 롤아웃 전에 소수의 송장으로 제어된 테스트를 하세요. 예: 오늘 기한인 송장, 7일 연체, 21일 연체인 3개의 송장을 만들어 내부 테스트 연락처로만 먼저 전송해 문구와 타이밍을 검증한 뒤 실제 고객으로 전환하세요.

AppMaster로 구축한다면 체크를 워크플로에 가깝게 두세요: 송장 생성 시 필수 필드를 검증하고, Business Process에서 "payment recorded"가 인보이스 상태를 업데이트하고 큐에 있는 이메일·SMS 알림을 취소하게 하세요.

예시: 지속적 추적 없이 소규모 팀이 결제 모으기

작은 서비스 회사에 재무 담당자 Mia 한 명과 영업 리드 Jordan이 있습니다. 그들은 스프레드시트를 뒤적이지 않고도 오늘 마감할 일을 볼 수 있도록 AR 연령 대시보드를 사용합니다.

한 고객 Northwind Dental에 세 건의 오픈 송장이 있습니다:

• Invoice #1021: $1,200, 12일 연체(1–30 버킷)
• Invoice #1033: $800, 37일 연체(31–60 버킷)
• Invoice #1040: $450, 아직 기한 전(Current 버킷)

Mia는 매일 아침 담당자 큐에서 시작합니다. 본인 배정 계정으로 필터돼 있고 우선순위별 정렬이 되어 있어 무엇을 먼저 처리할지 고민할 필요가 없습니다.

그녀의 루틴은 단순합니다:

• 31–60 구간은 우선 개인 이메일 발송
• 약속 결제일이 있는 송장은 재촉 전에 확인
• 고액 계정은 메시지 대신 통화 작업 생성
• 최근 분쟁이 있는 계정은 일시중지 후 적절한 팀원에게 라우팅

Northwind Dental의 37일 연체 송장은 오늘 시퀀스 단계를 트리거합니다. 오전 9시에 시스템은 인보이스 번호, 금액, 명확한 다음 단계(결제 날짜 회신 또는 즉시 결제)를 참조한 이메일을 예약합니다. 이틀 내 활동이 없으면 SMS 후속을 예약합니다. 12일짜리 송장은 더 완화된 트랙에 남아 더 적은 재촉을 받습니다.

오전 11시 18분, Northwind가 Invoice #1033을 결제합니다. 결제가 기록되는 순간 자동화는 해당 송장에 연결된 모든 미래 알림을 취소합니다. 그 계정은 내일 나갈 SMS를 받지 않습니다. Mia는 고객 상세 뷰에서 상태 변경과 함께 시퀀스가 결제로 중지되었다는 타임라인 노트를 확인합니다.

가장 좋은 점은 Mia가 규칙을 외울 필요가 없다는 것입니다. 대시보드는 남은 일을 보여 주고 워크플로우가 타이밍을 관리합니다.

안전한 롤아웃 계획은 예측 가능하게 유지합니다:

• 서로 다른 버킷에서 10–20개 고객으로 파일럿 실행
• 회신, 분쟁, 옵트아웃을 매주 검토하고 문구 조정
• 깨끗한 결과가 나올 때만 다음 시퀀스 단계를 추가
• 결제 시 중지 로직이 검증되면 전체 AR 목록으로 확장

코드 없이 AppMaster에서 이 전체 과정을 구축할 수 있습니다: Data Designer에서 인보이스와 결제를 모델링하고, UI 빌더에서 대시보드 화면을 만들고, Business Process Editor에서 알림·중지 규칙을 정의하고, 내장 메시징 통합을 통해 메시지를 전송하세요.