여행사 예약 관리 프로그램 고르는 기준 — 시트로 버티다 막히는 5지점

여행사 예약 관리 프로그램은 예약 건을 한 곳에 모아, 변경 이력과 출발 전 처리해야 할 일을 사람의 기억 대신 시스템이 붙들게 하는 도구입니다. 기능 목록을 비교하기 전에, 지금 쓰는 시트가 정확히 어디서 깨지는지 확인하는 편이 빠릅니다. 이 문서는 판단 기준 12가지, 3방식 비교표, 월 300건 기준 비용 환산, 실제 운영 데이터로 확인한 동기화·취소 수치, 4주 이관 계획을 순서대로 담았습니다.

여행사 예약 관리 프로그램은 무엇을 대신해 주는가

이름은 여러 가지로 불립니다. 예약 관리 프로그램, 여행사 관리 프로그램, 여행사 ERP, 투어 오피스. 부르는 말은 달라도 실제로 대신해 주는 일은 네 가지로 좁혀집니다.

1. 예약 한 건의 최신 상태를 한 곳에 둔다 — 인원 변경, 항공 변경, 입금 여부가 같은 화면에서 갱신됩니다.
2. 출발 전에 해야 할 일을 시간에 걸어 둔다 — 서류 안내, 잔금 안내, 출발 안내가 날짜 기준으로 뜹니다.
3. 같은 정보를 두 번 옮겨 적지 않게 한다 — 예약 정보가 명단, 일정표, 견적서로 자동으로 흐릅니다.
4. 담당자가 아니어도 읽을 수 있게 만든다 — 인수인계가 파일 전달이 아니라 권한 부여로 끝납니다.

반대로 말하면, 이 네 가지에서 문제가 없다면 굳이 도구를 바꿀 이유가 없습니다. 기능이 많아서 좋은 게 아니라, 지금 새는 곳을 막아야 좋은 것입니다.

구글 시트로 버틸 수 있는 한계는 어디인가

단체·패키지를 취급하는 곳에서 시트가 실제로 깨지는 지점은 대체로 아래 다섯 곳입니다. 기능 부족 때문이 아니라, 시트에는 "누가 언제 무엇을 바꿨는지"와 "아직 안 한 일"을 담을 자리가 없기 때문입니다.

지금 바꿔야 하는지 10분 만에 판정하는 표

도구를 바꾸는 결정은 감으로 하면 대체로 늦습니다. 아래 8개 항목에 해당하는 개수를 세면 됩니다. 지난 3개월 동안 한 번이라도 실제로 벌어진 일만 셉니다.

• 0~3점 — 시트를 정리하는 편이 더 싸게 끝납니다. 열 이름 통일과 필터 뷰만 손봐도 대부분 해결됩니다.
• 4~8점 — 안내 발송 한 가지만 먼저 도구로 넘깁니다. 전면 교체는 아직 이릅니다.
• 9점 이상 — 이미 사고가 난 상태입니다. 무료 기간에 실제 예약 한 건을 끝까지 굴려 보는 단계로 넘어가야 합니다.

대형 ERP · 시트 · 중간 도구는 무엇이 다른가

여행사가 실제로 놓인 선택지는 세 개입니다. 기능 개수가 아니라 도입에 드는 시간과 바꿀 때의 비용이 갈립니다.

규모가 큰 곳은 맞춤 개발이 필요하니 대형 ERP가 맞습니다. 예약이 월 몇 건인 곳은 시트가 맞습니다. 문제는 그 사이입니다. 시트로는 새기 시작했는데 대형 ERP를 들이기엔 규모와 기간이 부담인 구간이 가장 넓고, 그 구간을 위한 선택지가 오래 비어 있었습니다.

비용은 사람 시간으로 환산해야 판단이 선다

월 구독료를 금액으로만 보면 비교가 안 됩니다. 몇 시간을 줄이면 본전인지로 바꾸면 바로 판단이 섭니다. 시간당 인건비를 15,000원으로 잡고 계산해 보겠습니다.

그 16분이 어디서 나오는지가 진짜 질문입니다. 월 예약 300건, 출발 건수 40건 규모를 기준으로 잡으면 대체로 이렇게 흩어져 있습니다.

이 중 절반만 자동으로 넘어가도 21시간입니다. 손익분기 5.93시간의 3배가 넘습니다. 반대로 월 예약이 30건 이하라면 같은 계산이 4.5시간 근처로 떨어져 도입 효과가 잘 안 보입니다. 규모가 판단 기준인 이유가 여기 있습니다.

고를 때 확인할 7가지 — 기본

