N
Negotiations.AI
← Back to blog

사례 연구: Objection을 활용한 협업 및 생산성 소프트웨어

Objection Handling이 협업 및 생산성 소프트웨어에서 결과를 어떻게 바꾸는지 보여주는 구체적인 시나리오입니다.

8 min read

사례 연구: Objection을 활용한 협업 및 생산성 소프트웨어

협업 플랫폼 구매는 단순해 보이지만, 조달, IT, 보안, 사업 부서 책임자가 각각 가치를 다르게 정의하기 시작하면 상황이 복잡해집니다. 협업 및 생산성 소프트웨어 조달에서 가장 어려운 부분은 첫 견적이 아니라, 공급업체가 라이선스 축소, 관리자 권한, 지원 조건, 또는 종료 관련 문구에 대해 반대할 때 귀사의 팀이 어떻게 대응하느냐인 경우가 많습니다.

빠른 답변

협업 소프트웨어 협상에서 objection handling이 가장 효과적으로 작동하는 방식은, 공급업체의 반대에 대해 단순히 할인만 요구하는 것이 아니라 도입률, 보안, 상업적 트레이드오프에 연결된 근거로 대응하는 것입니다. 이 사례 연구에서 구매자는 usage and adoption metrics, admin and security controls, 그리고 단계적 라이선스 약정을 활용해, 경직된 per-user licensing 입장을 고수하던 공급업체를 보다 유연한 enterprise agreement negotiation 결과로 이끌었습니다. 그 결과, 거래를 적대적으로 만들지 않으면서도 더 나은 적합성, 더 낮은 낭비, 더 명확한 리스크 조건을 확보할 수 있었습니다.

상황

직원 4,800명의 한 기업은 여러 차례의 인수 이후 도구를 통합하고 있었습니다. 이 회사는 채팅, 문서 협업, 화이트보딩, 회의 도구가 혼재된 환경을 단일 생산성 제품군으로 대체하고자 했습니다.

공급업체의 제안은 다음과 같았습니다:

  • 유료 좌석 4,500개
  • 사용자당 월 27달러
  • 36개월 계약
  • 1년 차 이후 매년 5% 인상
  • 프리미엄 지원 포함
  • 표준 SLA만 제공
  • 제한적인 관리자 내보내기 권한
  • 미갱신 시 90일 전 통지

이 조건은 확장, 추가 기능, 또는 인상 효과를 제외하더라도 3년 약정 금액이 대략 437만 달러에 달했습니다. 조달팀은 좌석 수가 과도하게 부풀려졌다고 우려했습니다. IT는 더 강력한 admin and security controls를 원했습니다. 재무팀은 확정 지출을 낮추길 원했습니다. 사업 스폰서는 빠른 롤아웃을 원했고, 거래가 지연되는 것도 원하지 않았습니다.

이것은 전형적인 협업 및 생산성 소프트웨어 협상 문제입니다. 공급업체는 플랫폼 전반의 광범위한 가치를 판매하지만, 구매자는 사용자 그룹별로 고르지 않은 도입률을 봅니다.

반대가 나타난 지점

공급업체는 예측 가능한 네 가지 objection을 제기했습니다:

1. “가치를 얻으려면 거의 전면 배포가 필요합니다.”

계정팀은 더 낮은 좌석 약정이 협업 성과를 약화시키고 가격 효율성도 떨어뜨릴 것이라고 주장했습니다.

2. “우리 가격은 이미 엔터프라이즈 고객 기준으로 벤치마킹되어 있습니다.”

공급업체는 이 견적이 전략 고객에게는 시장 표준 수준이라고 설명하며, 더 깊은 단가 인하에 저항했습니다.

3. “관리자 권한과 내보내기 권한은 표준 패키지의 일부입니다.”

보안 및 IT 팀은 더 나은 로깅, 더 세분화된 통제, 그리고 회사가 나중에 마이그레이션할 경우를 대비한 더 명확한 데이터 내보내기 지원을 요청했습니다.

