B BROCENT

How to Analyse Cloud PBX Call Data with Gemini

How to analyse cloud PBX call detail records with Gemini: the export fields that matter, time-zone and holiday traps, a worked staffing example, and the call-data privacy rules to settle first.

Support agents working at computers with headsets in an open-plan office
The short answer: Export three months of call detail records from your cloud PBX, give Gemini your office hours, time zones and holiday calendar as context, and ask for answered-versus-abandoned rates by local hour and weekday instead of a monthly average. The pattern that surfaces is almost always a coverage problem rather than a phone-system problem — which makes it a staffing decision, not a procurement one.

Ask an operations manager how many calls the business misses in a typical week and you will usually get a shrug, or a number half-remembered from a report someone circulated last quarter. Ask whether the front desk is understaffed and you will get a confident answer with nothing behind it. Both questions have precise answers, and those answers have been sitting inside the phone system the entire time.

This is a walkthrough of getting them out: what to export from a cloud PBX, how to prompt Gemini so the numbers mean something, and — the part most guides skip — the privacy exposure you create the moment you export a file full of customer phone numbers.

What Your Phone System Already Knows That Nobody Looks At

Every cloud PBX writes a call detail record, or CDR, for every call that touches it. A typical record carries a timestamp, direction, the calling and called numbers, the queue or extension that received the call, how long it rang, how long it was connected, a disposition code (answered, abandoned, voicemail, busy, failed), and often which agent picked up. Three months of traffic for a small or mid-sized company is usually somewhere between a few thousand and a few tens of thousands of rows.

That size is the awkward middle: far too much to eyeball in a spreadsheet, far too little to justify a business-intelligence project or a workforce-management platform. So in practice nobody looks, and the conversation about phone coverage stays anecdotal — driven by whoever complained most recently.

Meanwhile the built-in dashboard on a hosted cloud PBX platform will happily tell you that 94% of calls were answered last month. That number is true and almost useless. The missing 6% is not sprinkled evenly across the month — it is concentrated in specific hours, on specific days, in specific queues, and usually on calls from one particular market. Finding that concentration is the whole exercise.

Getting Usable Call Data Out of a Cloud PBX

Nearly every hosted PBX exposes CDRs as a CSV export from its admin console, and most also offer an API for the same data. If your phone system is integrated into Microsoft Teams through a certified session border controller, the record is often split: the PBX holds the trunk-side leg and Teams holds the client-side leg. Export both and reconcile them on the call identifier, or you will silently drop every call that was answered in Teams rather than on a desk phone.

Ask for the widest date range the console will give you in a single file; three months is the working minimum.

CDR exports — the fields that matter and the ones that mislead

  • Disposition is the field the entire analysis hangs on, and it is the one platforms define most inconsistently. Read your vendor's documentation for what each code actually means before you interpret anything.
  • Abandoned is not the same as missed. An abandoned call is one where the caller hung up before anyone answered. A missed call frequently means one extension in a ring group did not pick up — while a colleague answered it two seconds later. Count both as failures and you will invent a crisis that does not exist.
  • Ring duration before answer is the most under-used field in the file. Average speed of answer tells you more about caller experience than the answer rate does, and it moves earlier: queues degrade in ring time well before people start hanging up.
  • Talk duration on its own is close to meaningless. A three-minute call is good if it resolved something and bad if the caller was transferred twice.
  • Repeat callers need collapsing. The same number dialling three times in fifteen minutes is one unsatisfied customer, not three calls. Left uncollapsed, repeat dialling inflates your volume precisely in the hours where your coverage is worst.
  • Internal extension-to-extension traffic should usually be excluded. It is real usage but not customer demand, and it distorts every ratio you calculate.

Time zones, public holidays, and why raw averages hide the problem

CDR timestamps are typically stored in UTC, or in whatever time zone the tenant was configured with years ago by someone who has since left. If your customers are in Japan, your desk is in Hong Kong and your overflow sits in Singapore, an analysis that never converts to local time produces a chart that is wrong in a way nobody catches.

