미창조㈜ · AX 사업추진 TF

16-G. 시술 기록·상담 기능 상세 — 9개

15번 목록의 G 도메인을 와이어프레임 작성자가 화면에 무엇을 놓을지 판단할 수 있는 수준까지 폈다. 기능 하나를 여섯 줄(목적·트리거·입력·규칙·결과·예외)로 정의한다.

9개1차92차0미결 02차 미작성 0

상위: 15. RIAHN CONNECT 기능 목록 · 화면 목록 — G 도메인
필드 정의와 표기(⚑ 분리 검토 · ▷ 2차 상세 미작성)는 16-C 0-1과 같다
작성: 이원섭 PM · 2026-08-11

0. 이 도메인이 사업 전체를 좌우한다

계획서·과업지시서 어디에도 독립 항목으로 없지만, 이 사업의 데이터 품질 전체가 여기서 결정된다.

[8/7 미팅 근거] 본부장 — "쓰는 매장이 있고, 안 쓰는 매장이 있고 그런 차이가 좀 있습니다… 메모를 쓰는 매장이 많지는 않고… 워낙 이 핸드[SOS]에 데이터 만들어 놓은 건 많은데 사실 다 쓰는 게 아니거든요."

즉 기존 CRM은 기록 필드가 있어도 안 쓰인다. 데이터가 없는 게 아니라 입력이 안 되는 것이 문제다. RIAHN CONNECT가 헤어짱·핸드SOS를 대체해도 입력 UX가 같으면 결과도 같다.

제약 넷

입력 시간이 3탭을 넘으면 안 쓰인다. 이 도메인의 성패는 기능 개수가 아니라 G-02 하나에 달려 있다. 젖은 손으로, 시술 중에, 서서 입력한다.
정량 입력과 빠른 입력은 상충한다. 약제 소진(O-07)을 재려면 g/ml 단위가 필요한데 그걸 손으로 넣으라고 하면 아무도 안 쓴다. 배합 프리셋 선택 = 정량 자동 산출로 푼다.
기록되지 않은 것은 없는 것이다. 결제는 남는데 시술이 안 남는 건이 상당수다(C-12). 기록률 자체를 지표로 관리한다(G-06).
사진과 상담 내용은 동의에 걸린다. 촬영 전 동의 확인이 선행되고, 원본은 보관하지 않는다.

1. 기록 입력 (4)

RC-G-01시술 기록 입력1차

R3 디자이너SC-D04 (D3 모바일태블릿)

목적: 실제로 무엇을 어떻게 했는지 남긴다. 추천·레시피·이탈 예측 모델의 유일한 원천 데이터
트리거: 시술 완료 직후. 또는 시술 중 단계별로
입력: 예약·고객(A-10) · 메뉴(K-03) · 약제 마스터(O-07) · 직전 시술 이력(B-04)
규칙: 실제 시술 내용·약제·배합비·소요시간을 남긴다. 예약된 시술과 실제가 다르면 실제를 기준으로 하고 차이를 남긴다 — 결제(C-01)가 이 값을 쓴다. 소요시간은 자동 측정을 우선하고 수기 보정을 허용한다(A-06 실측 보정의 입력). 약제는 O-07 코드 체계를 쓴다
결과: 시술 기록 1행, B-04 타임라인에 추가, C-01 결제의 확정 근거, I-08 레시피 환류 입력, O-07 재고 소진
예외: 미입력 상태로 결제가 끝나면 C-12 정합 보정 대상이 된다. 네트워크가 끊겨도 입력은 계속되고 재연결 시 동기화한다

RC-G-02빠른 입력 UX1차

R3SC-D04

목적: 기록을 실제로 하게 만든다. 와이어프레임의 성패가 여기 달려 있다
트리거: G-01 입력 시작
입력: 표준 태그 · 직전 시술(B-04) · 음성 입력 · 배합 프리셋(O-07)
규칙: 3탭 이내 완료를 목표로 한다. 세 가지 수단을 병용한다 — ①표준 태그 선택 ②직전 시술 복사 후 수정 ③음성 입력. 터치 타깃은 최소 44px, 시술 중 사용을 전제로 조작 단계를 최소화한다. ⚠️ 약제 정량 입력과 상충하므로 배합 프리셋을 고르면 정량이 자동 산출되게 하고 수기 계량을 강요하지 않는다
결과: G-01 기록 완료
예외: 프리셋에 없는 배합은 수기 입력을 허용하되 그 건은 별도 표시해 프리셋 보완에 쓴다

RC-G-03상담 기록1차

R3SC-D07 SC-C01

목적: 고객이 무엇을 원했는지 남긴다. 시술 결과와 요구의 차이가 클레임의 근원
트리거: 시술 전 상담
입력: 상담 내용 · STT 음성 · 고객 요구사항
규칙: 텍스트와 STT 둘 다 받는다. 요구사항을 구조화해 다음 방문 때 브리핑(B-13)에 실린다. 고객 확인 화면(SC-C01)에 오늘 할 시술·예상 금액·소요시간을 띄워 합의를 남긴다
결과: 상담 기록, 고객 확인, 시술 기록(G-01)의 참조
예외: STT는 매장 소음에서 정확도가 떨어진다. 원문과 교정본을 함께 두고 교정을 강제하지 않는다