4. “이 할인 수준에는 36개월 계약이 필요합니다.”

공급업체는 매출을 보호하고 구매자의 규모 조정 옵션을 줄이기 위해 장기 약정을 선호했습니다.

이러한 objection 자체는 놀라운 일이 아니었습니다. 중요한 것은 구매자가 이를 어떻게 다뤘느냐였습니다.

준비 단계: 회의 전 AI 지원 objection handling 활용

상업 조건 논의 전, 조달 책임자는 AI를 사용해 예상 objection을 세 가지 범주로 정리했습니다:

  • 가치 objection: “귀사는 너무 적게 구매하고 있습니다.”
  • 가격 objection: “이 가격은 이미 경쟁력 있습니다.”
  • 리스크 objection: “우리는 표준 조건을 바꿀 수 없습니다.”

그다음 팀은 내부 데이터를 바탕으로 대응 트랙을 만들었습니다:

  • 활성 사용 데이터에 따르면 첫 12개월 동안 고급 협업 기능을 사용할 것으로 예상되는 직원은 2,900명뿐이었습니다.
  • 추가로 900명은 기본 메시징과 회의 기능만 필요했습니다.
  • 약 700명의 현장 직원은 공유 기기 워크플로를 사용했기 때문에 기명식 전체 제품군 라이선스가 필요하지 않았습니다.
  • 보안팀은 역할 기반 관리자 위임과 내보내기 문서화에서 공백을 발견했습니다.

이 점이 중요했던 이유는, objection handling negotiation은 구매자 고유의 사실에 기반할 때 더 강력해지기 때문입니다. 팀은 공급업체가 “너무 비싸다”고 주장하지 않았습니다. 대신 제안된 패키지가 실제 배포와 맞지 않는다고 주장했습니다.

구조화된 준비 워크플로가 필요하다면, 당사의 AI negotiation co-pilot features 페이지를 참고하세요.

이 사례에서 사용된 objection handling 플레이북

Objection 1: “표준화를 하려면 4,500석이 필요합니다.”

구매자의 답변은 단순히 “아니요, 그렇지 않습니다”가 아니었습니다. 대신 이렇게 말했습니다:

“우리는 표준화가 목표라는 점에 동의합니다. 우리의 롤아웃 데이터에 따르면 1단계에서는 전체 사용자 2,900명, 경량 사용자 900명, 공유 기기 사용자 700명이 예상됩니다. 지금 4,500석을 약정하면, 배포 후 양측이 더 정확히 측정할 수 있는 도입 리스크에 대해 비용을 지불하게 됩니다. 계약 구조를 롤아웃 곡선에 맞춰 설계합시다.”

이 답변은 세 가지를 해냈습니다:

  1. 공급업체의 목표를 인정했습니다.
  2. usage and adoption metrics를 도입했습니다.
  3. 논의를 가격에서 구조로 전환했습니다.

Objection 2: “우리 벤치마크 가격은 이미 공격적입니다.”

구매자는 이렇게 답했습니다:

“우리는 단순한 표면적 사용자당 가격만 평가하는 것이 아닙니다. 활성 사용자당 실질 비용, 사용자 계층 간 유연성, 그리고 12개월 동안 사용되지 않는 라이선스 비용까지 평가하고 있습니다. 단가를 크게 움직일 수 없다면, 계층화, true-down 권리, 또는 단계적 약정에서 조정이 필요합니다.”

이것은 소프트웨어에서 handle pushback negotiation을 실무적으로 수행하는 방식입니다. 공급업체가 리스트 가격의 정합성을 지키려 한다면, 범위와 시점에 관한 상업적 레버로 이동해야 합니다.

Objection 3: “관리자 권한과 내보내기 권한은 표준입니다.”

구매자의 답변:

“이번 배포에서 admin and security controls는 법무 레드라인 문제가 아니라 도입을 가능하게 하는 요소입니다. 우리 IT 팀은 엔터프라이즈 롤아웃을 승인하기 위해 위임된 관리, 감사 가시성, 그리고 문서화된 내보내기 지원이 필요합니다. 이것들이 고정되어 있다면, 우리는 범위를 줄이거나 배포를 단계화해야 할 수 있습니다.”

이렇게 함으로써 “있으면 좋은 것”을 배포 의존 요소로 바꿨습니다.

Objection 4: “이 가격에는 36개월이 필요합니다.”

구매자는 이렇게 답했습니다:

“1년 차 약정이 실제 롤아웃을 반영하고, 도입 지표, 지원 성과, 보안 제공 항목에 연동된 명확한 검토 시점이 있다면 36개월 프레임워크를 논의할 수 있습니다.”

다시 말해, 구매자는 계약 기간 자체를 거부하지 않았습니다. 대신 그 기간에 조건을 붙였습니다.

수정된 거래 구조

두 차례의 협상 끝에 양측은 다음에 합의했습니다:

  • 1년 차 전체 제품군 라이선스 3,000개, 사용자당 월 24.50달러
  • 경량 사용 라이선스 800개, 사용자당 월 11달러
  • 첫 12개월 동안 동일한 1년 차 요율로 전체 제품군 라이선스 최대 700개 추가 옵션
  • 초기 확정 계약 기간 24개월, 도입 임계치 충족 시 사전 합의된 확장 일정 포함
  • 초기 계약 기간 동안 연간 인상 없음
  • 프리미엄 지원 유지, 단 분기별 서비스 검토 회의 포함
  • 관리자 역할 세분화 개선 사항을 구현 계획서에 문서화
  • 전환 지원을 위한 데이터 내보내기 지원 문구 추가
  • 만성적 SLA 실패 시 60일 시정 경로와 서비스 크레딧 포함
  • 합의된 usage and adoption metrics를 활용한 1년 차 도입 검토

예상 1년 차 확정 지출은 원래 구조 대비 상당히 줄었지만, 더 큰 성과는 적합성이었습니다. 이 회사는 기명식 라이선스를 과잉 구매하는 일을 멈췄고, per-user licensing negotiation에서 shelfware 리스크를 줄였습니다.

objection handling이 효과적이었던 이유

공급업체의 프레이밍을 받아들이지 않으면서도 그들의 우려에는 답했다

공급업체는 “가치를 얻으려면 지금 더 많이 구매하라”고 말했습니다. 구매자는 “우리는 조기 약정이 아니라 단계적 도입을 통해 가치를 얻겠다”고 답했습니다.

카테고리 특화 근거를 사용했다

생산성 제품군 조달에서는 추상적인 ROI 슬라이드보다 도입 데이터가 더 중요합니다. 기명 사용자, 기능 사용 깊이, 공유 기기 사용자군, 롤아웃 웨이브는 모두 구체적입니다.

확실성과 확실성을 교환했다

공급업체는 매출 확실성을 원했습니다. 구매자는 활용 확실성을 원했습니다. 타협점은 실제 수요에 연동된 확장 권리를 포함한 램프 구조였습니다.

보안을 상업 조건과 연결했다

Admin and security controls는 별도의 기술 이슈로 다뤄지지 않았습니다. 그것들이 배포 리스크에 영향을 주었기 때문에 정당한 상업적 레버로 활용되었습니다.

다음 협업 소프트웨어 협상을 위한 실전 체크리스트

협업 소프트웨어 조달을 위한 objection handling 체크리스트

