What the VERM transfers sub-report shows

The transfers sub-report inside VERM is one of the simpler cuts, and that simplicity is the point. It takes the calls matching your report criteria and, for each destination in-group, shows how many transfers were made into it. Alongside the raw count it shows that in-group's share of all transfers pulled for the report. So if your agents pushed 400 calls onward during the period, this report tells you exactly where those 400 went and in what proportion.

Per in-group, not per agent

The breakdown is keyed on the destination Ingroup, the call queue a transferred call lands in. Each row is one in-group, the number of transfers it received, and the percentage that count represents against every transfer in the report. The percentages add up to roughly 100 percent across the rows, so a single dominant row means most onward traffic funnels into one queue. This is a routing view, not an agent-productivity view; it does not tell you which agent transferred what, only where calls ended up.

A transfer in VICIdial can be a Warm transfer, where the agent stays on the line to introduce the caller, or a Cold transfer, where the agent drops off and the call moves on alone. The transfers sub-report counts the destination regardless of style, so read it as "where did calls go" rather than "how were they handed over." That makes it a clean read on routing rather than on agent technique, and it pairs naturally with the answered-calls-by-queue cut, which shows how many calls each queue ultimately handled. Reading the two together tells you whether the in-groups receiving the most transfers are also the ones answering the most calls, or whether work is piling up faster than a queue can clear it.

What the shares tell you

• A heavily skewed distribution usually means one in-group is doing most of the closing work; check it has the staff to match its share.
• An in-group you did not expect to see receiving transfers can point at a misconfigured menu or a Closer route sending calls to the wrong queue.
• A near-zero share for a queue that should be busy is worth investigating; transfers may be failing before they land.

One thing the transfers cut deliberately does not do is tell you the outcome of the transferred call. It stops at the destination in-group; whether the receiving agent closed, lost, or re-transferred the caller is recorded in the answered and unanswered reports for that queue. So treat this report as the first hop in a chain. When you see a large share landing in one in-group, follow it into that queue's answered breakdown to see if the volume is being handled or simply absorbed. Read across the period rather than a single hour, since transfer volume swings with staffing and time of day, and a one-off spike rarely means a routing problem on its own.

How a transfer is counted

flowchart LR
  A[Agent transfers call] --> B{Destination in-group}
  B --> C[Sales queue]
  B --> D[Support queue]
  B --> E[Verification queue]
  C --> F[Count and percent per in-group]
  D --> F
  E --> F

Transfer patterns read best next to the rest of your queue numbers. For a live view of how each in-group is loaded while calls are moving, see the real-time main report, and for the full set of reporting screens start with the VICIdial reports overview.

VICIfast delivers managed VICIdial with VERM in place from the first call, on a branded HTTPS subdomain provisioned in under 40 seconds. See pricing to get going.