1P by GN⁺ | ★ favorite | 댓글 1개
  • 새 SaaS 제품을 가볍게 시험해 보려는 순간부터 영업 이메일, 메일링 리스트, 반복 통화 요청이 이어지며 사용자의 시간이 계속 잠식됨
  • 구매 흐름은 정작 필요한 한두 기능보다 정해진 데모와 “everything platform”식 설명에 끌려가고, 영업 담당자와 세일즈 엔지니어가 통화를 늘림
  • 결제 승인 단계에서는 상위 의사결정권자를 통화에 끌어들이려는 압박이 커지며, 내부 승인에는 보통 최소 한 달, Fortune 500에서는 모든 것이 잘돼도 최소 3개월이 걸림
  • 구매 후에는 영업 담당자가 사라지고 LLM 기반 고객지원, 긴 SLA, 문서화되지 않은 한계와 실패 모드가 실제 사용자에게 남음
  • 계정 담당자는 문제 해결보다 추가 기능 판매에 집중하고, 결국 더 빠르고 무료인 오픈소스 대안이 등장하면 계약 갱신 중단과 이메일 이별로 끝남

체험판 뒤에 따라붙는 연락

  • 새 서비스나 제품을 시험해 볼 때 가장 큰 장벽 중 하나는 이후 이어지는 지속적인 연락
  • 처음에는 “질문이 있으면 알려 달라”는 무해한 이메일로 시작하지만, 곧 “customer success fun-gineer” 같은 담당자가 체험판 경험을 확인하자며 연락함
  • 사용자는 대개 특정 기능 하나를 확인하려고 가입함
    • 그 기능이 없으면 관심을 접고 잊어버림
    • 아직 평가 중인 경우가 아니면 왜 연락이 오는지 알기 어려움
  • 메일링 리스트에 남으면 새 릴리스와 출시 알림을 계속 받게 됨
    • 관심이 없더라도 원하는 기능이 추가됐을 가능성 때문에 구독 해지를 매번 고민함
    • 접근 가능한 릴리스 노트가 없으면 마케팅 이메일이 기능 추가 여부를 확인하는 유일한 경로처럼 됨

“통화 한번 하시죠”로 바뀌는 구매 흐름

  • 최악의 경우는 실제로 서비스를 쓸 수 있을 때이며, 이때부터 일련의 통화 일정에 묶임
  • 웹사이트에 신용카드 번호를 입력하면 끝나는 대신 Microsoft Teams에서 낯선 사람들과 관계를 만들어야 함
  • 전형적인 SaaS 영업팀에는 두 역할이 등장함
    • 영업 담당자는 CRM에 데이터를 입력하며 판매 성사까지 계속 밀어붙임
    • “sales engineer”, “customer success engineer” 같은 직함의 담당자는 문서를 실제로 읽은 몇 안 되는 사람으로, 제품을 새로운 “everything platform”처럼 설명함
  • 데모는 사용자가 원하지 않는 기능까지 포함함
    • 사용자는 한두 기능만 확인하려고 왔지만 정해진 데모 템플릿은 유연하지 않음
    • 영업 담당자는 사용자가 기술적이라는 식의 가벼운 칭찬으로 분위기를 누그러뜨리려 함
  • 세일즈 엔지니어의 데모는 좋지 않은 순간에 깨지고, 뒤이어 “보통은 잘 된다”는 해명이 나옴

보안·컴플라이언스와 길어지는 승인

  • 어느 시점에 컴플라이언스와 보안을 물으면 의미 없는 인증서 묶음이 전달됨
  • 인증 문서는 실제로 항목을 수행했다는 증거라기보다 그럴듯하게 수행한 것처럼 보일 수 있음을 보여주는 수준으로 다뤄짐
  • 데모와 관계 형성이 끝나면 영업팀은 사용자의 상위 의사결정권자를 통화에 참여시키려 함
  • 의사결정권자는 여러 회사의 영업 피치를 매주 듣고 싶어 하지 않기 때문에, 제안서를 정리하는 일은 사용자에게 넘어감
  • 사용자가 제품을 정말 중요하게 생각하면 내부 승인에 필요한 사람들을 직접 접촉해야 함
    • 이 과정은 최소 한 달 걸림
    • Fortune 500 회사에서는 모든 것이 완벽히 진행돼도 최소 3개월 걸림
  • 시간을 아끼려던 제품 도입이 큰 프로젝트가 되면서, 사용자는 차라리 직접 도구를 역공학했어야 했는지 고민하게 됨