RC-G-04시술 전후 사진 촬영1차

R3SC-D06

목적: 결과를 시각으로 남긴다. 클레임 근거이자 포트폴리오(F-05) 원천
트리거: 시술 전, 시술 후
입력: 카메라 · 동의 상태(J-01, B-16)
규칙: 촬영 → 동의 확인 → 업로드 순서를 지킨다. 동의가 없으면 촬영 단계에서 막는다 — 찍고 나서 묻는 순서면 이미 늦다. 원본은 보관하지 않는다(비식별 처리 후 저장). 전후를 쌍으로 묶는다
결과: 사진 저장, B-06 고객 카드에 연결
예외: 동의 철회 시 기존 사진 열람이 즉시 막힌다. 삭제 요청(J-10)은 별도 절차

2. 수집·품질 (5)

RC-G-05만족도 수집1차

R6 고객SC-C04

목적: 결과에 대한 고객 반응을 즉시 받는다
트리거: 시술 직후 거울앞 태블릿. 또는 사후 링크 발송
입력: 별점 · 간단 코멘트
규칙: 시술 직후 태블릿이 응답률이 가장 높다. 항목을 늘리지 않는다 — 별점 하나와 선택 코멘트면 충분하다. 사후 링크는 응답률이 낮지만 솔직도가 높으므로 병행한다
결과: 만족도 1행, B-04 이력에 표시, B-10 이탈 위험 입력, F-03 디자이너 성과 입력
예외: 저점 응답은 클레임(B-08)으로 전환할 수 있게 한다. 담당 디자이너 앞에서 입력하는 구조라 점수가 관대해지는 편향이 있다 — 사후 링크 응답과 분리해 본다

RC-G-06기록 완료율 표시1차

R1SC-M19 SC-M28

목적: 기록이 실제로 되고 있는지 본다. 이 도메인이 작동하는지 판정하는 지표
트리거: 일·주 단위 집계
입력: 결제 건수 대비 시술 기록 건수 · 디자이너별·매장별 분해
규칙: 디자이너별·매장별 기록률을 낸다. 낮은 쪽을 벌하는 용도가 아니라 입력 UX가 어디서 막히는지 찾는 용도로 쓴다 — 특정 시술군에서만 기록률이 낮으면 그 입력 흐름에 문제가 있는 것이다. 8/7 미팅의 "메모 작성 우수 매장 식별"(랩큐 액션 26번)이 여기 걸린다
결과: 기록률 지표, 저조 구간 식별
예외: 표본 편향에 주의한다. 기록이 잘 되는 매장의 데이터만 모델에 들어가면 결과가 왜곡된다

RC-G-07미기록 리마인더1차

자동 → R3SC-M19 SC-D01

목적: 빠뜨린 기록을 그날 안에 채우게 한다
트리거: 결제 완료 + 시술 기록 없음이 일정 시간 지속
입력: C-12 정합 검사 결과 · 담당 디자이너
규칙: 담당 디자이너에게 먼저 보낸다. 매니저에게 먼저 가면 대신 입력하게 되고 그러면 내용이 부정확해진다. 퇴근 전 한 번 모아서 보내는 편이 건별 알림보다 낫다. 알림 라우팅은 K-17
결과: 리마인더 발송, 미기록 목록
예외: 며칠 지난 건은 기억에 의존하므로 정확도가 떨어진다. 경과일을 함께 표시해 신뢰도 판단에 쓴다

RC-G-08시술 레시피 뷰1차

R3SC-D05(경계 — SFR-I)

목적: 시술 중 무엇을 어떻게 할지 태블릿으로 본다
트리거: 시술 시작
입력: 확정 레시피(SFR-I) · 고객 이력(B-04) · 진단(B-05)
규칙: 단계 체크리스트와 타이머를 제공한다. 방치 시간(A-07)이 타이머와 연동된다. 스펙 소유는 SFR-I이며 여기서는 표시와 데이터 계약만 정의한다 — 와이어프레임에 점선 박스 + "타 모듈 연동" 라벨
결과: 조회. 실제 값과 다르면 G-01에서 실제를 기록
예외: 레시피가 없는 시술은 빈 상태로 둔다

RC-G-09레시피 확정 갱신1차

자동SC-D04(경계 — I-08)

목적: 실제 시술값을 레시피에 되먹인다. 레시피가 현실과 멀어지지 않게 하는 장치
트리거: G-01 기록 완료
입력: 실제 시술값(약제·배합비·소요시간) · 기존 레시피 버전
규칙: 실제값으로 확정 버전을 갱신한다. 개별 시술 한 건으로 바로 바꾸지 않고 누적된 실제값의 경향으로 판단한다. 버전을 남겨 되돌릴 수 있게 한다
결과: 레시피 확정 버전 갱신, I-08 환류
예외: 기록 신뢰도가 낮은 건(G-07 지연 입력 등)은 환류에서 가중치를 낮춘다