The VERM disconnections sub-report explained

The disconnections sub-report inside VERM answers one plain question: how did your answered calls end? It takes every call that reached an agent within the report window and groups it by disconnection cause. For each cause you get a count, the percentage of total calls that cause represents, a small bar graph comparing the causes against one another, and a pie chart summing up the whole set. There are no formulas to memorise here; it is a clean frequency table of endings.

What each row means

Each row is one disconnection cause and the number of answered calls that ended that way. The percentage is that cause's share of all answered calls in the report, so the rows add up to roughly 100 percent. The bar graph is a quick relative read, and the pie chart is the same data in proportion form. Because the set is limited to answered calls, this is a view of how live conversations closed, not of calls that never connected. The unanswered side has its own "disconnection causes" cut that works the same way but over dropped calls, so if a cause looks alarming on the answered side it is worth checking whether it shows up on the unanswered side too before you assume the worst.

Keep in mind that the answered set is defined by the log user id being a real agent login rather than the system values VDAD or VDCL. That distinction matters here because it means every row in this sub-report represents a call a person actually handled. The disconnection cause is captured at the moment the channel closed, so it reflects how the line ended, not how long the agent was on it or whether the outcome was good. For that you look elsewhere in VERM, but as a first read of call quality this frequency table is hard to beat.

How to read it without over-reading it

A healthy outbound Campaign usually shows most answered calls ending in a normal caller or agent hangup. A sudden rise in an abnormal cause is worth a look, because it can point at carrier trouble or a misconfigured route rather than agent behaviour. Pair this with the call's Disposition to separate "the line dropped" from "the agent finished and dispositioned the call" — the disconnection cause is the technical ending, the disposition is the human outcome.

• Read the percentage column first; raw counts swing with call volume but the share is comparable across days.
• Watch for a new cause appearing that was not there last week; that is a clearer signal than a small shift in an existing one.
• Cross-check against the Ingroup or queue cut so you know whether a spike is global or isolated to one inbound stream.

How the sub-report is built

flowchart TD
  A[Answered calls in window] --> B[Group by disconnection cause]
  B --> C[Count per cause]
  C --> D[Percent of total calls]
  D --> E[Bar graph relative shares]
  D --> F[Pie chart of all causes]

Disconnection patterns make most sense next to your other VERM cuts; if you have not looked at how the system splits answered from unanswered traffic yet, the real-time main report is a good companion. For the full set of reporting screens, see the VICIdial reports overview.

VICIfast runs managed VICIdial on a dedicated server, so VERM and its sub-reports are live on your branded subdomain in under 40 seconds. See pricing to spin one up.