How Next Agent Email decides who gets the next email

When an inbound email arrives on a VICIdial email group, the system has to decide which agent gets it. That decision is made by a single field on the email group called Next Agent Email. It works the same way agent routing works for inbound calls: only agents who are available and logged into that group are considered, and the chosen ordering method picks one of them.

An email behaves much like a call. It pulls the customer's record onto the agent's screen and locks the Lead so the agent will not get another call or email while they work it. When they finish, they apply a Disposition and become available again. So picking the right Next Agent Email method matters for how evenly your team's workload is spread.

The ordering methods

Next Agent Email offers a list of methods. Each one sorts the pool of available agents differently and then hands the email to whoever ends up first in that order:

• random: orders by a random update value, so emails land more or less by chance.
• oldest_call_start and oldest_inbound_call_start: order by the last time an agent was sent an email. This evens out the total each agent receives.
• oldest_call_finish and oldest_inbound_call_finish: order by the last time an agent finished an email, so the agent who has been waiting longest gets it.
• overall_user_level: orders by the agent's user level, so a higher user level receives more emails.
• inbound_group_rank and campaign_rank: order by the rank you gave the agent, highest to lowest.
• ingroup_grade_random and campaign_grade_random: give higher-graded agents a higher probability, not a guarantee.
• fewest_calls and fewest_calls_campaign: order by how many emails each agent has already taken, fewest first.
• longest_wait_time: orders by how long an agent has been actively waiting for an email.
• ring_all: rings every available agent at once, intended only for a few agents on a low-volume group.

How the choice flows

Whatever method you pick, the path from an incoming email to a chosen agent is the same. The system gathers the available agents in that group, sorts them by your method, and assigns the email.

flowchart TD
  A["Inbound email arrives"] --> B["Find available agents in this group"]
  B --> C{"Next Agent Email method"}
  C -->|oldest wait| D["Agent waiting longest"]
  C -->|fewest_calls| E["Agent with fewest emails"]
  C -->|user_level / rank| F["Higher-level or ranked agent"]
  C -->|grade_random| G["Higher-graded agent, by probability"]
  D --> H["Assign email, lock lead"]
  E --> H
  F --> H
  G --> H

A handy way to think about the families: oldest-wait methods reward whoever has been idle longest, fewest-emails methods chase a flat count, and the rank, user-level, and grade methods push more work toward specific people. The grade methods only shift the odds rather than forcing the outcome. Most teams start with one of the oldest-wait or fewest-emails methods for a fair spread, then move to a rank, level, or grade method once they know which agents they want carrying more of the load. You can change the method at any time, so it is worth trying one for a few days and watching how the totals land before you commit.

If you want a deeper comparison of the two most common choices, read oldest-wait versus fewest-emails. For the full picture of how email groups fit alongside calls, see the inbound email and chat guide. The same routing ideas apply to an Ingroup, an Agent, and any Closer you assign to a queue. If you would rather run all of this on a managed box without wiring up parsers yourself, our pricing page lays out the plans.