Super Sale WeekClaude Skills — 20% OFF
Tips

경쟁사 데이터를 벤치마킹 보고서로 변환하는 방법 (단계별 가이드)

Powerdrill Team·
경쟁사 데이터를 벤치마킹 보고서로 변환하는 방법 (단계별 가이드)

경쟁사 데이터를 수집하는 것은 절반의 쉬운 일에 불과합니다. 결국 가격, 요금제 제한, 기능 체크 표시, 직원 수 추정치 등이 담긴 스프레드시트만 남게 되죠. 하지만 이는 여전히 가장 중요한 질문인 '우리가 앞서고 있는가, 뒤처지고 있는가?'에 대한 답을 주지 못합니다.

벤치마킹 보고서가 바로 그 답을 제시합니다. 귀사의 수치를 비교 그룹에 대입하여 현재 어느 위치에 있는지 보여줍니다.

보고서의 신뢰성을 결정하는 것은 두 가지입니다. 비교 그룹에 누가 포함되어 있는지, 그리고 평균과 비교했는지 아니면 분포와 비교했는지 여부입니다.

이 가이드에서는 먼저 결정해야 할 사항, 세 가지 수동 방법, 그리고 각 방법이 한계에 부딪히는 지점을 다룹니다.

시작하기 전에 필요한 것

한 문장으로 방어할 수 있는 비교 그룹이 필요합니다. "동일한 예산에서 구매자가 우리와 함께 최종 후보로 고려할 도구들"은 타당한 정의입니다. "가장 규모가 큰 8개 기업"은 그렇지 않습니다.

경쟁사당 하나의 행, 속성당 하나의 열이 필요하며, 각 속성은 명확히 정의되어야 합니다. "AI 기능"이라는 열은 모호하지만, "업로드된 파일로 슬라이드 생성"이라는 열은 명확한 사실입니다.

또한 모든 수치에 대해 수집일이 필요합니다. 가격과 요금제 제한은 계속 변하기 때문에, 날짜가 없는 벤치마킹 보고서는 소리 없이 쓸모없어집니다.

먼저 두 가지를 결정해야 합니다.

무엇을 비교할 것인가. 가격, 역량, 또는 결과물입니다. 이들은 서로 다른 비교 그룹이 필요하며, 이를 하나의 표에 섞는 것이 가장 흔히 저지르는 구조적 실수입니다.

순위를 매길 것인가, 점수를 매길 것인가. 순위를 매기려면 분포가 필요합니다. 점수를 매기려면 가중치가 필요하며, 가중치에는 이를 책임질 담당자가 필요합니다.

재작업을 가장 많이 줄여주는 습관이 하나 있습니다. 별도의 메모 탭이 아니라 모든 셀 바로 옆에 출처 URL을 기록하는 것입니다.

비교가 가장 어려운 이유

대부분의 벤치마킹 작업은 수치를 비교 그룹의 평균과 비교합니다. 이는 데이터를 해석하는 가장 취약한 방식입니다.

평균은 중간값을 알려줄 뿐입니다. 중간에 데이터가 몰려 있는지, 아니면 귀사가 가장자리에 가까이 있는지는 알려주지 못합니다.

백분위수 순위는 이를 보여줍니다. PERCENTRANK.INC는 데이터 세트 내에서 특정 값이 어디에 위치하는지 반환합니다. 이를 통해 여러분이 실제로 원하는 문장을 얻을 수 있습니다. 즉, 우리 가격은 최종 후보군의 30번째 백분위수에 위치한다는 것입니다.

사분위수는 구간을 나누어 줍니다. QUARTILE.INC는 비교 그룹을 4개로 나누는데, 이는 보통 보고서를 한 번 읽는 사람에게 충분한 해상도를 제공합니다.

여기에는 사람들이 흔히 빠지는 규모의 함정이 있습니다. 배타적 백분위수(exclusive percentile) 함수는 표본 크기가 작을 때 극단적인 백분위수를 계산할 수 없습니다.