영업 자료에는 잘 안 적히지만, 도입 후 만족을 가르는 항목들입니다.

1. 예약을 손으로 다시 입력해야 하는지. 예약 시스템에서 자동으로 들어오지 않으면 일이 줄지 않고 늘어납니다. 어느 시스템과 어떤 방식으로 연동되는지 이름으로 확인합니다.
2. 출발 전 할 일이 날짜에 걸리는지. 목록만 보여주는 도구와, 날짜가 되면 먼저 알려주는 도구는 다릅니다.
3. 명단·일정표·견적서가 예약에서 자동으로 나오는지. 같은 정보를 다시 타이핑하는 구간이 남아 있으면 결국 시트로 돌아갑니다.
4. 여권 정보를 사람이 안 읽어도 되는지. 사본에서 이름·번호·만료일이 자동으로 올라오는지, 만료일 경고가 있는지 봅니다.
5. 권한을 사람 단위로 나눌 수 있는지. 정산 금액은 대표만, 예약은 담당자만 보는 구분이 되는지 확인합니다.
6. 데이터를 내 것으로 꺼낼 수 있는지. 엑셀 내보내기가 되는지, 해지 후에도 받을 수 있는지 미리 물어봅니다.
7. 먼저 써 보고 결정할 수 있는지. 무료 기간에 실제 진행 중인 예약 한 건을 끝까지 굴려 봐야 압니다. 데모 데이터로는 안 보입니다.

고를 때 확인할 5가지 — 계약서에 안 적히는 것

도입 6개월 차에 문제가 되는 항목들입니다. 계약 전에 물어보면 답을 받을 수 있고, 도입 후에는 대체로 못 바꿉니다.

1. 동기화가 멈췄을 때 알려 주는가. 실패는 대체로 조용합니다. 마지막 성공 시각과 어제 처리 건수를 화면에 띄워 주는지 확인합니다.
2. 취소된 예약에 안내가 안 나가게 막는 장치가 있는가. 취소 고객에게 출발 안내가 나가면 그 한 번으로 관계가 끝납니다. 발송 직전 상태를 다시 확인하는 구조인지 물어봅니다.
3. 여권번호가 화면에 그대로 보이는가. 권한 그룹별 마스킹과 조회 이력 기록이 되는지 확인합니다. 직원이 늘어난 뒤에 붙이려면 늦습니다.
4. 고객 데이터가 외부로 나가는가. 외부 언어모델이나 제3자 서비스로 고객 정보를 보내는 기능이 있는지, 끌 수 있는지 명시적으로 확인합니다.
5. 사용량 한도가 어디서 걸리는가. 예약 건수, 문서 인식 장수, 발송 건수마다 플랜별 한도가 있습니다. 성수기 기준으로 계산해야 합니다.

예약 자동 동기화는 실제로 어떻게 도는가

"연동됩니다"라는 한 줄 뒤에는 대체로 이런 구조가 있습니다. 실제 운영 중인 워크스페이스에서 측정한 수치로 설명하겠습니다.

가장 오래 걸리던 구간은 예약 자체가 아니라 승객 연락처를 다시 긁어오는 부분이었습니다. "빈칸이 하나라도 있으면 다시 조회"로 판정하면 93건 중 55건이 대상이 됩니다. 부부·가족은 대표 한 명에게만 번호를 두는 것이 정상이라 영영 안 채워질 빈칸을 매번 다시 긁게 됩니다. 판정 기준을 "번호가 하나도 없는 예약"으로 바꾸자 대상이 4건으로 줄었고, 외부 호출은 115건에서 4건이 됐습니다. 같은 기능이라도 판정 기준 한 줄이 소요 시간을 가릅니다.

자동화가 조용히 멈추는 3가지 실패 모양

도입 후 실제로 겪는 사고는 "화면이 안 뜬다" 같은 시끄러운 고장이 아닙니다. 아무 일도 안 일어나는데 아무도 모르는 형태입니다.

취소는 언제 몰리는가 — 실측 77건

안내 자동화를 설계할 때 가장 많이 나오는 걱정이 "취소된 손님한테 문자가 나가면 어떡하나"입니다. 실제 분포를 보면 어디를 막아야 하는지가 분명해집니다. 취소된 예약 77건을 출발일까지 남은 일수로 분류한 결과입니다.

임박 취소가 0건이라는 사실 하나로 두 가지가 정해집니다. 첫째, 동기화 주기를 3시간으로 두어도 안전합니다. 취소 직후 최대 3시간 동안 시스템이 아직 확정 상태로 보고 있어도, 그 사이에 안내가 나갈 확률이 실적상 극히 낮습니다. 둘째, D-15 안내가 가장 먼저 효과를 보는 자동화입니다. 취소의 83.1%가 그 이전에 들어오므로 대상이 이미 정리된 뒤에 나갑니다.