Tell the model the tenant time zone explicitly, state which local time zone you want results in, and hand it your public-holiday list. Hong Kong, mainland China, Japan and Singapore holiday calendars do not line up, and Golden Week or Lunar New Year otherwise shows up as a fortnight of "unexplained low volume" that quietly drags every average down.

The prompt that works is unglamorous. Upload the CSV, then supply the context the file cannot carry on its own: business hours per site, headcount on the desk per shift, what each disposition code means in your platform, the holiday list, and the specific question you want answered. Check Gemini's current documentation for file size and format limits before you plan around a very large export — if the file is too big, split it by month and analyse each part separately.

A Worked Example — From Three Months of CDRs to a Staffing Recommendation

Take a 140-person manufacturer with a Hong Kong head office, two plants in Guangdong, and customers across Japan and Southeast Asia. Roughly 11,000 inbound external calls over three months. The PBX dashboard reported 91% answered, which everyone had long ago agreed was fine.

The first prompt was deliberately narrow: group calls by local hour of day and by weekday; for each bucket report total inbound, answered, abandoned, and median ring time before answer or abandonment; exclude internal extension calls; treat calls from the same number within fifteen minutes as a single attempt.

Three things fell out of the result. The first hour of the working day turned out to be the worst hour of the week: calls arriving between 08:00 and 09:00 Hong Kong time made up roughly a seventh of the week's inbound volume and abandoned at more than three times the daily rate. The desk was rostered from 09:00. Customers in Japan, an hour ahead, had been calling into an empty office for years.

The second was lunch. Between 12:30 and 13:30 abandonment roughly tripled and median ring time went past forty seconds. The desk was nominally on a rota, and in practice was not.

The third was smaller and more interesting: a persistent evening tail of Japanese-language calls after 17:30 — low in volume, very high in abandonment, because the one bilingual staff member had already gone home.

None of those findings is visible in a 91% answer rate.

Do not ask the model to count. This is the single most important habit in the whole workflow. Language models are unreliable at arithmetic across thousands of rows; they will approximate, sample, or confidently produce a plausible total. Ask Gemini instead to write the aggregation — a Google Sheets formula, a pivot specification, or a short Python snippet you can run over the CSV yourself. Then run it and compare. Use the model for the shape of the question and the interpretation of the answer; use deterministic arithmetic for the numbers. Every figure that reaches a manager should be reproducible without the model.

The staffing question needs the same discipline. Asking "how many agents do we need?" invites a confident guess. Asking "given a median handle time of four minutes and a target of no more than 5% abandonment, what hourly coverage does each of these buckets imply, and show your working" gets you arithmetic you can check — and argue with.

AI-Assisted Analysis vs Built-In PBX Reporting vs a Contact-Centre Platform

  • Built-in PBX reporting is free, live, and already switched on. It is genuinely good for totals, per-extension activity and trunk utilisation. It is weak wherever the question cuts across dimensions — hour by market by queue by disposition — because it only answers the questions its designers anticipated.
  • AI-assisted analysis of a CDR export is the right tool for one-off diagnostic questions, and it costs nothing to procure. You can ask an unanticipated question at 10pm and have a defensible answer before midnight. The limits are real: it is a snapshot rather than a live view, someone has to do the export, and every number needs verifying.
  • A contact-centre platform buys real-time queue management, forecasting, adherence tracking and per-agent quality scoring. It earns its licence cost when calls are your primary customer channel and you have fifteen or more agents. For a six-person desk that answers the phone alongside other work, it is a large recurring cost aimed at a problem a spreadsheet and a good question can diagnose in an afternoon.

The honest sequence is diagnose first, buy second. A surprising share of companies about to purchase a contact-centre platform discover their actual problem was a roster.

The Answer That Isn't a Phone-System Problem

In almost every one of these analyses the conclusion is not "the phone system is inadequate". It is "nobody is at the desk at 08:15", or "the only person who can answer in Japanese works one time zone away and finishes at 17:30", or "overflow routes to a voicemail box that gets checked twice a day".

Those are coverage decisions, and there are only a few real levers. You can move the roster, which is free and is often enough. You can extend the coverage window, which means either paying for early and late shifts or routing out-of-hours traffic to a multilingual help desk that already runs 24×7. You can change routing so unanswered calls overflow somewhere staffed instead of into voicemail. Or you can decide the abandonment is acceptable — a perfectly legitimate answer, as long as it is a decision rather than an accident.

