앱을 여러 개 쓰면 리포트가 앱 개수만큼 생깁니다. CRM에서 하나, 헬프데스크에서 하나, 회계에서 하나. 매달 이것들을 엑셀로 합치는 일이 누군가의 업무가 됩니다.
Zoho Analytics는 이 작업을 없애기 위한 도구입니다. 여러 앱의 데이터를 한곳으로 모아 교차 분석하고 대시보드로 고정합니다.
그런데 도구를 붙인다고 자동으로 해결되지는 않습니다. 데이터를 모으는 것과 의미 있게 합치는 것은 다른 문제입니다. 키가 맞지 않으면 합쳐도 답이 안 나옵니다.
이 글은 통합 대시보드를 설계하는 순서를 정리합니다. 질문 정의부터 키 설계, 갱신 주기, 권한까지입니다.
가장 흔한 실패는 '있는 데이터로 만들 수 있는 차트'를 모아 대시보드를 만드는 것입니다. 보기에는 그럴듯한데 아무도 보지 않습니다.
시작점은 질문이어야 합니다. 매주 경영 회의에서 실제로 묻는 질문, 결정을 바꾸는 질문.
질문을 다섯 개 이내로 적으십시오. 예를 들어 이번 달 계약 예상액은 얼마인가, 어느 단계에서 가장 많이 막히는가, 어떤 채널이 계약으로 이어지는가, 고객 이탈 신호가 있는 계정은 어디인가.
질문이 정해지면 필요한 데이터가 자동으로 정해집니다. 반대 순서로 하면 데이터는 많은데 답은 없는 대시보드가 나옵니다.
여러 앱의 데이터를 합칠 때 가장 먼저 걸리는 것이 키입니다. CRM의 '회사'와 헬프데스크의 '고객'과 회계의 '거래처'가 같은 대상인지 시스템은 모릅니다.
국내 B2B에서 가장 안정적인 키는 사업자등록번호입니다. 상호는 바뀌고 표기가 제각각이지만 번호는 유일합니다.
세 시스템 모두에 이 값이 같은 형식으로 저장되어 있는지 확인하십시오. 하이픈 유무, 자릿수, 공백. 형식이 다르면 매칭률이 떨어지고, 매칭이 안 된 데이터는 조용히 집계에서 빠집니다.
키 정리가 끝나기 전에 대시보드를 만들면 숫자가 틀립니다. 그리고 틀린 대시보드는 한 번만 들켜도 다시 신뢰받지 못합니다.
모든 데이터를 가져올 필요는 없습니다. 오히려 다 가져오면 갱신이 느려지고 관리가 어려워집니다.
원칙은 '1번에서 정한 질문에 답하는 데 필요한 것만'입니다. 거래 금액과 단계는 필요하지만 모든 활동 기록까지 가져올 이유는 대개 없습니다.
대신 집계 단위를 미리 정하십시오. 일별인지 주별인지, 계정 단위인지 거래 단위인지. 집계 단위가 정해지면 가져올 데이터 양이 크게 줄어듭니다.
연동에는 API 호출이 따르므로 소모량도 고려 대상입니다. 전체 동기화보다 변경분만 가져오는 증분 방식이 거의 항상 낫습니다.
실시간이 항상 좋은 것은 아닙니다. 주간 회의에서 쓰는 지표를 5분마다 갱신할 이유가 없습니다.
갱신 주기는 그 숫자를 보고 무엇을 결정하는지에 맞추십시오. 주간 회의용이면 일 1회로 충분하고, 영업 담당자가 자기 파이프라인을 확인하는 용도라면 더 자주 필요할 수 있습니다.
주기를 늘리면 API 소모와 시스템 부하가 줄어듭니다. 이 여유가 다른 연동에 쓰입니다.
갱신 시각도 정하십시오. 회의 시작 전에 갱신이 끝나 있어야 합니다. 회의 중에 숫자가 바뀌면 논의가 멈춥니다.
같은 이름의 지표가 다르게 계산되는 것이 통합 대시보드의 두 번째 함정입니다. '전환율'이 어디서는 MQL 대비이고 어디서는 전체 리드 대비입니다.
지표 정의서를 만드십시오. 지표명, 계산식, 분자와 분모의 정의, 제외 조건, 담당자.
특히 제외 조건이 중요합니다. 테스트 데이터, 내부 거래, 취소된 건을 포함하는지 아닌지가 숫자를 크게 바꿉니다.
이 문서는 대시보드 옆에 링크로 붙여 두십시오. 숫자에 대한 질문이 나올 때마다 같은 답을 반복하지 않아도 됩니다.
통합 대시보드는 여러 시스템의 데이터를 모으므로 권한이 섞이기 쉽습니다. CRM에서 못 보던 데이터를 대시보드에서 보게 되는 상황이 생깁니다.
설계 원칙은 원본 시스템의 권한을 넘지 않는 것입니다. 원본에서 못 보는 데이터는 대시보드에서도 안 보여야 합니다.
실무에서는 역할별로 대시보드를 나누는 방식이 관리하기 쉽습니다. 경영용, 영업 관리자용, 담당자 개인용.
급여·원가처럼 민감한 데이터가 들어가는 경우에는 별도 대시보드로 분리하고 접근자를 명시적으로 관리하십시오. 한 대시보드에 섞어 두고 필터로 가리는 방식은 사고가 납니다.
대시보드가 늘어나면 아무도 보지 않게 됩니다. 어디를 봐야 할지 모르기 때문입니다.
실무 권장은 용도별로 다섯 개 이하입니다. 경영 요약, 영업 파이프라인, 마케팅 성과, 고객지원 현황, 운영 지표 정도입니다.
각 대시보드에는 차트를 여덟 개 이하로 두십시오. 스크롤해야 보이는 차트는 대부분 보지 않습니다.
새 요청이 오면 추가하기 전에 기존 차트 중 하나를 뺄 수 있는지 먼저 물으십시오. 이 규칙 하나가 대시보드의 수명을 크게 늘립니다.
대시보드는 만든 시점이 아니라 3개월 뒤에 평가합니다. 평가 기준은 조회 수가 아니라 '이것을 보고 무엇이 바뀌었는가'입니다.
월 1회 점검하십시오. 각 차트가 여전히 질문에 답하고 있는지, 보지 않는 차트가 있는지, 새로 생긴 질문이 있는지.
보지 않는 차트는 과감히 빼십시오. 남겨 두면 대시보드 전체의 신뢰도가 떨어집니다. '이건 원래 안 봐요'라는 말이 나오는 순간 옆 차트도 의심받습니다.
데이터 원본이 바뀌면 대시보드도 바뀌어야 합니다. CRM에서 속성을 추가하거나 단계를 바꿨는데 대시보드를 안 고치면 조용히 틀린 숫자가 나옵니다. 변경 관리 절차에 대시보드 점검을 포함하십시오.
Zoho Analytics의 플랜별 정가, 행 수 한도, 사용자 수 조건은 이 글의 확인 범위에 포함되지 않았습니다. 공식 가격 페이지에서 확인하십시오.
연동 가능한 데이터 소스의 목록과 각 소스별 동기화 방식은 제품 문서에서 확인해야 합니다.
CRM 연동 시 소모되는 API 크레딧은 동기화 방식과 데이터 양에 따라 달라집니다. 별도 글에서 계산 방법을 다룹니다.
이 글은 설계 원칙을 다루며 특정 화면의 조작 방법이나 수식 문법은 포함하지 않습니다.
|
단계 |
할 일 |
완료 판정 |
|---|---|---|
|
1. 질문 정의 |
경영 회의에서 실제로 묻는 질문 5개 이내 |
질문이 문장으로 적혀 있다 |
|
2. 키 정리 |
사업자등록번호 등 공통 키의 형식 통일 |
세 시스템 매칭률을 수치로 안다 |
|
3. 범위 결정 |
질문에 답하는 데 필요한 데이터만 선정 |
가져오지 않을 것이 목록으로 있다 |
|
4. 집계 단위 |
일/주 · 계정/거래 단위 확정 |
단위가 지표마다 정해져 있다 |
|
5. 갱신 주기 |
의사결정 주기에 맞춰 설정 |
회의 전 갱신 완료 시각이 정해져 있다 |
|
6. 지표 정의 |
계산식·분모·제외 조건 문서화 |
정의서가 대시보드에 링크되어 있다 |
|
7. 권한 설계 |
원본 시스템 권한을 넘지 않게 |
역할별 대시보드가 분리되어 있다 |
|
8. 운영 규칙 |
월 1회 점검 · 추가 시 하나 제거 |
점검 담당자와 주기가 정해져 있다 |
2단계를 건너뛰고 만든 대시보드는 숫자가 틀립니다. 그리고 한 번 틀린 대시보드는 다시 신뢰받지 못합니다
|
증상 |
실제 원인 |
대응 |
|---|---|---|
|
아무도 대시보드를 보지 않는다 |
질문이 아니라 데이터에서 시작했다 |
질문 5개를 먼저 적고 재구성 |
|
숫자가 원본 시스템과 다르다 |
키 형식 불일치로 매칭 누락 |
공통 키 형식 통일 후 매칭률 측정 |
|
같은 지표가 화면마다 다르다 |
계산식과 제외 조건이 문서화되지 않음 |
지표 정의서 작성 후 링크 |
|
갱신이 느리고 자주 실패한다 |
전체 동기화 · 불필요한 데이터 포함 |
증분 동기화 · 범위 축소 |
|
회의 중에 숫자가 바뀐다 |
갱신 시각이 정해져 있지 않음 |
회의 전 갱신 완료 시각 고정 |
|
볼 수 없어야 할 데이터가 보인다 |
원본 권한을 넘는 설계 |
역할별 분리 · 민감 데이터는 별도 대시보드 |
|
차트가 너무 많아 어디를 볼지 모른다 |
추가만 하고 제거하지 않음 |
대시보드 5개 · 차트 8개 이하 규칙 |
일곱 증상 중 앞의 세 가지가 가장 흔하고, 모두 설계 단계에서 예방됩니다
Q. CRM 기본 리포트로는 부족한가요?
한 제품 안의 데이터를 보는 데는 충분한 경우가 많습니다. Analytics가 필요해지는 시점은 서로 다른 앱의 데이터를 교차해서 봐야 할 때입니다. 예를 들어 고객지원 티켓 수와 갱신율을 함께 보거나, 마케팅 채널과 회계상 매출을 연결할 때입니다.
Q. 키 매칭률은 어느 정도면 쓸 만한가요?
목표 수치를 정하기보다 '매칭 안 된 건이 무엇인지' 확인하는 편이 실용적입니다. 매칭 실패 목록을 뽑아 보면 대개 표기 형식 문제이고 일괄 정리가 가능합니다. 정리 후에도 남는 건은 예외로 관리하되, 집계에서 빠진다는 사실을 대시보드에 표기하십시오.
Q. 실시간 갱신이 필요한 경우는 없나요?
있습니다. 다만 드뭅니다. 콜센터 대기 현황처럼 지금 행동을 바꾸는 지표라면 실시간이 맞습니다. 주간 회의에서 보는 지표는 일 1회로 충분합니다. 갱신 주기를 늘리면 API 소모와 부하가 줄어 다른 연동에 여유가 생깁니다.
Q. 대시보드를 만들었는데 요청이 계속 들어옵니다.
추가 전에 '기존 차트 중 하나를 뺄 수 있는가'를 먼저 물으십시오. 이 규칙 하나가 대시보드의 수명을 크게 늘립니다. 요청이 계속된다면 1번의 질문 목록이 실제 의사결정과 맞지 않는다는 신호일 수 있으니 질문부터 다시 점검하십시오.
이 글은 Zoho Analytics로 여러 앱의 데이터를 통합 대시보드로 만드는 설계 원칙을 다룹니다. 플랜별 정가와 한도, 화면 조작 방법, 수식 문법, 개별 데이터 소스의 연동 절차는 다루지 않습니다.
이 글은 P3 구축과 운영 시리즈의 일부입니다.
본문의 원화 환산은 1 USD = 1,380원, 기준일 2026년 9월 12일을 적용했습니다. 요금과 약관은 변경될 수 있으므로 계약 전 공식 페이지에서 재확인하십시오.