14 KiB
14 KiB
EG-BIM Q&A 사용자 여정 맵
기준일: 2026-09-21
대상 서비스: qa-test.baroncs.co.kr / EG-BIM Q&A
주요 사용자: EG-BIM 관련 문의가 있는 작성자, 문의를 처리하는 관리자·담당자
여정 범위: Q&A 진입부터 문의 등록, 답변 확인, 완료 확인까지
이 문서는 시스템 상태의 흐름이 아니라 사용자가 경험하는 목표·행동·감정·접점·문제·개선 기회를 중심으로 정리한 journey map이다. 상세한 OAuth, API, DB 상태 전이는 기술 전이맵을 참고한다.
1. 한눈에 보는 여정
journey
title EG-BIM Q&A 문의 작성자 여정
section 문의를 시작함
Q&A 메뉴를 발견한다: 4: 작성자
Q&A 페이지로 이동한다: 4: 작성자
SSO 로그인·동의를 완료한다: 2: 작성자
section 문의를 등록함
목록에서 문의 등록을 선택한다: 4: 작성자
카테고리·제목·내용을 입력한다: 4: 작성자
첨부파일과 비밀글 여부를 설정한다: 3: 작성자
문의를 제출하고 접수 결과를 확인한다: 4: 작성자
section 처리 결과를 기다림
문의 상세에서 접수 내용을 확인한다: 3: 작성자
상태 변경·답변 알림을 받는다: 3: 작성자
상세 페이지에서 관리자 답변을 확인한다: 4: 작성자
section 문의를 마무리함
추가 질문을 남긴다: 3: 작성자
완료 안내를 확인한다: 4: 작성자
완료 확인을 제출한다: 4: 작성자
2. 사용자 프로필과 여정의 목표
문의 작성자
EG-BIM을 사용하면서 문제가 생겼거나 지원이 필요한 사용자다. 빠르게 문의를 남기고, 내 문의가 정상적으로 접수되었는지와 현재 처리 상태를 알고 싶어 한다. 답변이 도착하면 내용을 확인하고 필요할 경우 추가 질문을 남긴다.
사용자의 핵심 목표는 다음과 같다.
- 별도의 복잡한 가입 절차 없이 Q&A에 진입하기
- 문의 내용을 정확하게 전달하기
- 첨부파일과 비밀글을 안전하게 사용하기
- 문의가 접수되고 처리 중인지 확인하기
- 답변을 확인하고 문제 해결 여부를 마무리하기
관리자·담당자
접수된 문의를 확인하고 담당자를 지정한 뒤 상태, 공개 답변, 내부 메모를 관리한다. 작성자에게 필요한 정보만 전달하면서 내부 협업 정보와 비밀 정보를 보호해야 한다.
3. 문의 작성자 여정 맵
| 단계 | 사용자의 목표·질문 | 사용자 행동 | 주요 접점 | 생각·감정 | 문제점·불안 요소 | 개선 기회 |
|---|---|---|---|---|---|---|
| 1. 진입 | “어디에서 문의하지?” | 홈페이지에서 EG-BIM Q&A 메뉴를 찾고 클릭한다. | 바론 홈페이지, Q&A 링크 | 빠르게 해결하고 싶음 | Q&A 위치나 별도 사이트 이동이 명확하지 않을 수 있음 | 메뉴명에 Q&A 문의하기를 사용하고, 이동 전 안내 문구를 제공한다. |
| 2. 인증 | “내 계정으로 바로 들어갈 수 있나?” | Q&A로 이동한 뒤 필요하면 중앙 SSO에서 로그인·동의한다. | Q&A 진입 화면, BRSW SSO | 기대 → 로그인 피로 | 외부 사이트로 이동한 이유를 모를 수 있고, 로그인 실패 원인이 불명확할 수 있음 | EG-BIM 계정으로 로그인합니다라는 설명과 실패 원인별 안내를 제공한다. |
| 3. 문의 시작 | “새 문의를 어디서 작성하지?” | 목록을 확인하고 문의 등록 버튼을 누른다. | Q&A 목록, 문의 등록 버튼 | 안도감 | 버튼이 눈에 띄지 않거나 기존 문의와 새 문의의 구분이 약할 수 있음 | 목록 상단에 주요 CTA를 고정하고 새 문의 등록으로 명확히 표시한다. |
| 4. 내용 작성 | “무엇을 얼마나 적어야 하지?” | 카테고리, 제목, 내용, 비밀글 여부를 입력한다. | 작성 폼, 입력 도움말 | 집중, 약간의 부담 | 필수 항목, 적절한 설명 수준, 개인정보 입력 여부를 판단하기 어려울 수 있음 | 예시 문구, 필수 표시, 개인정보·비밀글 안내, 작성 중 이탈 방지를 제공한다. |
| 5. 첨부·제출 | “파일이 제대로 올라갔나? 제출됐나?” | 파일을 첨부하고 등록 버튼을 누른다. | 첨부 UI, 업로드 진행 표시, 등록 버튼 | 긴장 → 안도 | 큰 파일·지원하지 않는 형식·네트워크 오류를 알기 어려울 수 있음 | 파일 형식·용량 사전 안내, 진행률, 재시도, 중복 제출 방지를 제공한다. |
| 6. 접수 확인 | “내 문의가 접수됐나?” | 등록 완료 메시지와 문의 상세를 확인한다. | 완료 toast, 상세 페이지 | 안도감 | 접수 번호와 다음 단계가 충분히 안내되지 않을 수 있음 | 접수 번호, 현재 상태, 예상 처리 안내, 알림 수단을 명확히 보여준다. |
| 7. 처리 대기 | “누가 보고 있나? 언제 답이 오나?” | 상세 페이지를 다시 방문하거나 알림을 확인한다. | Q&A 상세, SMS·카카오 알림 | 불확실함 | 처리 상태가 오래 바뀌지 않거나 진행 상황을 알 수 없을 수 있음 | 상태 정의, 최종 업데이트 시각, 예상 응답 시간, 상태 변경 알림을 제공한다. |
| 8. 답변 확인 | “문제가 해결됐나?” | 관리자 공개 댓글과 상태를 확인한다. | 상세 페이지, 답변 알림 | 기대 → 안도 또는 추가 질문 | 답변과 내부 메모가 섞이거나, 답변 알림에서 내용을 확인하기 어려울 수 있음 | 공개 답변만 노출하고, 답변 알림은 상세 페이지로 연결한다. |
| 9. 추가 질문 | “조금 더 설명하거나 다시 물어봐도 되나?” | 추가 댓글을 남기고 필요한 파일을 보완한다. | 댓글 입력, 첨부 UI | 협업, 때로는 답답함 | 완료된 문의를 다시 문의해야 하는지 기준이 모호할 수 있음 | 추가 문의와 완료 확인을 구분하고, 완료 후 재문의 정책을 안내한다. |
| 10. 완료 | “이 문의를 끝내도 되나?” | 완료 안내를 확인하고 완료 확인을 제출한다. | 완료 안내, 완료 확인 버튼 | 마무리, 만족 또는 망설임 | 완료 확인의 의미와 취소 가능 여부가 불명확할 수 있음 | 완료 확인 전 안내, 확인 후 상태·후속 문의 방법을 제공한다. |
4. 감정 곡선과 핵심 순간
감정
높음 진입 ── 문의 시작 ── 접수 확인 ───────── 답변 확인 ── 완료
︿ ︿ ︿ ︿ ︿
중간 ────┘ └─ 작성 ──────┘ └─ 추가 질문 ┘
낮음 인증 실패·업로드 실패·장기 대기
가장 중요한 순간은 다음 네 가지다.
- 로그인 전환 순간: 사용자는 Q&A가 다른 사이트로 보이더라도 인증 과정이 안전하고 자연스럽다고 느껴야 한다.
- 제출 직후: 문의가 실제로 접수되었다는 확신이 필요하다. 완료 메시지만이 아니라 접수 번호와 현재 상태가 중요하다.
- 처리 대기 중: 답변이 없더라도 문의가 사라지지 않았다는 신뢰를 유지해야 한다.
- 답변·완료 순간: 공개 답변과 내부 처리 정보를 구분하고, 사용자가 해결 여부를 명확히 표시할 수 있어야 한다.
5. 관리자·담당자 백스테이지 여정
| 단계 | 관리자·담당자의 행동 | 사용자에게 보이는 결과 | 백스테이지 시스템 | 주의점 |
|---|---|---|---|---|
| 접수 확인 | 새 문의 목록을 확인한다. | 문의가 목록과 상세에 표시된다. | ABC API, workspace → project/channel 매핑 | feedbackId를 화면 표시 번호와 혼동하지 않는다. |
| 담당자 지정 | 담당자와 처리 범위를 지정한다. | 필요하면 담당자 지정 상태가 표시된다. | Secretary API, ABC feedback 필드 | 담당자 이메일과 WORKS 계정 매핑을 함께 확인한다. |
| 상태 관리 | 접수·처리 중·완료 등 상태를 변경한다. | 상태와 최종 변경 시각이 갱신된다. | ABC API PATCH, 상태 변경 이벤트 | 같은 상태를 다시 저장해 중복 알림을 만들지 않는다. |
| 내부 협업 | 내부 메모를 남긴다. | 작성자에게 노출되지 않는다. | 내부 댓글·권한 처리 | 내부 메모가 공개 댓글로 저장되지 않도록 구분한다. |
| 공개 답변 | 작성자에게 보여줄 댓글을 등록한다. | Q&A 상세에서 답변을 볼 수 있다. | 공개 댓글 API, 댓글 생성 이벤트 | 비밀글 내용과 내부 정보가 알림에 포함되지 않게 한다. |
| 완료 안내 | 완료 안내를 남기고 해결 여부를 요청한다. | 작성자에게 완료 확인 버튼이 노출된다. | COMPLETION_NOTICE, requester 검증 |
작성자 본인만 완료 확인할 수 있어야 한다. |
| 알림 처리 | 대상에 맞는 채널로 알림을 보낸다. | 사내 사용자는 WORKS, 외부 사용자는 카카오·SMS를 받는다. | 이벤트 라우터, 알림 이력 | 사용자 유형을 이메일만으로 판단하지 않고 서버에서 재검증한다. |
6. 터치포인트와 책임 주체
| 터치포인트 | 사용자 경험 책임 | 주요 성공 기준 |
|---|---|---|
| 홈페이지 Q&A 링크 | 홈페이지 | 링크가 눈에 띄고 이동 목적이 명확하다. |
| SSO 로그인·동의 | 인증/플랫폼 | 로그인 성공률이 높고 실패 이유를 이해할 수 있다. |
| Q&A 목록 | Q&A 프론트엔드 | 문의 등록과 기존 문의 확인이 쉽다. |
| 작성 폼 | Q&A 프론트엔드 | 필수 입력·첨부·비밀글 설정을 오류 없이 완료한다. |
| 등록 API·파일 업로드 | Q&A API·스토리지 | 중복 없이 저장되고 실패 시 복구 경로가 있다. |
| 관리페이지 | 운영/관리자 콘솔 | 문의가 빠르게 분류·담당 배정·처리된다. |
| 공개 댓글 | 관리자·Q&A | 작성자가 이해할 수 있는 답변이 제공된다. |
| WORKS·카카오·SMS | 알림 시스템 | 올바른 수신자에게 한 번만, 안전한 내용으로 전달된다. |
| 완료 확인 | Q&A·ABC API | 작성자 본인의 확인만 처리되고 상태가 일관되게 갱신된다. |
7. 핵심 개선 과제 우선순위
| 우선순위 | 개선 과제 | 기대 효과 | 확인 지표 |
|---|---|---|---|
| P0 | 등록 성공 화면에 접수 번호·상태·다음 행동을 명확히 표시 | 제출 후 불안 감소, 중복 문의 감소 | 등록 후 재제출 비율, 접수 확인 관련 문의 수 |
| P0 | 로그인·세션·첨부 업로드 실패 메시지를 사용자 언어로 정리 | 이탈과 반복 시도 감소 | 인증/업로드 실패 후 이탈률 |
| P0 | 공개 댓글·내부 메모·외부 알림의 정보 경계를 검증 | 정보 노출 사고 방지 | 권한 테스트, 알림 payload 점검 |
| P1 | 처리 상태와 최종 업데이트 시각을 상세에 표시 | 처리 대기 중 신뢰 향상 | 상세 재방문율, 상태 문의 건수 |
| P1 | 카카오 알림톡 실패 시 SMS fallback과 발송 결과를 운영 화면에 표시 | 답변 도달률 향상 | 채널별 SENT·FAILED·SKIPPED 비율 |
| P1 | 완료 안내와 추가 문의의 행동을 분리 | 완료 후 혼란 감소 | 완료 확인율, 완료 후 재문의 처리시간 |
| P2 | 작성 예시·첨부 가이드·비밀글 안내를 폼에 추가 | 문의 품질 향상 | 추가 확인 요청 비율, 첨부 오류율 |
8. 여정에서 보장해야 하는 원칙
- 사용자는 자신의 문의와 공개 답변만 볼 수 있어야 한다.
- 내부 메모, SSO token, API key, WORKS 인증정보는 사용자 화면·알림·로그에 노출하지 않는다.
- 비밀글은 알림에 제목·본문·댓글 원문을 포함하지 않고, 상세 페이지에서 권한을 확인하도록 한다.
- 접수 성공과 알림 발송 성공은 별개의 결과로 보여준다. 문의가 저장되었지만 알림이 실패할 수 있다.
- 같은 사용자가 여러 역할을 가져도 한 이벤트의 알림은 채널별 한 번만 발송한다.
- 작성자에게 보내는 링크는 관리페이지가 아니라 Q&A 상세 페이지여야 한다.
- 완료 상태는 작성자 본인 확인과 관리자 처리 결과가 일관되게 반영되어야 한다.
9. 검증용 대표 시나리오
정상 여정
홈페이지 Q&A 클릭
→ SSO 인증
→ Q&A 목록
→ 문의 작성·첨부
→ 등록 성공 및 상세 이동
→ 관리자 담당자 지정·상태 변경
→ 관리자 공개 답변
→ 작성자 답변 확인
→ 완료 확인
인증 세션이 이미 있는 사용자
홈페이지 Q&A 클릭
→ 로그인 화면 없이 Q&A 목록 진입
→ 문의 작성·등록
첨부 업로드 실패
문의 내용 작성
→ 파일 업로드 실패
→ 실패 원인 표시·재시도
→ 성공 후 제출 가능
외부 작성자 알림
문의 저장
→ 외부 작성자 판정
→ 카카오 알림톡 시도
→ 실패 시 SMS fallback
→ 채널별 결과 기록
내부 메모와 공개 답변 구분
관리자 내부 메모 저장
→ 작성자에게 미노출
관리자 공개 답변 저장
→ 작성자 상세 페이지에 노출
→ 답변 알림 발송
10. 현재 테스트 모드에서의 범위
현재 assets/config.js의 apiBaseUrl이 비어 있으면 문의 등록 결과는 브라우저 localStorage에 임시 저장된다. 따라서 사용자는 등록 완료와 상세 이동을 경험할 수 있지만, 다음 백스테이지 여정은 실제로 실행되지 않는다.
- ABC DB 저장
- 관리페이지 목록 반영
- 담당자 지정과 상태 변경
FEEDBACK_CREATION등 이벤트 발생- WORKS·카카오·SMS 알림
- 작성자 완료 확인의 서버 검증
운영 여정을 검증하려면 실제 API 연결, Q&A 세션 검증, 알림 채널 설정, 수신자 매핑, 공개 댓글·내부 메모 권한 검증을 함께 완료해야 한다.