The analysis is what turns it into a decision. "We should probably get more phone cover" loses a budget conversation every time. "We lose 34% of calls in the 08:00 hour, that hour is 14% of our inbound volume, and most of it is Japan" does not.

Getting This Right — Call Data Privacy, Recording Consent, and When to Bring In IT

A CDR export is a file of customer phone numbers with timestamps attached. That is personal data under Hong Kong's PDPO, Singapore's PDPA, mainland China's PIPL and the GDPR — the number identifies a person and the call pattern says something about them. Before it goes anywhere near an AI tool, four things need settling.

  • Pseudonymise before you upload. Hash the caller number, or truncate the last four digits, and keep the mapping outside the file. Counting calls per hour does not require knowing who called. This single step removes most of the exposure at almost no analytical cost.
  • Treat recordings and transcripts as a different category entirely. CDRs are metadata; recordings are content, and across most APAC jurisdictions they carry notification or consent obligations, longer retention arguments, and much harder cross-border transfer questions — particularly for data originating in mainland China under PIPL. Nobody should be uploading call recordings to a general-purpose AI tool on their own initiative.
  • Use the enterprise tier, not a personal account. Data handling, retention and model-training commitments differ between the consumer and business tiers of every major AI service. If your organisation has not signed the relevant agreement, the analysis has not been approved — it has merely happened.
  • Decide where the file lives afterwards. Three months of customer call records sitting in an employee's Downloads folder, or on a personal cloud drive, is a breach notification waiting for a lost laptop.

This is where the workflow stops being a clever prompt and starts being IT governance. Our AI+ Support service covers exactly this ground: choosing the right tier, setting data-handling rules, and making pseudonymisation routine rather than something the analyst remembers to do. The export, the API access, the retention policy and access control sit with whoever runs your infrastructure day to day — for many of our clients, Brocent's managed IT support team. For a second opinion on your own call data before a platform purchase, get in touch.

Frequently Asked Questions

Are call detail records personal data under PDPO, PDPA or PIPL?

Generally yes. A phone number is an identifier, and a CDR links it to times, durations and the department called. All three regimes treat that as personal data. Pseudonymising the number before analysis substantially reduces the risk and does not affect volume or timing analysis at all.

Do we need consent to analyse call recordings with AI?

Recordings are a materially higher bar than CDRs, and the answer depends on your jurisdiction and on what you told callers at the time. If your recording announcement covered quality and training only, feeding those recordings to a third-party AI service may exceed the stated purpose. Get this reviewed before you start.

What is the difference between an abandoned call and a missed call?

An abandoned call is one where the caller hung up before it was answered — a direct measure of patience running out. A missed call, in most platforms, means a specific extension did not answer, which is routine in ring groups where someone else picks up. Abandoned matters for customer experience; missed is frequently noise.

Can this actually tell us how many people we need on the phones?

It tells you precisely when demand exceeds coverage, which is the input to that decision. It will not produce a defensible headcount on its own — any tool claiming to without knowing your handle times and escalation rate is guessing. Size the gap with the analysis, then apply your own service target.

Does this work with Microsoft Teams telephony?

Yes, with one caveat: when a PBX is integrated into Teams through a certified session border controller, the call record is often split between the two systems. Pull both sets and join them, or your answer rate will be wrong in favour of the desk phones. Check what your specific deployment writes where before you trust a single export.

How much call history do we need for this to be meaningful?

Three months is a reasonable minimum. One month cannot distinguish a pattern from an unusual few weeks, and may not contain a public holiday or seasonal peak. More than a year usually reflects staffing you have since changed.

Share:

Ready to take action?

Turn these insights into a roadmap for your business.

Book a 15-minute no-obligation consultation with our APAC IT experts. We'll review your current setup and provide a tailored IT roadmap within 24 hours.

📋

Free Checklist

10 Critical Checks Before Expanding IT to Greater China

PIPL compliance, network segmentation, bilingual helpdesk setup, and more — everything your IT team needs before Day 1 in China.

Request the checklist →