Auto answer in Genesys Cloud: voice, messaging and email, designed with care

Watch an agent on a voice queue for an hour and count the Accept clicks. Each one is small, but each one is also a moment where the call is waiting on a person rather than the other way round, and a missed alert sends the agent to Not Responding and the caller back to the queue. Auto answer removes that moment. The interaction connects, a short tone plays, and the conversation starts.

Now picture the same setting on an email queue at 09:00. The agent finishes a call, and an email has already connected to them. Then a second message joins it before they have read the first. Nothing is wrong with the platform; the design simply did not ask whether this work suits being pushed rather than pulled. Auto answer is a powerful control, and the right answer differs by channel, by queue and sometimes by person.

When we first wrote about this in June 2023, Genesys had just brought auto answer to digital queues. It has grown since: it can now be set at queue or agent level, switched on for a whole queue and overridden per channel, and used for email as well as messaging. Legacy ACD web chat is no longer part of the picture: Genesys ended support for ACD Web Chat version 2 on 11 June 2025 in favour of web messaging. This guide is our current, evergreen view.

Auto answer is off by default. At queue level, enabling it on the queue's General tab applies it to all supported voice and digital channels on the queue. Each channel can then be set individually, overriding the queue-level setting for that channel. Genesys gives the example of a queue with auto answer enabled but disabled for email, SMS and WhatsApp, so it continues for web messaging and the other messaging channels. One rule catches people out: changing the queue-level setting is treated as a fresh update and clears the channel-level overrides, so they must be set again.

At agent level, an administrator opens Admin, People, selects the user and switches on Auto Answer in the user's profile. All channels are selected by default, and the administrator can narrow them, for example to voice and messages only. This needs Agent UI > Agents permissions to view, edit and delete, Directory > User permissions to view and edit, and the Telephony > Plugin > All permission. For voice, the agent's phone must support auto answer, and Genesys recommends persistent connections in the phone's baseline appearance settings for agents who use it.

The two levels combine without hierarchy: if auto answer is enabled at either level, the interaction is auto answered. The queue setting applies to every agent and group that is currently a member of the queue. For repeatable configuration we work through the Public API. Agent settings live at /api/v2/users/agentui/agents/autoanswer/{agentId}/settings as a map of media types to an enabled flag, and each queue's mediaSettings carry enableAutoAnswer per media type, with message subtype settings taking precedence over the message media setting.

Illustrative body for PUT /api/v2/users/agentui/agents/autoanswer/{agentId}/settings

{
  "settings": {
    "call":    { "enabled": true },
    "message": { "enabled": true },
    "email":   { "enabled": false }
  }
}

Without auto answer, an interaction alerts and waits for Accept. On a voice queue the alerting timeout can be set between 7 and 59 seconds; when it expires, the agent's status changes to Not Responding and the call returns to the queue. Email channels behave the same way when an alert times out. With auto answer enabled, the alerting timeout no longer applies and the option is hidden. Instead, the agent hears a short audio alert as the interaction connects, and each queue channel has a setting for how long the alert tone plays.

For voice, Genesys gives designers one more useful control: a queue can play whisper audio only to agents configured for auto answer, so an agent who did not click anything still learns which queue the caller came from before the conversation starts. If no whisper prompt is configured and auto answer is enabled, a tone plays. Genesys advises keeping whisper prompts as short as possible, because two-way audio does not begin until the whisper finishes.

Digital interactions feel different. In the embedded clients, such as Genesys Cloud for Salesforce, Microsoft Teams or Zendesk and the Embeddable Framework, Genesys documents that an auto-answered message or email connects and appears in the interaction list, with any configured screen pop, when the agent has no other interactions. If the agent is already handling interactions, the new one appears in the list as held, and the agent switches to it when ready. That is the moment a design either supports the agent or overwhelms them.

Auto answer does not decide how much work an agent receives; agent utilisation does. Genesys states that the number of auto-answered interactions depends on the utilisation settings. By default an agent can handle one voice call, one callback, one email, up to four chats, up to four messages and up to four workitems at a time, and administrators can change this at organisation or agent level and choose which interaction types may interrupt others. By default, interruptions to email are allowed. With manual answer, an agent can let an alert pass; with auto answer, every slot that utilisation allows is filled without asking.

Two queue settings help keep digital capacity honest. Dynamic utilisation reduces an interaction's weight after a configured period of inactivity, by a percentage of its original base weight, so a quiet conversation stops occupying a full slot. Inactivity handling for messaging disconnects an inactive conversation with a sign-off message, or routes it to another Architect flow, after a period between one and 30 minutes. Both matter more with auto answer, because the agent no longer filters what arrives.

Reporting follows the same logic. Genesys documents that the total interaction time of an auto-answered interaction includes the time between the auto answer and the moment the agent picks it up. Genesys has also announced a revision to digital reporting, planned for April 2026, so that hold time, also called inactive duration, is captured for auto-answered digital interactions and included in total interaction duration and agent occupancy. We brief planners and analysts before enabling auto answer on digital queues, so a change in handle time is understood as measurement, not performance.

Real-time channels are the natural fit. On voice queues, and on outbound campaign queues in particular, auto answer removes dead time; Genesys's own announcement of queue-level voice auto answer gives the example of enabling it for outbound campaign queues while keeping it disabled for inbound queues. Web messaging often benefits too, when the customer is present and expects a prompt reply. Callbacks are supported as well, and the callback type and agent readiness decide whether connecting immediately suits the team.

Asynchronous channels need more thought. SMS and WhatsApp conversations are often sporadic, and an email may need research before a reply. Auto-answering them can fill an agent's list with held work they cannot attend to at once, and it removes the small act of choosing the next task. We usually leave email on manual answer, decide SMS and WhatsApp queue by queue with the operations team, and lean on bots and flows to gather context first, so whatever reaches an agent is ready to work.

Readiness and accessibility matter just as much. Auto answer assumes that an agent who is On Queue is ready at that moment; agents who go On Queue early, or who step away without changing status, will be connected regardless. The audio alert is the agent's main signal, so we check headset routing and agree a visible alternative for any agent who cannot rely on hearing it, using the per-agent setting to keep manual answer where a person's needs call for it. A per-agent exception is a design decision, recorded and reviewed, not a workaround.

We treat auto answer as part of routing design, not a checkbox. In Discover we look at each queue's channels, volumes, concurrency and agent behaviour, and talk to the people who will live with the result: agents, team leaders and workforce planners. In Define, our Business Analyst writes the decision as requirements with acceptance criteria, queue by queue and channel by channel, including the per-agent exceptions. In Design, the Solution Architect records the choice in the Low-Level Design with the utilisation profile, dynamic utilisation rules, inactivity handling and whisper prompts that go with it, and notes in the design decision log why each channel is on or off.

Build is done through the Public API or CX as Code where the client works that way, so queue and agent settings can be reviewed, peer checked and reapplied, and so the reset of channel overrides after a queue-level change cannot catch anyone out. In Prove, our User Acceptance Test Lead runs real agents through realistic shifts: a call arriving during an email, three messages arriving together, an agent returning from a break, an agent relying on a visual cue. After go-live, release readiness reviews track Genesys changes to auto answer and reporting, so the design stays current as the platform moves.