전시 부스 신청 관리자 화면 필수 항목을 실무 관점에서 정리했습니다. 신청 폼 수집 항목, 현황 대시보드, 부스 배정, 승인 워크플로우, 결제 연동, 권한 로그까지 설계 기준을 확인하세요.
- 부스 신청 접수 설계 전 결론: 관리자 화면에 반드시 들어가야 할 6가지
- 1단계: 참가업체별 필수 수집 항목과 신청 폼 설계 기준
부스 신청 접수 설계 전 결론: 관리자 화면에 반드시 들어가야 할 6가지

부스 신청 시스템을 설계하다 보면 흔히 "접수 폼부터 만들자"고 시작하는데, 이건 순서가 반대예요. 사무국이 마감 이후에 무스 추가래 하는가를 먼저 정의하고, 그 작업이 화면에서 어떻게 처리될지를 거꾸로 설계해야 접수 항목이 흔들리지 않습니다. 결론부터 말씀드리면, 관리자 화면에 반드시 들어가야 할 건 아래 6가지입니다.
6가지 필수 구성 요소
1. 참가업체 수집 항목 설계 — 업체명, 담당자, 연락처, 사업자등록증 첨부까지 한 번에 받기 2. 실시간 현황 대시보드 + 엑셀 다운로드 — 접수 건수, 결제 통계를 라이브로 보고, 행사 후 보고서로 내보내기 3. 부스 배정 도면 관리 — 신청 내역과 배정 현황을 하나의 화면에서 대조하기 4. 승인·반려·대기 워크플로우 + 자동 알림 — 상태 변경 시 담당자에게 알림톡 발송 5. 결제 연동과 수납 관리 — 카드·간편결제·가상계좌 연동, 미수금 추적 6. 권한·로그 기반 수정·환불 처리 — 누가 언제 무엇을 바꿨는지 기록으로 남기기
왜 "하나의 데이터 흐름"이어야 하는가
이 6가지가 각각 따로 놀면 사무국이 마감 2주 전쯤 반드시 사고가 납니다. 엑셀로 받은 신청과 결제 내역이 안 맞고, 승인 메일은 이미 갔는데 부스 배정은 안 된 업체가 발견되는 식이죠.
1단계: 참가업체별 필수 수집 항목과 신청 폼 설계 기준

부스 신청이 몇십 건 쌓인 뒤에 후회하는 순간은 대부분 "명찰에 쓸 소속명을 따로 안 받았네" 하는 순간입니다. 접수가 시작된 폼은 고치기 어렵고, 빠진 데이터를 다시 묻는 일은 참가업체도 운영팀도 지치게 만듭니다. 그래서 필드 정의가 곧 관리자 화면 설계의 절반입니다.
필수 수집 항목 다섯 가지
- 업체명(사업자명) — 명찰·계산서·안내판에 공통으로 쓰이는 기준값
- 담당자명·연락처·이메일 — 승인 안내와 당일 알림이 도착할 창구
- 사업자등록증 첨부 — 형식·용량 검증을 폼 단계에서 미리 걸어두기
- 부스 규모·종류 — 자유기입 대신 선택지로 받아야 나중에 집계가 됩니다
- 요청 위치 메모 — 배치 확정 전 참고용으로 남기는 짧은 텍스트 필드
여기서 판단 기준은 "이 값이 나중에 어디서 다시 쓰이는가" 하나입니다. e-Regi 배지 시스템은 이름·소속·QR·로고를 드래그앤드롭으로 배치하고 키오스크에서 1초 만에 명찰을 뽑아 줍니다. 즉 신청 폼의 소속 필드가 그대로 현장 명찰의 품질을 결정하는 구조라서, 처음부터 필드명을 통일해야 합니다.
폼 설계에서 놓치기 쉬운 세 가지
- 반응형 대응 — 담당자는 PC보다 스마트폰·태
2단계: 현황 대시보드, 부스 배정 도면, 상태 변경 워크플로우 구성