구매 후 남는 한계와 고객지원

  • 승인이 끝나고 돈이 오가면 영업 담당자는 사라지고, 사용자는 Customer Service, 즉 LLM에게 넘겨짐
  • “limitless, cloud-based platform”은 실제 사용 중 여러 한계를 드러냄
    • 어느 날은 정상 동작함
    • 다음 날에는 보이지 않는 임계값을 넘기고 전체 흐름이 무너짐
  • 문서는 장점을 강조하도록 정리돼 있어 경고나 한계를 찾기 어려움
  • LLM 고객지원은 같은 문서 링크를 반복해서 제시하고, 이후에야 실제 사람에게 이메일을 보낼 수 있음
  • 지원 이메일의 SLA는 72 business hours처럼 길며, Super Enterprise Plan™을 선택하지 않았기 때문으로 처리됨
  • 응답은 보이지 않는 한도에 도달했으니 워크플로를 재구성하라는 식으로 끝남
  • 사용을 계속할수록 문서화되지 않은 실패 모드 목록이 늘어남
    • 예: “두 버튼을 너무 빨리 누르면 iFrame이 오류를 낸다”
    • 스택이 오류를 기록하고 있을 것으로 보이지만, 누구도 연락해 원인을 설명하거나 수정 방법을 돕지 않음

계정 담당자, 추가 판매, 오픈소스와 결별

  • 어느 날 새 계정 담당자(account rep) 가 연락해 제품 사용 방식과 도움을 논의하자며 통화를 요청함
  • 이 통화는 피드백 수집이나 문제 해결보다 또 다른 판매 피치에 가까움
  • 담당자는 문제 목록을 듣고 “살펴보겠다”고 하지만, 실제 목적은 추가 기능 구매 설득으로 드러남
  • 추가 기능은 SSO나 API 접근처럼 판매자에게는 비용이 거의 들지 않지만 사용자에게는 큰 차이를 만드는 항목임
  • 사용자는 제품을 더 사서 기본 기능을 얻을지, 아예 제거하고 다른 길로 갈지 결정해야 함
  • 결국 어떤 오픈소스 개발자가 같은 일을 하는 무료 도구를 만듦
    • 이름은 CodeSquish, Dojo, GitCharm 같은 식으로 우스꽝스러울 수 있음
    • 동료를 통해 알게 되고, 찾아보면 필요한 일을 모두 수행하며 비용이 없고 100배 더 빠름
    • 단 한 명이 유지보수하고 포럼이 Discord 서버뿐이어도 상용 제품보다 훨씬 나음
  • 계약 때문에 이별은 미뤄지지만, 결국 Finance에 갱신하지 말라고 전달함
  • 갱신 중단이 보이면 공급사 팀이 갑자기 많은 관심을 보이고, 오픈소스 도구가 실제로는 열등하다고 설득하려 함
  • 사용자는 “내부에서 논의하겠다”고 말하지만 실제 논의는 하지 않으며, 마지막에는 이메일로 이별을 통보하고 도메인을 차단함

댓글과 토론

