Case study

Building a Per-Business-Unit Zoom Billing Model Beyond Native Reporting

A multi-system reporting pipeline that turned fragmented Zoom data into a daily executive billing view by business unit.

Overview

Native Zoom reporting could not provide the business-unit allocation model leadership needed. This work created a structured data pipeline that gathered user, phone, and Contact Center data across Zoom APIs, normalized it, and delivered a usable executive reporting layer downstream.

Business challenge

  • Zoom’s native reporting could not produce a reliable per-business-unit billing structure.
  • Usage data lived across standard Zoom, Zoom Phone, and Zoom Contact Center APIs.
  • Leadership needed visibility into usage, ownership, and chargeback logic by business unit.
  • Any reporting layer had to be consistent enough to support executive review, not just ad hoc analysis.

My role

  • Designed the end-to-end data model and reporting flow.
  • Used n8n as the backbone to orchestrate token generation, API calls, transformation, and output logic.
  • Merged user, group, phone, number, and Contact Center data into a single structured reporting layer.
  • Delivered the daily data handoff that fed downstream executive reporting in SharePoint and Power BI.

Architecture

How the reporting pipeline worked

The value was not a single API call. It was the orchestration of multiple Zoom data sources into one coherent business-unit model.

Source Systems

  • Zoom Users API
  • Zoom Groups API
  • Zoom Phone APIs
  • Zoom Contact Center APIs

Orchestration Layer

n8n Workflow Backbone

  • Token generation and API auth
  • Data pulls across products
  • Normalization and record matching
  • Append-or-update sync logic

Structured Data Layer

Google Sheets

Daily user, number, phone, license, and Contact Center billing structure by business unit.

Executive Reporting

SharePoint → Power BI

Published daily into the reporting layer executives used to review usage and cost allocation.

1

Authenticate and orchestrate

n8n handled token generation and served as the control layer for the workflow.

2

Pull Zoom user data

Gathered users, user details, group membership, and license context across the Zoom estate.

3

Enrich with Phone and Contact Center

Joined phone numbers, phone usage, calling plans, Contact Center roles, teams, and usage data.

4

Normalize and sync

Applied transformation logic, stable record matching, and append-or-update behavior for repeatable daily refreshes.

5

Deliver executive reporting

Published to Google Sheets, then uploaded daily to SharePoint as the backbone for Power BI reporting.

Key design decisions

  • Use n8n as the orchestration layer so API logic, transformation, and refresh behavior stayed centralized.
  • Build around business-unit reporting needs rather than forcing leadership into native Zoom views.
  • Combine identity, licensing, phone, number, and Contact Center data into one downstream-friendly structure.
  • Create a repeatable daily handoff model so reporting could support executives instead of manual analyst effort.

Outcome

  • Created a billing and usage model that Zoom reporting could not provide natively.
  • Gave executives a clearer view of user, number, phone, and Contact Center costs by business unit.
  • Established a daily reporting backbone from Zoom APIs to Google Sheets, SharePoint, and Power BI.
  • Improved reporting confidence by replacing fragmented exports with one structured pipeline.