웹사이트로 문의가 들어오지 않는 이유는?

페이지가 아니라 경로를 순서대로 점검하기

아무것도 오지 않을 때 사람들은 페이지를 다시 쓰고 싶어집니다. 제목을 바꾸고, 버튼을 키우고, 양식 옆에 후기를 넣습니다. 그러나 그것은 가장 마지막에 바꿀 일입니다. 완전한 침묵을 만드는 고장은 거의 언제나 기계적인 것이고, 이쪽에서 보면 기계적 고장과 설득의 실패는 똑같은 모습, 즉 비어 있는 받은편지함으로 보이기 때문입니다. 차이는 모양에 있습니다. 설득이 서툰 페이지도 가끔은 문의를 만들어 냅니다. 양식이 아무 데도 보내지 않는 페이지는 글이 아무리 좋아져도 영원히 정확히 0입니다.

1. 양식이 어딘가로 전송되기는 하는가 로컬 미리보기나 편집기의 미리보기 창이 아니라 게시된 URL을 열고, 브라우저 네트워크 패널을 연 채로 양식을 작성해 제출해 보세요. 찾는 것은 페이지에서 나가서 성공 상태로 돌아오는 요청 하나입니다. 아무것도 나가지 않는다면 그 양식은 장식입니다. 생성된 페이지에서는 충분히 흔한 일이라 확인 목록의 맨 앞에 둘 만합니다. 이 계열의 결함은 AI로 웹사이트를 만들어도 될까에 더 정리해 두었습니다.
2. 전송된 내용에 항목 이름이 실려 있는가 양식은 성공적으로 전송되고도 빈 채로 도착할 수 있습니다. 보내는 입력 칸에 이름이 붙어 있지 않기 때문입니다. 알아볼 수 있는 문장을 입력해 제출하고, 무언가가 도착했는지가 아니라 실제로 무엇이 도착했는지를 보세요. 항목이 비어 있는 알림은 받은편지함이 아니라 마크업의 문제이며, 한 통 읽어 보기 전까지는 드러나지 않습니다.
3. 메일이 실제로 발송되었는가 모두가 건너뛰는 단계입니다. 양쪽에서 보이지 않기 때문입니다. 사이트는 메일을 넘겼다고 믿고, 당신은 반송을 한 번도 보지 못합니다. 메일 서비스 자체의 발송 기록을 열고 테스트 시각을 찾아보세요. 거기에 아무 줄도 없다면 발송된 적이 없는 것이고, 스팸함을 둘러싼 모든 추리는 헛수고입니다.
4. 도착했는가, 그리고 어디에 떨어졌는가 사이트가 발송에 쓰는 곳과 다른 서비스의 주소로 보내 보고, 스팸함과 프로모션함, 그리고 몇 년 전에 만들어 두고 잊어버린 필터 규칙이나 공용 수신함을 확인하세요. 같은 도메인에서 같은 도메인으로 가는 메일은 나름의 방식으로 깨지기 때문에, 그 경로만 시험하면 다른 모든 사람이 겪는 문제를 가릴 수 있습니다.
5. 방문자가 진짜 사람인가 아무도 관심이 없다고 결론짓기 전에, 들어오는 쪽이 사람인지 확인하세요. 봇과 링크 미리보기, 가동 확인 점검은 모두 세션으로 기록되지만 그중 무엇도 양식을 채우지 않습니다. 그래서 페이지는 붐벼 보이면서 비어 있을 수 있습니다. 그 숫자를 정직하게 읽는 법은 웹사이트에 트래픽이 없는 이유에 있습니다.

감사 페이지는 영수증이 아니다

완료 화면은 인터페이스의 상태일 뿐입니다. 대부분의 구현에서 그것은 브라우저가 요청을 끝냈기 때문에 나타나는 것이지, 무언가가 저장되거나 발송되었기 때문이 아닙니다. 즉 문의가 이미 사라진 뒤에도 그 화면은 떠 있을 수 있습니다. 이것은 시험으로 우회할 것이 아니라 설계로 없애야 할 틈입니다. 가장 확실하게 속는 사람이 방문자 본인이기 때문입니다. 연락했다고 믿고 다시 시도하기를 그만두며, 당신은 그가 시도했다는 사실조차 알지 못합니다.

