What Your Call History Data Says About Your Brokerage
MaxoTel's hosted PBX keeps a structured record of every inbound and outbound call on the service, and that record can be in a spreadsheet on your desk inside ten minutes. This article covers what a call detail record actually contains, how to get a month of it out through the account portal or the Call History API, and the five views worth building from it before anything else. It also sets out precisely what call history data cannot answer, because knowing where that line sits is what stops a reasonable number being read as more than it is. By the end you will know which operational questions your existing export already answers and which ones need a different source.
Your phone system has been keeping this record all along
A brokerage running MaxoTel holds a structured record of the client calls that reached it, for as long as its own history and retention settings have kept them. Not the conversations themselves, but the shape of them: when each call arrived, which number it came in on, how long it ran, whether it connected, and whether audio was kept.
That record is not a report anyone has to commission. It is produced automatically as a by-product of running the phone, and on MaxoTel it is available two ways: on screen in the account portal with a download button underneath it, and through the Call History API, which returns call detail records as CSV or JSON for a nominated period.
This is worth an afternoon because most of the operational questions a principal asks during a renewal season are questions about volume, timing and reachability. When do calls actually arrive, and on which days. Which published number carries the load. How many callers did not get through. MaxoTel's call history covers the inbound and outbound calls on the service rather than a sample of them, and getting at it needs no new software.
What a brokerage gets out of the export does depend on decisions made earlier. Routing structure determines how separable call types are once they are in the record, which is why how the phone system was set up at the beginning shows up again here. A firm with a single published number will read volume and duration accurately and will find call type harder to isolate. A firm with separate renewal, claims and general numbers gets that separation for free in every row.
The gap worth closing is not a data gap. For most brokerages running a hosted PBX, the data has been accumulating since the day the system went live. It is a reading gap, and it closes with an export and a pivot table.
What a call detail record contains, and how to get it out
A call detail record is one row per call, and MaxoTel produces one for every inbound and outbound call on the service whether or not recording is switched on. It is reachable two ways, the account portal and the Call History API, which present it differently and do not expose an identical field set.
The Call History API documents what each record returns. Every row carries a unique call ID, the date and time in both readable and Unix formats, the call direction, the originating party number, the terminating party number, a plain-text description of the rate category, the call completion status, the duration in seconds, the same duration in a friendly hours-minutes-seconds format, the call cost, and a flag showing whether a recording exists for that call. One further field, a statistics identifier, is documented as unused.
MaxoTel documents 14 fields per record. One of them, a statistics identifier, is marked unused, which leaves 13 that carry information about the call. There are two ways to get those records out, and the right one depends on what happens next.
The portal export, for a spreadsheet. The account portal's call history view takes a start date and an end date, both inclusive, and displays the matching calls as a table with type, time, origin, destination, recording, rate, status, duration and cost columns. Advanced options filter by call type, by answered or unanswered status, by duration above or below a set number of minutes, and by cost. Rather than displaying the results, Download CSV returns the same set as a file. For a principal or operations manager who wants to look at last month and does not want to write anything, this is the whole process.
The API, for anything that repeats. The Call History API returns call detail records through a standard HTTP request to MaxoTel's API host, using the calls list endpoint. Three parameters are required: an API key, a start time and an end time, each accepted as either a Unix timestamp or an RFC date. The documentation treats the start time as inclusive and the end time as exclusive, which is worth knowing before stitching consecutive months together. Output format defaults to JSON and can be set to CSV. Optional parameters filter to connected calls only, filter to charged calls only, add a header row to CSV output, add the human-readable duration, and set a record limit, which defaults to and caps at 10,000 records per request.
Access requires a key, and creating an API key is done in the account portal against a specific permission set. Call History needs read permission. Generating CSV output through the API needs the Download CSV permission allowed as well, which is a separate tick and easy to miss on a first attempt.
The practical division is simple. CSV into a spreadsheet suits a monthly read by a person. JSON suits anything scheduled or feeding a dashboard, and anything that needs to run without someone remembering to run it. Starting with the portal download and moving to the API once the reading has become a habit is the sensible order.
Your phone system has been counting every call since the day it went live.
Callyx.ai works on the recordings a business already holds, so the conversations behind those records become something you can actually read.
What the export cannot tell you
The field list is the boundary. Everything in it can be counted, sorted and charted. Anything outside it needs a different source, and knowing which is which before building a view saves rebuilding it later.
The export does not name the person who took the call
The documented fields identify the number at each end of the call, not the staff member. Per-broker activity does exist, but it sits in a different place: the portal's PBX statistics report includes an agent call distribution table with total calls per agent, calls where the agent hung up first, total and average duration, and shortest and longest call. That is a separate on-screen report with its own filters rather than a column in the export, and MaxoTel notes that PBX statistics may not be available on every plan. Anyone planning a per-broker view should check both of those before designing around it.
The export does not carry wait time or abandonment
How long a caller waited before someone picked up, and how many abandoned the call, which MaxoTel defines as hanging up before being answered by an agent or leaving a voicemail, are queue measures. They appear in the same PBX statistics report, broken down by queue and by the number the caller dialled, with answered, voicemail and abandoned counts alongside average, shortest and longest wait. The report also charts wait times and abandonment against incoming call volume in 30-minute blocks, which is where a day's pressure shows up. None of it is in the call history export.
The connected status carries a caveat
MaxoTel's own portal documentation notes that where an IVR is in use, a call is marked as connected as soon as the IVR picks up. A brokerage whose main number opens with a menu will see a connected rate that reflects the menu answering rather than a broker. The figure is not wrong, but it answers a narrower question than it appears to, and it is worth reading next to the queue-level answered and abandoned counts rather than on its own. The same caution applies to several of the standard call metrics a brokerage might track, which is a useful companion read before setting definitions.
The destination field behaves differently for inbound calls
The API documents destination as the terminating party number. The portal guide adds that for inbound calls the column shows the recipient and the type of destination. What exactly appears there for a given queue or ring group is not specified in the documentation, so a month of real export is the only reliable way to find out what your own configuration produces. Test before building anything that depends on it.
One request returns at most 10,000 records
For most brokerages a month sits comfortably inside that. For a busy firm pulling a quarter, or automating a first historical load, the limit needs a date-range loop rather than one large request.
The largest boundary of all: it tells you a call happened, not what was said
Every field in the record describes the container. Duration says a conversation ran for 14 minutes. Status says it connected. The recording flag says audio exists. None of them says whether the client's turnover was confirmed before quoting, whether a premium increase was explained in a way the client accepted, or whether an objection went unanswered. Those sit in the audio, and reaching them through manual review is possible at small volumes and gets harder in direct proportion to how well the brokerage is going.
The five views worth building first
The five views below are our selection rather than a standard, and they are where we would start. Each one is a pivot on a single documented field, and all five can be built from a single month of CSV.
Volume by hour and by weekday
Pivot the date and time field into hour-of-day and day-of-week buckets and count calls in each. This is the view that tends to surprise people most, because the shape of a brokerage's week is rarely what the roster assumes. A Monday morning spike, a quiet hour after 4pm and a Wednesday running heavier than Thursday all show up immediately, and each becomes a rostering decision rather than an opinion once it is on a chart. Run it again across a renewal period and it becomes a capacity plan.
Volume by number dialled
Where a brokerage publishes more than one number, group inbound calls by the destination field and count. Check first that the field carries the dialled number in your own configuration, because as set out above the documentation does not commit to what it returns behind a queue or ring group. Where it does, this tells you which line is carrying client demand, which is not always the one that gets the most attention, and whether a marketing number, a claims line or an after-hours number is earning its place. Where it does not, the queue breakdown in PBX statistics reports the same thing by the number the caller dialled.
Connected against unanswered calls
MaxoTel's status field separates calls it marks connected from calls it does not. Grouped by hour and by number, the unanswered rows are the closest thing the export holds to a measure of demand the firm did not serve, and it is an imperfect proxy rather than a count. Where an IVR sits at the front of the call flow, MaxoTel marks the call connected the moment the menu picks up, so the connected side of this view can include callers who never reached a broker. Treat it as a prompt to look at the queue report rather than as a final answer.
Call length distribution
Not average duration, which flattens everything interesting about a brokerage's call mix into a single number that moves for reasons nobody can explain. Bucket the duration field instead. Under one minute, one to three, three to eight, eight to 20 and over 20 are buckets we have chosen rather than anything the phone system defines, so adjust them to your own call mix. The under-one-minute bucket is the one to look at first, because it can hold wrong numbers, misroutes and conversations that ended before they started, and its size relative to everything else is worth explaining rather than assuming. The long tail matters too, and where the buckets sit is more useful than where the mean sits.
Repeat callers
Filter to inbound calls first, then group by the origin field, count calls per number across the month and sort descending. The inbound filter matters: on an outbound call the originating party is your own service, so an unfiltered view ranks your brokers rather than your clients. What comes back is repeated originating numbers, which is not quite the same as repeated clients, since a switchboard or a mobile may not map cleanly to one account. Some of what surfaces is normal: a large account with an active claim will appear often and should. What the view adds is the pattern nobody has noticed, where the same number appears four times inside a fortnight and nothing in the file explains why. It is one of the more commercially useful things a raw export can point at, and it needs no new software to produce.
Recording coverage, a sixth quick check
A sixth quick check is worth running once even if it never becomes a habit: group by the recording flag and see what proportion of calls have audio attached. Where that percentage is lower than expected, a per-extension exclusion or a recording setting narrowed at some point and never revisited are two possible causes worth checking, among others. It is also the number to know before relying on recordings for anything, including call recording compliance obligations.
The export tells you the call happened. The recording holds what was said in it.
Callyx.ai automatically monitors 100% of your recorded calls, which is the layer your call history counts but cannot describe.
Book a DemoHow Callyx.ai fits
The five views above need no new software, and a brokerage that builds them will know a good deal more about its own call activity than it did. What it will still not have is any information about the content of those calls, and that limit is structural. A record built from numbers, timestamps and durations cannot describe a conversation.
The call history record flags which calls have audio attached. What is in that audio is a separate question, and it is the one Callyx.ai answers. Callyx.ai works on the recordings a business already holds, transcribing and analysing them, so a call that currently reads as 14 minutes and connected on Tuesday becomes a conversation with a summary, extracted action items and a record of what was discussed.
Core
Included in all plans. Core transcribes and stores every call, produces an AI-generated summary and extracts action items after the call ends. This is the layer that turns the recording flag from a yes-or-no marker into readable content, and it is also what makes the repeat-caller view explicable: the export shows the same number ringing four times in a fortnight, and the transcripts show what each of those calls was about.
Insights
On the Professional plan. Insights tracks conversions, retention and referrals, maps the patterns that predict those outcomes and surfaces objections that went unaddressed. This is the layer that attaches a business outcome to a pattern the call history view only counted.
Coach
On the Professional plan. Coach works against a definition of excellent that the firm writes itself, flags missed qualification moments and produces structured feedback for the broker. Where the call length distribution raises a question about a set of short calls, Coach is what answers it with specifics rather than an impression.
Comply
On the Professional plan. Comply maps the firm's compliance obligations, monitors disclosures and fee mentions, and applies per-call compliance flags across every call rather than a sample.
Nothing about how brokers take calls changes, and no review task is added to anyone's day. The phone system carries on producing the same call history it always has.
Practical steps
Export one full month as CSV and open it
Use the portal's call history view, set a start and end date covering a complete month, and click Download CSV. Look at what actually comes back before designing anything. Configurations differ, and your own export is the only reliable description of what your system holds.
Build the volume-by-hour view first
It takes one pivot on the date and time column and it is the view most likely to change a decision this month. Roster and routing questions both fall out of it immediately.
Check what the destination column contains for your inbound calls
This is the field that determines whether call types are separable in your record. If everything arrives as one value, that is worth knowing before building any view that assumes otherwise, and it is a routing conversation rather than a reporting one.
Generate an API key once the monthly read has stuck
Create a key in the account portal with Call History read permission, and add the Download CSV permission if you want CSV output through the API. Then schedule the pull. Moving to the API before the habit exists usually produces an automated report nobody opens.
Write down what each view is for, in one line each
Which decision it informs, who reads it and how often. Five views with a stated purpose beat fifteen that exist because the data allowed them, and this is the step that keeps a reporting habit alive past its second month.
Summary
A call history export is an asset most brokerages already own and few open. It covers the inbound and outbound calls on the service rather than a sample of them, it needs no new software, and on MaxoTel it comes out as a spreadsheet or as JSON with a documented field for the time, direction, origin, destination, duration, status, cost and recording state of each call. Volume by hour, volume by number dialled, connected against unanswered, call length distribution and repeat callers are five views worth building from it, and each one answers an operational question a principal is already asking.
The boundary is worth holding clearly. The export describes the shape of a conversation and says nothing about its content. Per-broker and per-queue figures sit in a separate portal report rather than in the export. And the questions that matter most in a brokerage, about what was actually said on a renewal call and whether it went the way it should have, are not in any field because they were never in the data to begin with. They are in the recordings, which is where Callyx.ai works: transcribing and analysing the calls a business already holds, so the activity the export counts and the conversation that produced it stop being two separate reading problems.
| Operational question | Call history field | View to build |
|---|---|---|
| When do calls actually arrive? | Date and time | Count of calls by hour of day and day of week |
| Which published number carries client demand? | Destination | Count of inbound calls grouped by number dialled, once the field is validated against your configuration |
| How much demand are we not reaching? | Status | Unanswered calls as a share of inbound, by hour and by number, read with the IVR caveat |
| Are conversations getting longer or shorter? | Duration | Call counts bucketed by length, buckets set by you, not an average |
| Which numbers are ringing repeatedly? | Origin | Calls per originating number on inbound calls only, sorted descending |
| Do we have audio where we think we do? | Recording flag | Share of calls with a recording attached, by direction |
| Who answered, and how long did callers wait? | Not in the export | PBX statistics report: agent call distribution and queue breakdown |
| What was actually said on the call? | Not in the export | The recording, transcribed and analysed |
Frequently Asked Questions
About the Author
Vincent Keogh
Vincent is an operations specialist on the Callyx.ai team, writing for compliance managers and principals on how to get maximum value from recorded calls: across compliance, staff training, and business performance.
Related Articles
Your calls are already being recorded.
Now make them count.
Recorded advice conversations are reviewed against your compliance criteria, with issues flagged and documented. Less reliance on sampling. Fewer blind spots.