Microsoft는 PERCENTILE.EXC의 동작 방식을 문서화해 두었습니다. 이 함수는 "지정된 백분위수의 값이 배열의 두 값 사이에 있을 때 보간"하며, 보간할 수 없을 때는 #NUM! 오류를 반환합니다.

비교 그룹이 8개인 경우, 이 방식으로는 95번째 백분위수를 계산할 수 없습니다. 소규모 데이터 세트에는 포함적(inclusive) 함수를 사용하고, 어떤 함수를 사용했는지 명시하세요.

표준화 역시 매우 중요합니다. 사용자당(per-seat) 요금제와 워크스페이스당(per-workspace) 요금제는 팀 규모를 고정하기 전까지는 비교할 수 없습니다. 연간 요금과 월간 요금 역시 기준을 하나로 통일하기 전까지는 비교할 수 없습니다.

수동으로 작업하는 방법

옵션 1: 속성 매트릭스를 먼저 구축한 후 순위 매기기

계산을 시작하기 전에 표를 제대로 구성하세요. 경쟁사당 하나의 행, 속성당 하나의 열, 열당 하나의 정의를 적용합니다.

그런 다음 XLOOKUP을 사용하여 귀사의 수치를 가져오세요. 그래야 직접 입력하는 대신 자동으로 행이 생성됩니다. 직접 입력한 값은 파일 내의 그 어떤 데이터보다 빠르게 최신 상태에서 벗어납니다.

그 다음에 순위를 매기세요. 숫자 속성마다 백분위수 열을 추가하여 보고서의 모든 주장에 명확한 근거 위치가 뒷받침되도록 합니다.

이 방법의 한계는 매트릭스가 결론이 아니라는 점입니다. 12개의 열을 보여줄 뿐 우선순위는 보여주지 못합니다.

옵션 2: 평균을 내기 전에 비교 그룹을 세분화하기

혼합된 데이터 세트 전체의 단일 평균을 내는 것은 벤치마킹이 잘못되는 지점입니다. 엔터프라이즈 전용 도구와 셀프서비스 도구는 서로 가격 경쟁을 하지 않습니다.

데이터 세트를 분할하고 세그먼트별로 AVERAGEIFS를 사용하세요. 이들을 병합하지 말고 각 세그먼트를 별도로 보고하십시오.

분할할 때 표본 크기에 주의하세요. 한 세그먼트에 경쟁사가 4개뿐이라면 이는 일화에 불과하며, 4개 데이터 포인트에 대한 백분위수는 방향성만 제시하는 것으로 표시해야 합니다.

여기서의 한계는 판단력입니다. 도구는 사용자가 정의한 세그먼트가 무엇이든 그대로 계산하므로, 세그먼트를 잘못 정의하면 확신에 찬 오답을 얻게 됩니다.

옵션 3: 출처(provenance) 탭 유지하기

데이터 포인트당 하나의 행을 구성합니다: 속성, 경쟁사, 값, 출처 URL, 수집일.

이렇게 해야 다음 분기에 보고서를 다시 실행할 수 있습니다. 또한 조사를 처음부터 다시 하지 않고도 "그 데이터가 어디서 나왔는가"라는 질문에 답할 수 있습니다.

한계는 출처 데이터가 스스로 업데이트되지 않는다는 점입니다. 모든 수치에는 유효 기간이 있으므로 누군가는 이를 다시 확인해야 합니다.

공통된 한계. 세 가지 방법 모두 속성이 비교 가능하다는 것을 전제로 합니다. 한 벤더는 제한 사항을 공개하고 다른 벤더는 아무것도 공개하지 않는 경우, 추측해서 채우기보다는 "미공개"라고 솔직하게 적는 것이 맞습니다.

수동 방식의 한계와 속도가 느려지는 지점