여권·명단 처리에서 시간이 나오는 지점

인원이 20명을 넘는 단체에서 가장 먼저 무너지는 것이 여권 확인입니다. 확인 항목은 셋뿐인데, 사람이 하면 매번 파일을 열어야 합니다.

• 영문 이름이 항공 예약과 같은가 — 한 글자만 달라도 탑승이 막힙니다
• 잔여 유효기간이 6개월 이상인가 — 입국 요건이 국가마다 다르지만 6개월이 안전선입니다
• 여권번호가 명단에 정확히 옮겨졌는가 — 손으로 옮기면 오타가 납니다

사본에서 이름·번호·만료일이 자동으로 올라오면 200장 기준 6.7시간이 사라집니다. 다만 문서 인식은 플랜별 장수 한도가 걸리는 대표적인 기능입니다. 월 100장 한도인 플랜에서 성수기에 200장을 처리해야 한다면 계산이 달라지니 성수기 기준으로 한도를 확인해야 합니다.

여권번호는 개인정보 중에서도 민감도가 높습니다. 권한 그룹별 마스킹과 조회 이력 기록이 되는지, 그리고 그 정보가 외부 서비스로 나가지 않는지를 계약 전에 확인해 두는 편이 안전합니다.

기존 데이터는 어떻게 옮기나 — 4주 계획

이관에서 실패하는 이유는 거의 하나입니다. 과거 데이터를 전부 옮기려고 하기 때문입니다. 진행 중인 예약만 옮기고 지난 예약은 시트를 그대로 두면 대부분 해결됩니다. 일괄 이전이 꼭 필요하면 1회성 스크립트를 쓰고, 이 방식으로 2,500건 이상을 한 번에 옮긴 사례가 있습니다.

1. 진행 중인 예약만 옮깁니다. 아직 출발하지 않은 건만 새 도구에 넣습니다.
2. 지난 예약은 시트를 그대로 둡니다. 조회용으로 남겨 두면 충분합니다.
3. 한 달은 두 개를 같이 씁니다. 새 도구가 실제로 굴러가는지 확인되기 전에 시트를 지우지 않습니다.
4. 안내 발송부터 넘깁니다. 가장 먼저 효과가 보이고, 틀려도 되돌리기 쉽습니다.
5. 마지막에 권한을 나눕니다. 초기에 나누면 아무도 아무것도 못 하는 상태가 됩니다.

도입 후 30일 점검표

도입은 계약이 아니라 30일 뒤의 상태로 판단합니다. 아래 항목이 전부 예가 되면 성공한 것이고, 두 개 이상이 아니오면 원인을 찾아야 합니다.

• 예약 정보를 시트에 다시 옮겨 적는 일이 사라졌다
• 출발 전 안내가 누락된 건이 0건이다
• 담당자가 아닌 사람이 예약 상태를 답할 수 있다
• 여권 확인 때문에 파일을 여는 횟수가 줄었다
• 마지막 동기화 시각을 어디서 보는지 직원 전원이 안다
• 취소 건에 안내가 나간 사례가 0건이다
• 월말 정산에서 건별 대조에 쓰는 시간이 줄었다
• 이번 달 사용량이 플랜 한도의 80% 아래다

요금은 한도 기준으로 비교합니다

월 구독형 도구는 금액보다 한도에서 갈립니다. 같은 금액이라도 성수기에 한도가 먼저 걸리면 실제 비용은 달라집니다. 비교할 때 아래 다섯 개를 같은 표로 만들어 두면 됩니다.

연 결제로 20% 정도 낮아지는 구조가 일반적이지만, 첫 해에는 월 결제를 권합니다. 한도가 우리 성수기에 맞는지는 한 시즌을 돌려 봐야 알 수 있고, 그 전에 1년치를 묶으면 한도가 안 맞았을 때 선택지가 사라집니다.

도입에 실제로 걸리는 시간

"수 일"이라는 표현은 범위가 너무 넓습니다. 셀프 방식으로 시작하는 경우의 실제 소요는 이렇습니다.

여기서 시간을 잡아먹는 건 입력이 아니라 자료를 찾는 시간입니다. 사업자등록증, 로고 파일, 예약 시스템 자격증명, 드라이브 폴더, 직원 명단을 먼저 한 폴더에 모아 두면 30분 쪽에 붙고, 그때그때 찾으면 60분을 넘깁니다.

자주 묻는 질문