데모

제품을 말로만 설명하던 시절에는 미팅이 같은 질문으로만 채워졌습니다. "그것도 되나요" 하고 물으면 "됩니다" 하고 답하고, 다시 "이런 경우에는요" 하고 물으면 "그것도 됩니다" 하고 답했습니다. 40분을 그렇게 쓰고 나면 상대의 머릿속에는 제품의 그림이 하나 생기는데, 그 그림은 실제 제품과 같지 않았습니다.

어긋난 그림은 나중에 값을 치렀습니다. 계약하고 두 주쯤 지나 "이게 이렇게 되는 게 아니었어요" 하는 연락이 옵니다. 파는 쪽은 거짓말을 한 적이 없고 사는 쪽도 잘못 들은 것이 아닙니다. 같은 문장을 서로 다른 화면으로 상상했을 뿐입니다. 이런 거래는 한 해를 채우지 못하고 끊깁니다.

데모는 그 상상을 없애려고 파이프라인 안에 자리를 하나 만든 것입니다. 상대가 제품을 그리는 대신 보게 만들면, 되는 것과 안 되는 것이 그 자리에서 드러납니다. 안 되는 것이 드러나 거래가 깨지는 일도 생기지만, 그 편이 계약 두 달 뒤에 깨지는 것보다 양쪽에 싸게 끝납니다.

30분에서 45분 사이의 화면 공유 미팅이고, 파는 쪽이 화면을 운전하며 상대의 상황을 하나씩 대입해 보는 자리입니다.

앞뒤 단계와 비교하면 성격이 뚜렷합니다. 고객의 상황을 묻는 첫 상담인 디스커버리 콜이 듣는 자리라면 데모는 보여 주는 자리이고, 뒤에 오는 제안서가 문서로 남기는 자리라면 데모는 문서 없이 화면으로만 진행됩니다.

진행은 대개 네 토막입니다.

1. 첫 5분은 지난 상담에서 들은 문제를 되짚습니다. "지난번에 문서를 찾는 데 주당 두 시간쯤 쓴다고 하셨죠" 하고 확인하고 시작합니다. 이 확인을 건너뛰면 남은 35분이 일반적인 기능 소개가 됩니다.
2. 다음 20분이 본체입니다. 그 문제와 직접 닿는 화면만 씁니다. 기능이 서른 개 있어도 넷만 보여 주고, 나머지는 물어볼 때 꺼냅니다.
3. 그다음 10분은 상대의 실제 자료를 넣어 봅니다. 미리 받아 둔 문서 몇 건이나 조직 구조를 넣으면 그림이 달라집니다. 시연용 예시 데이터로만 진행한 데모는 잘 흘러가도 기억에 남지 않습니다.
4. 마지막 5분은 다음에 할 일을 정합니다.

참석자 구성이 이 자리의 성격을 크게 바꿉니다. 실무 담당자 혼자 오면 대화가 쓰기 편한지에 머물고, 기술 검토자가 함께 오면 연동과 권한 질문이 쏟아집니다. 뒤쪽이 예상되면 기술 질문에 답하고 제품을 시연하는 세일즈 엔지니어가 같이 들어갑니다. 영업 담당자가 모르는 답을 추측해서 말하면 그 한 문장이 남은 거래 전체의 신뢰를 깎습니다.

화면을 다 보여 준 것으로는 넘어가지 않습니다. 넘어간 상태는 아래 셋이 확인된 상태입니다.

1. 남은 기술 질문이 없습니다. 답을 미룬 항목이 있으면 목록으로 적고 언제까지 회신하겠다고 말한 뒤, 회신한 다음에 다음 단계를 엽니다.
2. 결정에 관여하는 사람이 파악됐습니다. 이 자리에 온 사람이 혼자 결정하는지, 위에 승인이 필요한지, 보안 검토가 따로 붙는지를 묻습니다.
3. 다음 일정이 날짜로 잡혔습니다. 제안서를 언제까지 보내고 언제 함께 볼지가 정해져야 합니다.

셋 중 둘째가 가장 자주 빠집니다. 데모가 잘 끝나면 분위기가 좋아서 묻기가 머쓱해지는데, 그 질문을 빼놓으면 다음 두 주 동안 상대가 조용해진 이유를 알 수 없습니다. 승인 절차가 돌고 있는 것과 관심이 식은 것이 같은 침묵으로 보입니다.

다음 단계는 제안서이고, 그 뒤로 가격과 조건을 맞추는 협상과 계약을 매듭짓는 클로징이 옵니다. 데모에서 확인한 범위가 제안서에 적히는 범위와 같아야 합니다. 화면에서 보여 준 것보다 좁게 적으면 뒤에서 항의가 나오고, 넓게 적으면 도입 후에 못 지키는 약속이 됩니다.

"데모 잡기 전에 그쪽 문서 샘플 몇 개 받아 둘 수 있을까요?"

상대 자료를 넣어 진행하려고 준비물을 챙기는 말입니다.

"이번 데모는 세일즈 엔지니어 없이는 안 될 것 같아요. 연동 질문이 많을 겁니다."

기술 질문의 양을 미리 보고 인원을 붙이겠다는 판단입니다.

"데모까지 갔는데 제안서 단계로 안 넘어가는 건이 이번 달에 네 건이에요."

특정 단계에서 거래가 멈춘다는 신호이고, 데모 진행 방식을 고쳐야 한다는 뜻입니다.

페이지덱에서는 수아가 데모를 잡을 때 두 가지를 먼저 받아 둡니다. 상대 회사의 팀 구조와 지금 쓰는 도구입니다. 그리고 태오에게 부탁해 시연용 계정에 그 구조를 미리 만들어 둡니다. 부서 이름과 문서 제목이 자기 회사 것으로 보이면 상대가 질문하는 방식이 달라집니다.

잘 안 되는 데모에도 모양이 있습니다. 수아가 첫 5분을 건너뛰고 바로 화면을 열면, 상대는 기능을 구경하다가 마지막에 "좋네요, 검토해 보겠습니다" 하고 끝냅니다. 검토할 대상이 자기 문제와 이어지지 않았기 때문에 그 검토는 시작되지 않습니다.

데모를 기능 소개 시간으로 여기는 경우가 가장 많습니다. 제품을 보여 주는 자리이니 많이 보여 주는 쪽이 성실한 것처럼 느껴집니다. 하지만 상대가 기억하는 화면은 두세 개뿐입니다. 서른 개를 훑으면 그중 자기 문제에 닿는 것이 무엇이었는지 고르지 못한 채 미팅이 끝나고, 그 상태에서는 내부에 설명할 문장이 생기지 않습니다. 넷만 보여 주고 그 넷이 상대의 주당 두 시간을 어떻게 줄이는지 짚어 주는 편이 다음 단계로 잘 넘어갑니다.

깔끔한 화면만 보여 줘야 한다고 생각하는 것도 흔합니다. 오류가 나거나 느려지면 신뢰가 깨질 것 같아 안전한 경로만 밟습니다. 그런데 실무에서 쓰는 사람이 궁금한 것은 잘 될 때가 아니라 어긋날 때입니다. 자료가 5천 건이면 검색이 느려지지 않느냐는 질문에 그 상태를 직접 열어 보여 주는 쪽이, 문제없다고 말로 답하는 쪽보다 훨씬 강하게 남습니다. 안 되는 것을 안 된다고 말하는 것도 같습니다. 그 자리에서 드러난 한계는 계약 뒤에 드러난 한계보다 값이 싸게 끝납니다.