첫 번째 보고서를 작성하는 데는 일주일이 걸립니다. 두 번째 보고서도 거의 그만큼 걸리는데, 기초 수치들이 변경되었지만 아무도 어떤 수치가 바뀌었는지 기록해 두지 않았기 때문입니다.

가격은 자체 일정에 따라 변경됩니다. 요금제 제한, 최소 사용자 수, 패키징도 마찬가지이며, 이러한 변경 사항은 소리 없이 특정 셀의 데이터를 무효화합니다.

기능 열은 가격 열보다 더 빨리 노후화됩니다. 지난 분기에는 없었던 기능이 예고 없이 출시되면, 이제 귀사의 표는 경쟁사에 대해 사실이 아닌 내용을 담게 됩니다.

이것이 벤치마킹 작업의 진짜 위험입니다. 오래된 "없음(no)" 표시는 중립적인 오류가 아닙니다. 이는 뒷받침할 수 없는 타사 제품에 대한 잘못된 주장입니다.

발표 시점에 나타나는 두 번째 비용도 있습니다. 누군가 왜 특정 경쟁사가 포함되었는지 물었을 때, 비교 그룹 선정 규칙이 문서화되어 있지 않다면 보고서 전체의 신뢰성이 흔들리게 됩니다.

Powerdrill Bloom으로 보고서를 작성하는 방법

1단계: 경쟁사 스프레드시트 업로드하기

수집한 매트릭스와 귀사의 지표 파일(별도인 경우)을 업로드합니다. Powerdrill Bloom은 파일이 업로드되는 즉시 열을 분석하므로, 순위가 계산되기 전에 빈 셀, 혼합된 단위, 중복된 경쟁사 이름 등이 먼저 드러납니다.

Powerdrill Bloom에서 벤치마킹 보고서를 작성하기 위해 경쟁사 스프레드시트 업로드하기

2단계: 자연어로 비교 내용 설명하기

공식을 만드는 대신 비교 그룹과 기준을 자연어로 기술하세요. 어떤 경쟁사가 어떤 세그먼트에 속하는지, 어떤 가격 기준을 사용하는지, 어떤 속성이 숫자인지 설명합니다.

그런 다음 오류를 잡아내는 질문을 던지세요. 어떤 셀에 출처나 날짜가 누락되었는지, 어떤 속성이 혼합된 단위로 기록되었는지 물어봅니다. 그런 다음 각 세그먼트 내에서 귀사의 행이 백분위수 기준으로 어디에 위치하는지 물어보세요.

3단계: 차트, 보고서 또는 프레젠테이션 덱 내보내기

순위가 매겨진 표, 포지셔닝 차트, 또는 결과와 함께 비교 그룹 정의가 포함된 슬라이드를 내보냅니다.

Powerdrill Bloom에서 순위가 매겨진 벤치마킹 표 및 포지셔닝 차트 내보내기

수동으로 매트릭스를 재구축하는 것보다 이 방법이 더 나은 이유

수동 방식 Powerdrill Bloom
한 열에 혼합된 가격 기준 수동으로 표준화 기준을 명시하고 질문하기
속성별 백분위수 위치 열마다 공식 적용 순위 요청하기
출처나 날짜가 없는 셀 탭을 무작위로 확인 업로드 시 즉시 노출
다음 분기에 재실행 시트 재구축 파일만 교체하고 규칙은 유지

세 번째 행이 바로 여러분을 보호해 주는 항목입니다. 벤치마킹 보고서에서 출처가 없는 셀은 리스크가 되며, 이를 수동으로 찾는 것은 보통 생략되기 마련인 검증 단계입니다.

흔히 하는 실수들

브랜드 규모로 비교 그룹 선택하기. 구매자는 시가총액이 아니라 예산과 해결해야 할 과제(job to be done)를 기준으로 최종 후보를 선정합니다. 구매자의 관점에서 그룹을 정의하세요.

분포 대신 평균과 비교하기. 평균은 귀사가 밀집된 영역에 있는지 아니면 가장자리에 있는지 숨깁니다. 백분위수와 비교 대상 수를 함께 보고하세요.

