장애 안내 페이지

쉽게 말하면

손님이 문의를 보내는 이유는 화가 나서가 아니라 모르기 때문이에요. 내 쪽 문제인지, 언제 되는지, 내 주문은 어떻게 되는지를 알려 줄 곳이 없으면 유일한 방법이 문의예요. 안내 한 장은 그 문의를 미리 대신 답해 두는 일이에요.

안내가 문의를 줄이는 방식

안내문이 문의를 줄이는 건 착한 문장 때문이 아니에요. 손님 머릿속의 질문 네 개를 먼저 답해 버리기 때문이에요. 네 개 중 하나라도 비면 그 질문이 문의로 들어와요.

같이 죽지 않는 곳에 둬야 해요

이 문서에서 하나만 가져간다면 이 절이에요. 안내 페이지의 값어치는 고장 났을 때 열린다는 것 하나에서 나와요. 내 서비스 안에 만들어 두면, 내 서비스가 죽는 순간 안내도 같이 죽어요.

1. 1안내 페이지를 본 서비스와 다른 곳에 둬요. 다른 주소, 다른 호스팅, 또는 상태 안내 전용 서비스면 돼요. 같은 서버·같은 프로젝트 안에 두면 안내가 아니라 장식이에요.
2. 2글자만 있는 한 장으로 만들어요. 데이터베이스·로그인·결제·외부 연동을 하나도 쓰지 않아야 해요. 무거운 안내 페이지는 사람이 몰릴 때 같이 느려져요.
3. 3주소를 평소에 알려 둬요. SNS 소개란, 주문 완료 문자, 안내 메일 아래에 그 주소를 미리 박아 둬요. 사고 중에 새 주소를 알리려면 알릴 통로 자체가 막혀 있어요.
4. 4평소에는 "모두 정상" 한 줄만 떠 있게 둬요. 평소 아무것도 없던 페이지는 사고 때 손님이 신뢰하지 않아요.
5. 5장애 때는 그 한 장의 글자만 바꿔요. 새로 만드는 게 아니라 고쳐 쓰는 거예요. 3분 안에 끝나야 쓸 수 있는 장치예요.

한 장에 무엇을 적나

안내문은 창작이 아니라 칸 채우기예요. 칸을 미리 만들어 두면 당황한 상태에서도 3분에 끝나요. 사고 났을 때 문장을 새로 고민하면 그 시간에 문의가 쌓여요.

등급을 세 칸으로 나눠요

안내문의 톤은 사고 크기에 따라 달라야 해요. 다 똑같이 심각하게 쓰면 손님이 다음부터 안 읽고, 다 똑같이 가볍게 쓰면 진짜 큰 사고가 묻혀요. 칸 세 개면 충분해요.

가장 판단이 어려운 건 두 번째예요. 열 명 중 한 명만 실패하는 상태에서는 사장님이 눌러 보면 잘 되니까요. 이 판단을 사람 감이 아니라 살아 있나 감시하기와 에러 자동 수집에 맡겨 두면, 안내를 올릴지 말지가 숫자로 결정돼요.

게시한 다음이 진짜 일이에요

안내 페이지의 실패는 대개 게시 순간이 아니라 그 뒤의 침묵에서 생겨요. 한 번 올리고 두 시간을 방치하면 손님은 사장님이 손을 놨다고 읽어요. 갱신 리듬을 미리 정해 두면 이 문제가 사라져요.

1. 1첫 안내는 원인을 몰라도 올려요. "확인 중이에요"까지만 알아도 올릴 수 있어요. 원인을 알고 나서 올리려면 늘 늦어요.
2. 2정한 간격으로 갱신해요. 진행이 없어도 "아직 확인 중이에요"를 올려요. 진행 없음도 정보예요.
3. 3복구되면 복구를 알려요. 이 한 줄이 빠져서 손님이 계속 안 되는 줄 아는 경우가 많아요. 안내를 내리는 것과 복구를 알리는 것은 다른 일이에요.
4. 4사고 시간대의 주문·결제·문의를 따로 확인해요. 화면이 돌아온 것과 장부가 맞는 것은 다른 이야기예요. 순서는 사고가 났을 때에 있어요.
5. 5끝난 안내를 지우지 말고 남겨요. 지난 사고 기록이 쌓인 페이지는 감출 흠이 아니라 신뢰 자산이에요. 기업 손님은 이 목록을 보고 계약을 판단해요.

사장님이 실제로 겪는 장면

자주 묻는 것

Q. 손님이 하루 열 명인데 이것까지 만들어야 하나요?

지금은 SNS 고정글 하나로 충분해요. 필요해지는 신호는 규모가 아니라 상황이에요. 돈이 오가기 시작했을 때 · 손님이 예약 시간에 맞춰 찾아올 때 · 기업 손님이 붙었을 때. 이 셋 중 하나가 오면 만드세요. 만들어 두면 다음 사고마다 계속 값을 해요.

Q. 전문 상태 안내 서비스를 써야 하나요, 직접 만들어도 되나요?

판단 기준은 하나예요. 내 서비스와 함께 죽지 않는가. 이 조건을 만족하면 직접 만든 한 장으로도 충분해요. 전문 서비스의 장점은 이력 관리와 손님 구독 알림이라, 기업 손님이 붙기 전까지는 급하지 않아요.

Q. 안내를 올리면 고장이 잦다는 인상을 주지 않을까요?

손님이 나쁘게 기억하는 건 고장이 아니라 숨긴 것이에요. 고장은 어차피 손님이 먼저 겪어요. 그때 안내가 없으면 "고장 + 방치"로 기억되고, 안내가 있으면 "고장 + 관리되는 곳"으로 기억돼요. 같은 사고가 다른 평판이 돼요.

Q. 안내문을 매번 새로 쓰기가 어려워요.

매번 쓰지 마세요. 등급 세 개에 대해 빈칸 뚫린 문장을 미리 만들어 두면 시각과 기능 이름만 채워 넣으면 돼요. 응대 문구를 미리 만들어 두는 방법은 응대 표준 문구와 같은 요령이에요.

Q. 예정된 점검은 며칠 전에 알려야 하나요?

정해진 규칙은 없고 손님 종류에 따라 달라요. 판단 기준은 손님이 계획을 바꿀 수 있는 시간이에요. 예약 손님이 있는 서비스라면 예약 가능한 기간보다 앞서 알려야 의미가 있어요. 기업 손님과 약속한 통지 기간이 계약서에 있으면 그게 우선이에요.

Q. 안내 페이지와 사고 대응 순서는 뭐가 다른가요?

사고가 났을 때는 사장님이 무엇을 할지의 순서이고, 이 문서는 그 순서 안의 "손님에게 알리기" 한 칸을 어디에 어떻게 두는지예요. 대응 순서가 뼈대면 안내 페이지는 그 뼈대에 걸어 두는 도구예요.

Q. 갑자기 손님이 몰려서 느려진 것도 안내를 올려야 하나요?

올리는 게 좋아요. 이때 손님은 고장으로 오해하고 새로고침을 반복해서, 그 반복이 서버를 더 밀어붙여요. "지금 접속이 많아 느려요. 잠시 뒤 다시 열어 주세요" 한 줄이 실제로 부하를 줄여요. 대비는 갑자기 몰릴 때에서 봐요.