회의 전에 다음 다섯 가지를 준비하세요:

  1. 라이선스 세분화
  • 전체 사용자
  • 경량 사용자
  • 공유 기기 또는 키오스크 사용자
  • 계약직 또는 임시 사용자
  1. 도입 근거
  • 현재 활성 사용자 수
  • 분기별 예상 롤아웃
  • 부서별 기능 사용량
  • 폐기 예정인 중복 도구
  1. 상업적 대안 옵션
  • 고정 약정 대신 단계적 약정
  • 전체 제품군 좌석 일괄 구매 대신 계층형 라이선스
  • 가격 고정이 적용되는 확장 권리
  • 검토 시점의 true-down 또는 재분류 권리
  1. 운영 요구사항
  • 롤아웃에 필요한 admin and security controls
  • 지원 응답 KPI
  • 구현 마일스톤
  • 사용량 보고 접근 권한
  1. 리스크 및 종료 조건
  • 내보내기 지원 문구
  • 갱신 통지 시점
  • SLA 구제책 또는 크레딧
  • 도구 교체 시 전환 지원

연습용 AI 프롬프트

준비 단계에서 다음 objection handling prompts를 활용해 보세요:

  • “Act as a collaboration software sales rep. Push back on my request to reduce named seats from 4,500 to 3,000 while keeping enterprise pricing.”
  • “Give me three stronger ways to handle pushback negotiation when the vendor says our benchmark is already competitive.”
  • “Rewrite this response so it links admin and security controls to deployment risk, not just contract preference.”
  • “Simulate an enterprise agreement negotiation where the supplier refuses true-down rights but may accept phased expansion.”
  • “Challenge my argument using likely vendor objections on usage and adoption metrics.”

이러한 종류의 objection handling prompts는 실제 통화 전에 약한 논리를 드러내 준다는 점에서 유용합니다.

조달팀이 이 사례에서 복제해야 할 점

협업 및 생산성 소프트웨어 협상에서는 대화를 “할인 대 무할인”에만 머물게 두지 마세요. 더 나은 결과는 대개 상업 모델 자체를 재구성하는 데서 나옵니다:

  • 실제 사용자 행동에 맞게 라이선스 유형을 맞출 것
  • 약정을 롤아웃 단계에 연동할 것
  • usage and adoption metrics를 활용해 과도한 좌석 가정을 반박할 것
  • admin and security controls를 배포 레버로 다룰 것
  • 갱신 압박이 나타나기 전에 종료 및 전환 조건을 요구할 것

이 점은 특히 enterprise agreement negotiation에서 중요합니다. 이 경우 공급업체는 편의성, 표준화, 가격을 하나의 서사로 묶는 경우가 많습니다. 귀사의 역할은 그것들을 분리하는 것입니다.

추가 읽을거리

FAQ

협업 소프트웨어 협상에서 가장 큰 objection handling 실수는 무엇인가요?

모든 objection을 가격 objection으로 취급하는 것입니다. 이 카테고리에서는 좌석 구성, 롤아웃 시점, 지원, 관리자 통제가 단가만큼이나 중요할 때가 많습니다.

생산성 제품군 조달에서 usage and adoption metrics는 어떻게 도움이 되나요?

더 낮은 초기 약정을 방어하고, 계층형 라이선스를 정당화하며, 1년 차에 고급 기능을 도입할 가능성이 낮은 사용자에게 비용을 지불하는 일을 피하도록 도와줍니다.

per-user licensing negotiation에서는 무엇을 요청해야 하나요?

라이선스 세분화, 확장 가격 보호, 검토 시점, 재분류 유연성, 그리고 활성 사용에 대한 명확한 보고에 집중하세요.

상업 협상에서 왜 admin and security controls를 언급해야 하나요?

통제가 약하면 롤아웃이 지연되고, 내부 지원 비용이 증가하며, 실현 가치가 줄어들 수 있기 때문입니다. 따라서 이것은 단순한 기술 선호가 아니라 상업적 이슈입니다.

이 글은 일반적인 정보 제공 목적일 뿐이며, 법률, 재무, 또는 조달 자문이 아닙니다.

Try the AI negotiation co-pilot

Use Negotiations.AI to prepare, strategize, and role-play your next procurement or vendor negotiation.