What Is a Call Log (CDR)?

What exactly a CDR is

The initials CDR come from English: Call Detail Record — a record of the details of a call. Every call that passes through the PBX leaves such a record behind, just as every credit card payment leaves a line on the billing statement. The record doesn't contain the content of the call, but its "metadata": who, to whom, when, how long, and what happened along the way.

The term was born in the world of phone companies, where the records were used mainly for billing: you need to know how many minutes each subscriber talked and to which destination. Over the years it became clear that the same information is worth much more than an invoice. An organization that knows how to read its call log knows when it's busiest, how many customers give up before being answered, and which agent answers fastest.

In a cloud PBX the log is saved automatically, with no setup on your part. Every incoming, outgoing and internal call is recorded — even a call that lasted two seconds, and even a call that no one answered. Exactly these unanswered calls are sometimes the most important information in the log.

What is recorded in each record

The exact details vary from system to system, but in most PBXs you will find these fields:

Note the difference between total duration and call duration. A call that waited four minutes in a queue and was answered for one minute lasted five minutes from the caller's point of view, but only one minute of talking. Anyone who confuses the two gets reports that look too good — or too bad.

One call, several "legs"

This is the part that confuses most people who open a raw call log for the first time. Technically, a call that passes through several components is recorded in several parts — "legs." The caller enters the menu: one leg. Moves to a queue: another leg. The queue rings extension 204 and the agent answers: another leg. And if the agent transfers to a different extension — one more.

A raw log that shows each leg as a separate row looks as if the same customer called five times in a row. This causes real mistakes: an agent calls back a customer who "kept calling and calling," or a manager thinks the load is double what it is. A good log merges the legs into one row — one call in a person's eyes — and shows the full route inside it, from beginning to end.

Another trap: a call that rang on several phones at once (for example in a hunt group) creates a leg for each phone, but only one answered. The log needs to be able to say who actually answered, and not count the call as "unanswered" for all the others.

What you can learn from the log

• Unanswered calls — a list for calling customers back. In a small business this is sometimes the most profitable action of the morning.
• Load by hours and days — when you need more agents, and when you can release some.
• Wait times — how long people wait in the queue, and at what hour the waits get longer.
• Abandonment — how many hung up before being answered, and after how long.
• Agent performance — how many calls each one answered and what the average call length is.
• Investigating a case — a customer claims he called on Tuesday and no one answered? Search for the number and see exactly what happened.

An example from real life: a store in Bnei Brak discovered in the log that 40% of the unanswered calls come between 13:00 and 14:00 — exactly during the lunch break. Instead of hiring another employee, they shifted the breaks so that someone is always near the phone, and sent the lunch hour to a queue with a message.

CDR, recording and report — what's the difference

The log is the "what happened." The recording is the "what was said." A report is a summary of many records together — averages, graphs, comparisons. The three complement each other: in the report you see that on Sunday there were many long calls, in the log you find them, and in the recording you hear why.

The call log is also the basis for any smarter integration. A CRM system that shows a customer's call history, or an automatic monthly report sent to management — all of them pull the information from the log, usually through an API.

Common mistakes and tips

• Counting legs instead of calls — the number one reason for inflated reports.
• Measuring wait time from the start of the call — the time the caller spent in the main menu is not queue waiting. Real waiting is measured from the moment he entered the queue.
• Ignoring very short calls — a two-second call is usually a misdial, but ten of them in a row from the same number is a sign that something in the menu isn't working.
• Not exporting before things are deleted — the log has a retention period. Whatever matters to you in the long term, save in a file.

A simple tip: set yourself a five-minute "morning check" — filter for yesterday's unanswered calls, and get back to everyone who didn't get an answer. It's the cheapest habit that improves service.

How to read a log: six rows and what they mean

The fastest way to learn to read a log is to go over a few real rows. These are six rows from one morning of a small office (the numbers are made up):

Row 1 — a regular call: it entered the menu, chose service, was answered within 12 seconds, and talked for four and a half minutes. Nothing to check. Rows 2–3 — the interesting story of the morning: a customer from a landline waited in the queue for two minutes and forty seconds, hung up, and tried again right away — and then hung up after four seconds in the menu. Two things to learn from this: that at 09:15 there was no available agent, and that this customer is waiting for a callback. Row 4 — an outgoing call from extension 205 to a cell phone; in the log it appears with no wait because there is no queue. Row 5 — an inquiry to sales during the lunch break, 45 seconds of ringing and then voicemail. If this repeats every day at the same hour, it isn't a malfunction, it's a lunch break with no coverage. Row 6 — an internal call between two extensions, probably the consultation about the 13:20 call.

A good habit: don't read row by row, but "by number." The two rows for 03-000-2222 are one customer and one event, and that is exactly what filtering by number reveals in a second.

Questions the log answers in a minute

Most people open the log only when there is a problem. That's a pity — it answers everyday questions faster than anyone in the office. Here are a few examples, with the filter that brings the answer:

The seventh question brings the log back to its roots: it was born for billing, and even today it is the best tool for checking what you pay for and why.

Export and reports: from the log to a management picture

The on-screen log is good for pinpoint inquiries. For a picture of a month, you need to export. The export is a table file — a row for each call, a column for each field — that opens in any spreadsheet. From there, three simple operations are enough for most reports:

• Count by hour — take the hour column, group by hour of the day, count calls. This is your load graph, and it's the basis for deciding when you need another agent.
• Count by result — how many were answered, how many hung up in the queue, how many reached voicemail. The percentage of "not answered" out of the total is the one number worth tracking every month.
• Average by agent — average call duration and average answer time for each extension. Not in order to punish, but to see who needs training and who can train.

A reasonable monthly report for a small business is one page: number of calls, answer rate, average wait time, the three peak hours, and the list of calls that were not answered and did not get a callback. More than that — people read it once and don't come back.

Two tips for exporting: export before the log's retention period ends, and save one file per month under a consistent name ("calls-2026-09") — that way you can compare year over year. And if you want the report to build itself, without opening a file, turn to the API: pulling the calls into another system that already knows how to draw graphs.