Hacker News 의견들
  • 세상의 모든 조언을 거슬러, 글에서 묘사한 거의 모든 상황을 피하도록 설정하려고 하는 중임. 문제는 그런 전술들이 실제로 효과가 있고, 그래서 회사들이 도입한다는 점임
    투자자들도 그런 프로세스를 성숙도의 신호이자 최고 수준의 방식으로 보는 경우가 많음
    반대 접근은 정보를 최대한 투명하게 공개하고 막지 않기, 약점을 먼저 솔직히 말하기, 고객이 사람과 이야기하고 싶을 때 바로 문제를 처리할 수 있는 사람에게 연결하기, 고객이 요청하지 않는 한 AI 상담원이 전화하지 않게 하고 AI임을 즉시 밝히기, 월간/분기/연간/릴리스 노트만 같은 유연한 이메일 구독 옵션을 제공하기, 제품이 맞지 않으면 더 적합한 다른 제품 같은 유용한 대안을 제안하기임
    가치 기반 가격 책정 때문에 많은 회사가 이런 상황에 빠짐. 표준 가격을 두는 대신 고객을 자세히 조사해 제품으로 얻을 가치를 추정하고 그에 따라 가격을 정하는데, 이론상 매출은 극대화되지만 느리고 침습적임
    • 응원하지만, 내 경험상 사람들은 문서를 읽지 않고, 제품이 다루지 못하는 엣지 케이스 하나를 찾으면 경쟁 제품은 기본 경로조차 안 되는데도 온 에너지를 거기에 쏟음
      무료 요금제 사용자가 아주 기본적인 프로그래밍도 못 하면서 허용하는 순간 기술 지원 시간을 전부 가져갈 수도 있음
      AI 사용 공개, 여러 뉴스레터 옵션 제공, 맞지 않으면 솔직히 말하기는 합리적이고 실제로도 잘 작동했음. 하지만 앞의 세 가지는 제품을 망가뜨릴 수 있음. 다만 내가 냉소적이거나 지금까지 잘못 다뤄온 것일 수도 있음
      투자자 자금으로 유니콘을 만들려는 전제라면 그렇고, 다른 부수입이 있는 1인 회사의 느리지만 꾸준한 성장에는 이 방식이 맞을 수 있음
    • “고객이 구체적으로 요청하지 않는 한 AI 상담원이 전화하지 않게 하라”라는데, 실제로 “네, AI가 전화하게 해주세요”라고 요청하는 사람이나 고객이 있나?
    • 좋은 조언임. 10년 넘게 소프트웨어와 서비스를 만들고 팔았지만, 원문에서 묘사한 방식으로 고객을 대했다면 스스로 견디기 어려웠을 것임
    • 반대 접근은 회사에는 일이 줄고 사용자에게는 더 나은 경험이라 모두에게 좋아 보이지만, 그건 진공 속에서만 그렇다
      규제 없는 경쟁은 바닥을 향한 경쟁이라서 가장 비윤리적이고 침습적이며 위법 경계에 있고 조작적인 전술이 이기게 됨
      최고의 제품이 아니라 최고의 마케팅이 이기고, 고객 친화성이 아니라 강압을 통한 전환율이 이기며, 제품과 서비스의 가치가 아니라 사람들이 낼 수 있는 최대 금액이 가격이 됨
  • 큰 기업을 상대해야 하는 작은 스타트업 창업자 입장에서 반대편 이야기도 누군가 써야 함
    무료 요금제나 평가판과 괜찮은 문서가 있는데도 데모를 요구함. 자기 쪽 누군가가 검토하게 하기보다 내 시간을 낭비시키는 걸 선호함
    실제로는 바꿀 생각도 없으면서 엔터프라이즈 경쟁사 갱신 계약을 더 싸게 따내려고 가격/기능 비교 대상으로 이용함
    팔 수 있을지도 확실치 않은 상태에서 끝없는 보안 설문을 채워야 함. 금요일 밤 11시에 100개 넘는 질문을 채우는 걸 좋아하지 않느냐는 식임
    조달 프로세스가 3~6개월 걸리고, 종종 자기 마진만 신경 쓰는 제3자 소프트웨어 리셀러가 하나둘 끼어듦. CDW에게 가격을 15% 낮춰서 너희가 돈 벌게 해주지는 않겠다고 말해야 함
    계약이 끝난 뒤에도 돈은 60~90일 뒤에 들어오는데 서비스는 이미 제공해야 하고 현금흐름은 버거움. 은행 담당자가 마진과 신용카드 한도가 왜 꽉 찼는지 전화하기도 함
    그래서 큰 기업에는 반드시 비싸게 청구할 것임
    • 그래서 우리는 “양식은 작성하지 않는다”는 규칙을 두고 카드 결제만 받음. 그 때문에 잃은 고객도 있지만 우리는 작은 팀이라 괜찮음
      무엇을 하고 무엇을 하지 않을지 미리 분명히 말하는 게 정말 도움이 됨. 여전히 조달 양식 같은 걸 요구하지만, 적어도 거절하고 기대치를 설정할 수 있음
      https://help.timetastic.co.uk/hc/en-us/articles/115003288769...
    • 그건 고정된 기성 솔루션을 팔 때 이야기임
      약간 맞춤형이 필요하거나, 제품-시장 적합성을 다듬고 증명하는 초기 스타트업이 파일럿 고객과 협업하는 상황이라면 더 힘들어짐. 고객이 투자자 포트폴리오 안의 다른 스타트업이 아니라 진짜 회사이고, 그 안에서 아주 작은 한 팀 이상에 영향을 주며, 이미 CEO의 귀를 잡고 있더라도 여러 부서의 이해관계자들과 끝없는 회의를 몇 달 동안 해야 할 각오가 필요함
      민첩한 초기 스타트업 입장에서는 이론상 크고 둔한 대기업보다 엄청난 혁신 우위가 있어야 한다는 걸 체감하게 됨. 그들은 아무것도 못 하는 것처럼 보이기 때문임
      그런데 바로 그 아무것도 못 하는 크고 둔한 대기업의 동의를 필요로 하는 실수를 저질렀다면, 이제 그들의 이동 장벽 대부분이 내 장벽이 됨
  • 정확하고 잘 쓴 글임
    같은 이야기의 더 나쁜 변형도 봤음. 이미 좋은 오픈소스 솔루션을 팀에서 성공적으로 운영하던 엔지니어가, 다른 엔지니어에게 쓰레기 같은 제품의 엔터프라이즈 영업 공세가 떨어졌다는 걸 듣고 경보를 울리려 했지만 이미 늦은 상황임
    조직도 위쪽에서 정치적 자본을 걸고 서명했고, 어떤 경우에는 회사 돈을 그 특정 제품에 쓰는 것이 개인 성과 지표가 되어버림. 그래서 모든 대안은 막히고, 모두가 영업 마무리를 몇 달 기다린 뒤 IT가 SSO와 데이터베이스를 설정하는 데 또 한 달을 기다리고, 잘 작동하던 솔루션에서 쓰레기로 강제 이전함
    결국 계약은 갱신되지 않고 밀어붙인 사람들은 체면을 지키지만, 그걸 떠안았던 사람들 절반은 더 나은 회사로 이직했고, 4분의 1은 쓰레기 제품 때문에 방해받아 PIP를 받거나 커리어가 정체됐고, 남은 4분의 1도 대부분 다음 해에 해고될 것임
    엔터프라이즈 영업에는 그냥 NO라고 해야 함. 자기 제품을 팔려고 엔터프라이즈 영업을 해야 하는 것보다 더 나쁜 건, 다른 엔터프라이즈 영업이 만들어낸 나쁜 구매 결정을 직원으로서 강제로 써야 하는 것임
  • 이 이야기는 너무 많이 겪어본 고통스러운 죽음이라 정말 미칠 지경임
    그런데 오픈소스 솔루션을 찾으면 대체로 더 좋고 원하는 걸 전부 할 수 있음. docker compose up만으로 이미 간단히 테스트도 됨
    하지만 배포 단계에서 컴플라이언스가 SOC2 인증만 확인하고, 전 세계 누구나 이론상 코드를 바꿀 수 있다는 이유로 코드에 대한 깊은 실사를 요구하며 강하게 막힘
    매니저는 무료이고 오픈소스인데 어떻게 그렇게 좋을 수 있냐고 묻고, 과부하 상태인 팀은 예측 불가능한 소프트웨어를 하나 더 지원하는 걸 대체로 좋아하지 않음
    그래서 결국 형편없는 SaaS와 끝없고 쓸모없는 영업 주기, 끔찍하고 비싼 벤더 종속에 돈과 신경을 태울지, 아니면 오픈소스를 사내에서 활용하고 운영하며 돈과 신경을 조금 태울지의 선택이 됨
    보통은 오픈소스를 고름. 특히 SaaS가 빠르고 쉬운 셀프 온보딩, 의미 있는 평가 기간, 예측 가능하고 투명한 가격을 제공하지 않는다면 더 그렇다
    그리고 널리 도입되면 작성자를 지원하거나, 더 복잡한 오픈소스 소프트웨어라면 지원 플랜을 위한 예산을 배정함. 실제로는 거의 필요 없을 가능성이 높더라도 그렇게 함
  • 저자가 유머와 효과를 위해 이렇게 쓴 건 알겠음
    “[...] Google에서 CodeSquish를 찾아보니 내가 필요한 걸 전부 하고, 비용은 0이며, 성능은 100배 더 좋았다. Vermont 농장에서 가끔 나와 자기 호스팅 git 저장소에 코드를 푸시하는 은둔자 한 명이 유지보수하는데도 말이다.”
    그 가난한 은둔 유지보수자는 어느 화요일 오후, 당신 회사가 “CodeSquish”로 연 1억 달러를 벌면서 아무것도 기여하지 않는다는 걸 알게 됨. 그는 Vermont 농장에서 닭에게 먹이를 주며 조용히 자신의 인생 선택, 아니 라이선스 선택을 의심하게 됨
    • 현실적으로는 그런 식으로 자주 작동하지 않음
      대부분의 오픈소스나 SaaS는 Fortune 500 회사에서 유용하긴 해도 편의성에 가까워서 가치를 매기기 어려움. 글에서도 SaaS 벤더가 큰 회사에 더 가치 있어 보이려고 꾸며내고, 사람들에게 전화해 헛소리를 밀어붙이며 가치 기반 가격 책정을 쓰는 게 보임
      회사가 오픈소스 시스템을 운영한다고 해서 그것을 재판매하는 경우도 많이 보지 못했음. 보통은 전체 지식재산권을 소유하고 싶어서 글에서처럼 자기들의 허접한 것을 다시 만듦
      Amazon이 Elastic에 했던 일은 Elastic이 브랜드를 만들었기 때문에 가능했음. 무작위 프로젝트에는 그렇게 못 함. 어떤 프로젝트를 인프라 운영에 쓸 수는 있지만, 특정 라이브러리나 프로젝트에 가치를 귀속시키는 건 매우 어려움
      Amazon이 돈을 버는 건 Amazon이기 때문이지 Linux 커널을 쓰기 때문이 아님. 어쨌든 머리로 정리하기 어려운 문제임
    • 생각해보면 그 유지보수자는 큰 회사들에 청구서를 보내기 시작해도 될 것 같음. 금액이 적당히 작고 실제로 회사가 쓰는 제품이라면 재무팀이 아무 질문 없이 결제할 가능성이 있음
  • 매우 사실적이고 웃기지만 몇 가지는 짚고 싶음
    첫째, 이 중 많은 부분이 B2B 판매를 하고 소프트웨어 산업의 절반을 굴러가게 하려면 필요할 수도 있음. 파는 쪽 회사는 여러 번 연락하고, 영업 엔지니어를 붙이고, 모든 의사결정자를 맞춰주는 과정을 도와야 할 수 있음. 그렇지 않으면 일이 아예 진행되지 않음. 구매자들은 너무 바쁘고 큰 회사에 파는 일은 너무 복잡해서, 일부는 B2B 거래를 계속 굴리기 위한 필요악임
    둘째, 회사들이 실제로 더 잘 구매한다고 상상해보면 좋겠음. 대기업은 스타트업이 10분의 1 비용으로 10배 더 나은 것을 만들 수 있는데도 엔터프라이즈 비대 소프트웨어에 수백만 달러를 씀. 그들에게 더 쉽게 팔 수 있다면 이런 광기 없이도 모두가 더 좋은 것을 쓸 수 있음
    원글의 경험이 영혼을 갉아먹는다는 데 동의하지만, 고객들도 스스로를 조금 도우면 주머니에 돈도 더 남고 더 나은 기술도 얻을 수 있음
    • “10분의 1 비용으로 10배 더 나은 것”이라지만, SLA와 계약상 보장을 1% 비용으로 제공하기는 매우 어려움
      엔터프라이즈 제품은 그냥 다른 부류이고, 그건 제품 자체와는 별개임
  • 지난 한 달 사이 몇 번이나 열정적인 영업 엔지니어의 확인 연락에 진짜 제품 질문으로 답했는데, 곧바로 길고 미묘하게 틀린 LLM 생성 답변을 받은 일이 있었음. 정말 찝찝함
    • 최근 받은 AI 생성 스팸 메일에는 코믹하게 나쁜 문장이 두 개 있었음
      “LinkedIn에서 스페인어를 한다고 봤습니다. ‘¡Qué chévere!’가 대화에 에너지와 밝음을 가져오는 방식이 독특하게 매력적이라고 들었습니다. 최근에 연습할 기회가 있었나요?”
      “변화하는 규제에 adapitates하는 컴플라이언스 자동화 도구를 개발해, 안전하고 효율적인 투자 프로그램을 보장하면서 간접비를 줄입니다.”
      어떤 사람도 LinkedIn의 내 스페인어 “제한적 업무 가능” 표시를 보고 첫 문장처럼 말하지는 않을 것임. 그리고 두 번째의 “Adapitates”는 실제 단어가 아니라 환각임. https://old.reddit.com/r/ChatGPT/comments/1d8gc6x/did_chatgp...
      영업 자체가 문제가 아니고, 대부분의 사람은 어느 정도 영업을 받아들임. 데이터 복제 회사에서 개인화되지 않은 콜드 메일을 받은 적이 있는데, 짧고 핵심적이며 스팸 메일치고는 진정성이 있어서 실제로 제품에 관심이 생겼음
    • 답장을 보내서 어떻게 느꼈는지 말하고, 티켓에 딸린 피드백 양식이 있다면 거기에 의견을 남기는 걸 고려해줬으면 함
      지구상의 모든 회사가 이 기술을 실험하고 있고, 그들이 망쳤을 때 우리가 강한 신호를 주지 않으면 미래의 우리 자신을 이 쓰레기에 묶어두는 셈임
  • 12시간 또는 4시간 지원 SLA와 SSO 접근에 추가 비용을 내야 하는 이유는, 그러지 않으면 제품의 진입 요금이 몇 배로 뛰기 때문임
    그런 기능을 원하는 고객들이 비용이 얼마든 간에 지원이든 SOC-2 보고서든 필요로 하고, 그들이 필요 없는 고객들을 보조하는 구조임. 도움이 된다면 SSO와 SLA가 들어간 고급 패키지를 제품의 진짜 가격으로 보면 됨
    애초에 기술 분야에서 진짜 비용 기반 가격 책정은 거의 없음
    • 맞음. 엄격한 12시간 또는 4시간 지원 SLA를 제공하는 데 실제로 얼마나 드는지 생각하는 사람은 적음
      이는 사실상 회사가 추가 직원 최소 1명의 완전 부담 비용을 감당해야 한다는 뜻임. 그 완전 부담 비용은 대략 급여에 2배를 곱한 값이라고 보고, 이 SLA를 요구하는 고객 수로 나누면 얼마를 받아야 하는지 보이기 시작함
    • 4시간 SLA 고객이 72시간 SLA 고객을 보조한다고 보지는 않음. 그보다는 지원량을 관리하는 문제에 가까움
      답을 3일 뒤에야 받는다는 걸 알면 뻔한 건 직접 검색하고, 다른 방법으로 답을 못 찾을 때만 지원에 연락함. 하지만 더 짧은 SLA, 특히 전화 지원은 어떤 유형의 고객이 마주치는 모든 오류 메시지를 그대로 복사해 붙여넣고, 그 오류가 제품에서 나온 게 아닐 수도 있는데도 지원팀이 풀어주길 기대하게 만듦. 직접 겪어봤음
    • “그 기능을 원하는 고객들이 원하지 않는 고객을 보조한다”는 건, 회사가 이익을 덜 내는 고객에게 이익을 쓰는 셈이라 경제적으로 타당하지 않아 보임. https://regulationbodyofknowledge.org/wp-content/uploads/201... 2쪽의 박스를 참고할 만함
      교차 보조는 규제 때문에 생기거나, 회사가 시장 독점을 시도할 때 생길 수 있음
      제품 가격은 개발 비용보다는 얼마를 받을 수 있는지와 변동비에 따라 결정됨. 지적한 것처럼 이는 가격 차별로 이어지고, 겉보기에는 한 집단이 다른 집단을 보조하는 것처럼 보이지만 실제로는 아닐 수 있음
      한계비용과 이상적 의사결정의 모델을 보고 싶음. 고액 고객 전용 기능을 만들기로 하는 건 그 고객들이 그 기능 값을 낼 때만 이익이 됨. 다른 고객이 그 기능을 얻게 될 수는 있지만 그게 “보조”는 아님. 다만 더 나은 단어가 뭔지는 모르겠음
    • 지원은 그렇다 쳐도, SSO 추가 과금에는 어떤 변명도 없음. 전혀 없음. 이렇게 하는 회사는 고객을 착취하는 형편없는 회사이고 망해도 싸다
  • 놀라운 건 이런 영업 전술이 실제로 통한다는 점임. 많은 사람이 바로 이런 식으로 팔리기를 원하기 때문임
    헛소리 없는 직접 접근, 즉시 데모, 의미 있는 평가 기간, 쉬운 온보딩 등을 제공하면 보통의 영업 놀이를 기대하는 고객을 잃게 됨
    출처: 내가 직접 접근 방식을 하고 있음
    • 맞음. 여기서 중요한 건 저자가 그 게임을 분명히 안다는 점임. 글 곳곳에서 알고 있다는 듯 윙크하니까
      그렇다면 왜 영업 엔지니어와 전화 통화를 하나? 이메일은 그냥 삭제하면 됨
    • 이런 전술은 영업이 먼저 매니저나 디렉터에게 접근해 계약을 따내고, 하위 실무자들이 뒤처리를 맡게 만들 때 통함
      묘사된 상황처럼 기술 담당자가 최종 의사결정자를 막고 있다면 더 도박에 가깝고 자주 실패함
  • 내가 예외일 수도 있지만, 내 사용 사례와 가격을 두고 사람과 15분 대화하는 편이 문서나 평가판 제품을 헤매는 것보다 훨씬 효율적임
    신용카드 정보를 넣고 바로 시작하고 싶은 제품은 AWS EC2나 도메인 등록 서비스 같은 범용 소프트웨어뿐임
    가격/영업 모델에서 선이 꼬일 때가 있는데, 엔터프라이즈 제품을 범용 소프트웨어처럼 가격 매기는 경우가 그렇다. 보통 회사가 미성숙하다는 신호임
    두세 자릿수 가격의 소프트웨어에는 영업팀이 없어야 함. 다섯~여섯 자릿수 이상의 소프트웨어에는 영업과 온보딩 과정에 사람이 반드시 필요함. 내가 지불하는 것의 큰 부분이 지원이기 때문임
    • 내가 질문을 잘못하는 걸 수도 있지만, 이런 통화에서는 꾸준히 “예”라는 답을 듣고 나중에 실제로는 “아니오”였다는 걸 알게 됨
      문제는 우리가 알고 싶은 게 보통 “이 사용 사례를 충족할 수 있나요”가 아니라 “이 사용 사례를 얼마나 잘 충족하나요”라는 점임. 소프트웨어를 직접 만져보지 않고는 평가하기 어려움
    • 분명 세대 차이도 있음. 너무 자주 스팸을 당해서 연락처에 없는 전화는 받지 않음. 중요한 일이라면 음성 메시지를 남길 만큼 중요할 것임
      영업 피치를 자주 받지는 않지만, 다른 이유로 비슷한 태도를 갖고 있음. 문턱에 발을 들이려고 일단 예라고 말한 뒤 세부 조건에서는 아니라고 할 때를 대비해, 모든 내용을 글로 남기고 싶음
    • 크게 반대하지는 않음. 문제는 컴퓨터든 다른 것이든 뭔가를 조사하고 있다는 게 분명한 상황에서 오는 집요한 연락임. 어떤 여행사는 내가 브로슈어 몇 개를 내려받았다는 이유로 특히 공격적으로 연락해왔음