서로 다른 기준의 가격을 그대로 두기. 사용자당, 워크스페이스당, 월간, 연간 요금은 하나의 열을 공유할 수 없습니다. 기준을 하나로 고정하고 이를 명시하세요.

없는 기능을 영구적인 '없음'으로 기록하기. 새로운 기능은 조용히 출시됩니다. 모든 기능 셀에 날짜를 기록하고, 경쟁사에 대한 주장을 발표하기 전에 다시 확인하세요.

소규모 비교 그룹에 배타적 백분위수 함수 사용하기. 극단적인 백분위수는 이 방식으로 계산할 수 없으며 오류를 반환합니다. 포함적 함수를 사용하고 이를 명시하세요.

더 큰 표본을 얻기 위해 세그먼트 혼합하기. 엔터프라이즈와 셀프서비스가 혼합된 대규모 데이터 세트는 규모는 작지만 정직한 데이터 세트보다 나쁩니다. 세그먼트를 분할하고 라벨을 붙이세요.

가중치를 밝히지 않고 점수 보고하기. 가중치가 적용된 점수는 숫자의 탈을 쓴 의견일 뿐입니다. 가중치를 공개하거나 순위를 공개하고, 그 결과를 실제로 관리하는 선행 및 후행 지표와 결합하세요.

결론

비교 그룹을 한 문장으로 정의하고, 모든 속성 열을 정의하며, 가격 기준을 표준화하고, 평균 대신 백분위수를 보고하세요. 이것이 첫 번째 검토에서 벤치마킹 보고서가 살아남는 방법입니다.

비용이 많이 드는 부분은 분석이 아닙니다. 모든 셀에는 유효 기간이 있으므로, 보고서를 새로 작성하는 대신 다시 실행할 수 있도록 만들어야 한다는 점입니다.

이번 분기에도 매트릭스를 재구축하는 데 시간을 보내고 있다면, 이미 가지고 있는 스프레드시트로 Powerdrill Bloom을 사용해 보세요. 또한 경쟁사 벤치마킹을 위한 최고의 AI 도구 모음과 AI 경쟁사 분석AI 경쟁 인텔리전스 페이지도 확인해 보세요.

자주 묻는 질문

벤치마킹 보고서에는 어떤 내용이 들어가야 하나요?

정의된 비교 그룹, 정의된 속성당 하나의 열, 귀사의 데이터로 생성된 귀사만의 행, 그리고 숫자 속성별 백분위수 위치가 포함되어야 합니다. 모든 셀에는 출처와 수집일이 필요합니다.

경쟁사는 몇 개나 필요한가요?

백분위수가 의미를 가질 만큼 충분해야 하므로, 세그먼트당 8개에서 12개가 적절한 목표입니다. 5개 미만인 경우, 결과를 통계적이기보다는 방향성을 제시하는 것으로 표시하세요.

평균과 비교해야 하나요, 아니면 중앙값과 비교해야 하나요?

둘 중 어느 하나만으로는 부족합니다. 백분위수로 귀사의 위치를 보고하세요. 이것이 실제 질문에 대한 답이 되며, 왜곡된 비교 그룹에서도 왜곡되지 않는 결과를 보여주기 때문입니다.

신뢰할 수 있는 경쟁사 데이터는 어디서 얻을 수 있나요?

공개된 요금제 페이지, 공식 제품 문서, 공시 자료 등이 가장 신뢰할 수 있습니다. 출처가 명확하고 날짜가 기록되어 있기 때문입니다. 모든 수치 옆에 URL과 날짜를 기록해 두세요.

보고서는 얼마나 자주 업데이트해야 하나요?

가격 및 패키징은 분기별로 업데이트하고, 기능 관련 주장은 더 자주 업데이트해야 합니다. 기능은 공지 없이 변경되며, 이미 업데이트된 기능을 '없음'으로 방치하는 오류는 신뢰도에 큰 타격을 줍니다.