신청이 들어오기 시작하면 관리자 화면은 곧 운영 본부가 됩니다. 문제는 신청 접수 화면만 잘 만들어두고 정작 이걸 보는 화면이 빈약하면, 마감 직전에 "어느 부스가 남았지? 결제 안 한 곳이 몇 곳이지?"를 엑셀을 열어 하나씩 세는 상황이 생긴다는 겁니다.
대시보드: 숫자를 보는 화면, 아니라 판단하는 화면
라이브 모니터링이 진짜 힘을 발휘하는 순간은 '보고'가 아니라 판단일 때입니다. e-Regi처럼 참가 현황과 결제 통계를 실시간으로 보여주는 대시보드라면 이런 장면에서 바로 쓸 수 있어요.
- 접수 마감 임박: 신청 건수 대비 결제 완료 비율을 보고 미결제자에게 알림 재발송 판단
- 부스 마감 관리: 승인 대기 건이 몇 개인지 보고 오늘 몇 건을 처리할지 결정
- 행사 종료 후: 전체 데이터를 엑셀 보고서로 내보내기해 협찬사·내부 보고 마감
이때 대시보드에 반드시 있어야 할 항목을 미리 정해두세요.
- 신청 건수 (일별 추이)
- 상태별 건수: 승인 / 대기 / 반려
- 결제 현황: 완료 / 미결제 / 환불
- 부스 유형별 신청·배정 현황
부스 배정 도면: 색으로 보는 잔여 현황
3단계: 결제 연동·수납 관리와 마감 후 수정·환불 처리 로그

마감일 오후를 상상해 보세요. 조기신청 할인이 끝나기 직전인데 가상계좌로 신청한 업체 몇 곳의 입금이 아직 잡히지 않고, 그 사이에 부스 규모를 바꾸겠다는 전화가 겹칩니다. 결제 단계는 이렇게 수납 확인과 변경 요청이 동시에 몰리는 구간이라, 화면 설계가 처음부터 이 상황을 전제로 해야 합니다.
PG 연동과 요금 자동 계산
e-Regi는 NICEPAY·토스페이먼츠 통합 결제로 신용카드, 카카오페이, 네이버페이, 가상계좌를 지원합니다.
자체 개발 vs 솔루션 도입 비교와 사무국 체크리스트

행사를 앞두고 사무국에 가장 잦은 요청은 "부스 하나 더 추가해 주세요", "결제 수단에 가상계좌도 넣을 수 있나요" 같은 것들입니다. 자체 개발 시스템이라면 견적 산정과 수정 기간을 다시 협의해야 하지만, 검증된 솔루션이라면 관리자 화면에서 설정만 바꿔 바로 반영합니다. 이 대응 속도 차이가 사무국의 야근량을 정한다고 해도 지나치지 않습니다.
자체 개발 vs 솔루션 도입, 무엇이 다른가
| 항목 | 자체 개발 | 솔루션 도입 |
|---|---|---|
| 초기 준비 | 견적·구축 기간·요구사항 정의를 직접 진행 | 별도 개발 없이 행사를 개설해 바로 운영 |
| 인프라 | 서버 구축과 운영을 직접 관리 | 클라우드 SaaS라 별도 서버 구축 불필요 |
| 검증 | 첫 행사가 그대로 시험대가 됨 | 20+ 운영 완료 행사, 5k+ 누적 참가자, 99.9% 서비스 가동률 |
| 결제 연동 | PG API를 개별 발주하고 직접 연동 | NICEPAY·토스페이먼츠 통합으로 카드·카카오페이·네이버페이·가상계좌 지원 |
| 알림 발송 | 알림톡 API 직접 연동 필요 | 등록 완료·배지 발송·당일 알림 자동 발송, 대량 발송·템플릿 관리 지원 |
| 유지보수 | 장애 대응과 기능 수정을 직접 부담 | 운영사가 플랫폼 안정성을 관리 |