우리는 고객이 게시하는 페이지를 직접 호스팅하기 때문에, 문의를 기록하지 못했을 때 우리 문의 엔드포인트가 무엇을 반환할지 정해야 했습니다. 오류를 반환합니다. 저장하지 못한 메시지에 대해서는 확인 화면을 띄우지 않습니다. 거짓 확인이 눈에 보이는 실패보다 나쁘다는 전제 때문입니다. 눈에 보이는 실패라면 방문자에게 대신 이메일을 보낼 선택지라도 남습니다. 직접 백엔드를 다룬다면 같은 선택을 하고, 쓰기가 성공한 뒤에만 감사 인사를 하세요. 호스팅형 양식 서비스를 쓴다면 테스트를 보내고, 페이지가 바뀌었다는 사실이 아니라 그 서비스의 대시보드에 항목이 나타나는지를 확인하세요.

아무도 보지 않는 단계: 메일이 아예 나가지 않았다

이 문제의 가장 선명한 사례는 고객의 사이트가 아니라 우리 사이트에 있었습니다. 하루 100통이 상한인 메일 요금제를 쓰고 있었는데, 마침내 들여다본 날 계수기는 99를 가리키고 있었습니다. 그 이상은 서비스 쪽에서 거부되고 있었습니다. 반송은 하나도 없었습니다. 반송은 메일이 일단 수락되어 발송되었어야 생기는 것인데, 이 메일들은 수락된 적조차 없었으므로 읽을 반송도, 누군가의 스팸함에서 찾아낼 무언가도 없었습니다.

여기서 훔쳐 갈 만한 세부가 둘 있습니다. 거부는 403으로 돌아왔습니다. 자격 증명이 망가졌다고 읽게 되는 상태 코드이지, 속도 제한에서 예상할 429가 아닙니다. 그러니 상태 코드만으로 분류하면 엉뚱한 원인을 쫓게 됩니다. 더 나쁜 쪽은 이렇습니다. 우리 경로 중 하나는 낯선 사람이 발송 실패를 단서로 어떤 이메일 주소가 계정을 갖고 있는지 알아내지 못하도록, 발송 오류를 일부러 삼킵니다. 그 경로는 한 번도 보내진 적 없는 메일에 대해 "받은편지함을 확인하세요"라는 밝은 페이지를 계속 돌려주었습니다. 두 세부가 가르치는 것은 같습니다. 애플리케이션의 성공 메시지는 당신의 코드가 무엇을 시도했는지를 설명할 뿐, 서비스가 무엇을 했는지가 아닙니다. 그리고 서비스의 응답을 지켜보는 것이 없다면 둘은 며칠이고 어긋난 채로 있을 수 있습니다. 이 일이 있기 전에는 발송 실패 알림이 없었고, 지금은 있습니다.

장치는 작동하는데 여전히 조용할 때

테스트 문의가 끝까지 도달하는 것을 확인하고 나면 남는 설명은 평범한 것들이고, 다루기는 훨씬 쉬워집니다. 돌아오는 반응을 마침내 믿을 수 있기 때문입니다. 가장 흔한 것은 적합한 사람이 아직 충분히 오지 않았다는 것입니다. 공개된 지 한 달, 유입 링크가 없는 페이지의 독자는 아무도 없고, 양식을 고친다고 달라지지 않습니다. 그다음으로 흔한 것은 요청 자체입니다. "문의하기"는 다음에 무슨 일이 생길지 모르는 낯선 사람에게 열린 대화를 시작하라고 청하는 일이며, 보기보다 큰 부탁입니다. 대신 구체적인 것을 내미는 편이, 이를테면 특정한 질문이나 가격대나 시간 선택지가, 대개 항목 하나의 비용으로 개편보다 숫자를 더 움직입니다. 그 뒤의 이야기는 방문자를 가입으로 바꾸는 법에 있습니다.

기억할 가치가 있는 것은 순서입니다. 전달을 검증하고, 그다음 트래픽을 읽고, 그다음 제안을 바꾸세요. 아무 데도 보내지 않는 양식 위에서 제목을 다시 쓰는 한 시간은 원리적으로 성과를 낼 수 없기 때문입니다. 이 순서는 우리가 AgentCeres — agentceres.com의 AI 그로스 책임자 — 를 만드는 방식이기도 합니다. 전문가 팀이 페이지와 게시물과 아웃리치 초안을 쓰고, 밖으로 나가는 것은 사람이 승인하며, 고객의 메시지를 실어 나르는 부분은 괜찮겠거니 하지 않고 시스템이 점검합니다.