Genesys Cloud - Main

For those interested in the complete project journey, here are more details about how we approached the architecture, rollout, governance and measurement strategy at Solve4ME.

About the operation

The project was developed for a large Brazilian retail operation with nationwide post-purchase support across digital and physical channels.

Because of the scale of the operation, even a small improvement in retention, routing or resolution can represent a significant impact on customer experience and human service capacity.

The problem we wanted to solve

Customers contacting the operation about delayed orders were frequently transferred to human agents.

However, in many of these interactions, the agent was not responsible for investigating or resolving the delivery issue.

The agent's main role was to understand the situation, collect the necessary information and create a ticket for the N2 team, which was responsible for analyzing and resolving the problem.

In other words, the human agent was acting primarily as an intermediary between the customer and the team that could actually take action.

At Solve4ME, we identified this journey as a strong use case for an Agentic Virtual Agent.

The goal was not simply to provide an informational answer or avoid a human transfer.

The AVA needed to understand the customer's context, identify the appropriate delayed-order journey and perform the correct operational action.

Why we did not create one large AVA

At first glance, all the interactions appeared to represent the same use case: a customer had a delayed order and might need a ticket to be created.

However, during the discovery and mapping process, we identified different contexts, order stages, previous customer interactions, business rules and available actions.

Even when the final action appeared similar, the context required to reach that action was different.

For this reason, we designed a suite of specialized AVAs instead of creating one generic agent responsible for the entire delayed-order journey.

Each AVA received:

• A clearly defined responsibility
• A specific conversational context
• Business instructions related to its journey
• Access only to the required tools
• Clear handoff and fallback behavior

Genesys Cloud Architect remained responsible for deterministic orchestration, eligibility rules, routing and fallback.

The AVAs became responsible for understanding the conversation, collecting the necessary information and executing the appropriate action.

This separation was one of the most important design decisions in the project.

It reduced ambiguity between similar scenarios, prevented AVAs from accessing unnecessary actions and made testing, auditing and future maintenance safer.

AVA does not eliminate the need for good solution design.

It changes where that design happens.

The quality of the solution depends on clear agent boundaries, well-defined tool contracts, orchestration, instructions, knowledge curation, testing and governance.

Starting with a controlled rollout

We intentionally did not begin with a nationwide launch.

The solution was initially made available to only a portion of customers.

During this period, our team monitored real conversations, reviewed execution histories and evaluated whether the AVAs were correctly identifying each situation and performing the expected actions.

The controlled rollout allowed us to identify edge cases and refine the experience while the exposure was still limited.

We adjusted instructions, tool descriptions, value mappings, system messages and orchestration rules based on actual production behavior.

This stage was extremely important.

Real customer conversations often reveal situations and language variations that are difficult to reproduce through isolated testing alone.

Once the main journeys were stable and the necessary corrections had been implemented, the solution was expanded across Brazil.

Results observed so far

The project has already produced significant improvements:

• 85% retention within the AVA journey
• Overall flow retention increased from 79% to 84%
• A gain of 5 percentage points in overall retention
• Transfers to human service decreased from 21% to 16%
• Before the AVA implementation, CSAT was not measured specifically for this journey. With the new solution, this measurement was introduced, and 61% of customers reported that the experience helped or helped a lot.

These results are not only about containment.

They mean that fewer customers need to wait for a human agent whose main responsibility would be to perform an operational step that the AVA can execute immediately and consistently.

They also allow human agents to focus on situations where investigation, judgment, negotiation or more complex problem-solving is actually required.

What happened to Average Handle Time?

One important point is that Average Handle Time should not be analyzed in isolation after this type of automation.

We identified the possibility of a slight increase in human AHT.

However, this does not necessarily represent a loss of efficiency.

Before the AVA implementation, the human queue contained a combination of simple operational contacts and more complex cases.

Once the AVAs began retaining many of the simpler and more repetitive interactions, the contacts that continued to reach agents naturally represented a higher concentration of complex situations.

The average interaction handled by a human therefore became more demanding.

This creates a change in the contact mix:

• Fewer repetitive contacts reach agents
• A greater proportion of human interactions requires investigation
• Agents spend more time on cases where their expertise is necessary
• Total transferred volume decreases, even if the average duration of the remaining contacts increases slightly

For this reason, AHT should be evaluated together with retention, total transferred volume, total handling hours, repeat contacts, resolution and customer satisfaction.

The goal is not necessarily to make every remaining human interaction shorter.

The goal is to use human capacity where it creates the most value.

The next measurement layer

The results measured so far demonstrate the impact at the customer service entry point.

Our next goal is to connect the AVA journey with what happens after the operational action is completed.

We plan to evaluate indicators such as:

• Time until N2 resolution
• Repeat contact rate
• Correct categorization and routing
• Orders successfully recovered
• Final customer and order outcomes
• Total cost to serve

One of our hypotheses is that faster, more consistent and correctly categorized ticket creation may help the responsible team act earlier and potentially prevent some delayed orders from reaching undesirable outcomes.

This still needs to be measured, so we are not treating it as a confirmed result.

However, it represents an important potential business impact beyond containment.

As Brazilian market context, reporting that cites Ebit | Nielsen estimates that reverse logistics represents approximately 7% of the costs involved in e-commerce operations. This is a general market reference and does not represent a measured result from this project.

The benchmark helps explain why the next phase should examine the complete order outcome, rather than measuring only whether the initial interaction was retained.

A canceled or returned order can create impacts related to transportation, product inspection, inventory availability, reprocessing, refunds, additional contacts and the potential loss of the original sale.

The future measurement strategy will therefore focus not only on whether the AVA contained the interaction, but also on whether the journey contributed to a better final outcome for the customer and the operation.

Governance was part of the solution

As the number of specialized AVAs increased, governance became an essential part of the project.

At Solve4ME, we implemented systematic configuration reviews, validated the tool inventory available to each AVA, checked API value mappings, curated the knowledge content and documented the relationship between the AVAs and the Architect orchestration.

Some of the most important lessons came from small configuration details:

• Deterministic business logic should remain in Architect or functions, rather than depending only on natural-language instructions
• Guidelines and guardrails have different purposes
• System messages must be consistent with the customer's language
• API values must match exactly what the tools and instructions expect
• An AVA should have access only to the actions required for its responsibility

When multiple specialized agents coexist, a small inconsistency can change the outcome of an entire conversation.

Architecture, testing, auditing and documentation were therefore just as important as the conversational experience itself.

What comes next

We are evaluating how the same specialized AVA strategy can support other post-purchase journeys.

These journeys may introduce new eligibility rules, customer contexts and operational actions, making clearly defined AVA responsibilities even more important.

This project reinforced an important lesson for us:

The value of Agentic AI does not come only from creating a more natural conversation.

It comes from giving the AI a clearly defined responsibility, the right context, the right tools and a safe architecture in which it can act.

And sometimes, the best Agentic AI use case begins by asking a simple question:

Why are we transferring this customer to a human agent, and what does that agent actually do next?

How are you measuring AVA performance beyond retention and containment?

Are you already connecting virtual agent outcomes with downstream business indicators such as repeat contacts, resolution and final customer outcomes?

Mateus Nunes Thank you for taking the time to share such a comprehensive breakdown of the project. I really enjoyed reading it. I particularly liked the emphasis on specialised AVAs with clear responsibilities, while keeping deterministic orchestration in Architect. The focus on measuring business outcomes beyond containment was another great takeaway. There are some valuable design and governance lessons here that will be useful for anyone planning an AVA implementation. Thanks again for sharing your experience.

For those interested in the complete project journey, here are more details about how we approached the architecture, rollout, governance and measurement strategy at Solve4ME.

About the operation

The project was developed for a large Brazilian retail operation with nationwide post-purchase support across digital and physical channels.

Because of the scale of the operation, even a small improvement in retention, routing or resolution can represent a significant impact on customer experience and human service capacity.

The problem we wanted to solve

Customers contacting the operation about delayed orders were frequently transferred to human agents.

However, in many of these interactions, the agent was not responsible for investigating or resolving the delivery issue.

The agent's main role was to understand the situation, collect the necessary information and create a ticket for the N2 team, which was responsible for analyzing and resolving the problem.

In other words, the human agent was acting primarily as an intermediary between the customer and the team that could actually take action.

At Solve4ME, we identified this journey as a strong use case for an Agentic Virtual Agent.

The goal was not simply to provide an informational answer or avoid a human transfer.

The AVA needed to understand the customer's context, identify the appropriate delayed-order journey and perform the correct operational action.

Why we did not create one large AVA

At first glance, all the interactions appeared to represent the same use case: a customer had a delayed order and might need a ticket to be created.

However, during the discovery and mapping process, we identified different contexts, order stages, previous customer interactions, business rules and available actions.

Even when the final action appeared similar, the context required to reach that action was different.

For this reason, we designed a suite of specialized AVAs instead of creating one generic agent responsible for the entire delayed-order journey.

Each AVA received:

• A clearly defined responsibility
• A specific conversational context
• Business instructions related to its journey
• Access only to the required tools
• Clear handoff and fallback behavior

Genesys Cloud Architect remained responsible for deterministic orchestration, eligibility rules, routing and fallback.

The AVAs became responsible for understanding the conversation, collecting the necessary information and executing the appropriate action.

This separation was one of the most important design decisions in the project.

It reduced ambiguity between similar scenarios, prevented AVAs from accessing unnecessary actions and made testing, auditing and future maintenance safer.

AVA does not eliminate the need for good solution design.

It changes where that design happens.

The quality of the solution depends on clear agent boundaries, well-defined tool contracts, orchestration, instructions, knowledge curation, testing and governance.

Starting with a controlled rollout

We intentionally did not begin with a nationwide launch.

The solution was initially made available to only a portion of customers.

During this period, our team monitored real conversations, reviewed execution histories and evaluated whether the AVAs were correctly identifying each situation and performing the expected actions.

The controlled rollout allowed us to identify edge cases and refine the experience while the exposure was still limited.

We adjusted instructions, tool descriptions, value mappings, system messages and orchestration rules based on actual production behavior.

This stage was extremely important.

Real customer conversations often reveal situations and language variations that are difficult to reproduce through isolated testing alone.

Once the main journeys were stable and the necessary corrections had been implemented, the solution was expanded across Brazil.

Results observed so far

The project has already produced significant improvements:

• 85% retention within the AVA journey
• Overall flow retention increased from 79% to 84%
• A gain of 5 percentage points in overall retention
• Transfers to human service decreased from 21% to 16%
• Before the AVA implementation, CSAT was not measured specifically for this journey. With the new solution, this measurement was introduced, and 61% of customers reported that the experience helped or helped a lot.

These results are not only about containment.

They mean that fewer customers need to wait for a human agent whose main responsibility would be to perform an operational step that the AVA can execute immediately and consistently.

They also allow human agents to focus on situations where investigation, judgment, negotiation or more complex problem-solving is actually required.

What happened to Average Handle Time?

One important point is that Average Handle Time should not be analyzed in isolation after this type of automation.

We identified the possibility of a slight increase in human AHT.

However, this does not necessarily represent a loss of efficiency.

Before the AVA implementation, the human queue contained a combination of simple operational contacts and more complex cases.

Once the AVAs began retaining many of the simpler and more repetitive interactions, the contacts that continued to reach agents naturally represented a higher concentration of complex situations.

The average interaction handled by a human therefore became more demanding.

This creates a change in the contact mix:

• Fewer repetitive contacts reach agents
• A greater proportion of human interactions requires investigation
• Agents spend more time on cases where their expertise is necessary
• Total transferred volume decreases, even if the average duration of the remaining contacts increases slightly

For this reason, AHT should be evaluated together with retention, total transferred volume, total handling hours, repeat contacts, resolution and customer satisfaction.

The goal is not necessarily to make every remaining human interaction shorter.

The goal is to use human capacity where it creates the most value.

The next measurement layer

The results measured so far demonstrate the impact at the customer service entry point.

Our next goal is to connect the AVA journey with what happens after the operational action is completed.

We plan to evaluate indicators such as:

• Time until N2 resolution
• Repeat contact rate
• Correct categorization and routing
• Orders successfully recovered
• Final customer and order outcomes
• Total cost to serve

One of our hypotheses is that faster, more consistent and correctly categorized ticket creation may help the responsible team act earlier and potentially prevent some delayed orders from reaching undesirable outcomes.

This still needs to be measured, so we are not treating it as a confirmed result.

However, it represents an important potential business impact beyond containment.

As Brazilian market context, reporting that cites Ebit | Nielsen estimates that reverse logistics represents approximately 7% of the costs involved in e-commerce operations. This is a general market reference and does not represent a measured result from this project.

The benchmark helps explain why the next phase should examine the complete order outcome, rather than measuring only whether the initial interaction was retained.

A canceled or returned order can create impacts related to transportation, product inspection, inventory availability, reprocessing, refunds, additional contacts and the potential loss of the original sale.

The future measurement strategy will therefore focus not only on whether the AVA contained the interaction, but also on whether the journey contributed to a better final outcome for the customer and the operation.

Governance was part of the solution

As the number of specialized AVAs increased, governance became an essential part of the project.

At Solve4ME, we implemented systematic configuration reviews, validated the tool inventory available to each AVA, checked API value mappings, curated the knowledge content and documented the relationship between the AVAs and the Architect orchestration.

Some of the most important lessons came from small configuration details:

• Deterministic business logic should remain in Architect or functions, rather than depending only on natural-language instructions
• Guidelines and guardrails have different purposes
• System messages must be consistent with the customer's language
• API values must match exactly what the tools and instructions expect
• An AVA should have access only to the actions required for its responsibility

When multiple specialized agents coexist, a small inconsistency can change the outcome of an entire conversation.

Architecture, testing, auditing and documentation were therefore just as important as the conversational experience itself.

What comes next

We are evaluating how the same specialized AVA strategy can support other post-purchase journeys.

These journeys may introduce new eligibility rules, customer contexts and operational actions, making clearly defined AVA responsibilities even more important.

This project reinforced an important lesson for us:

The value of Agentic AI does not come only from creating a more natural conversation.

It comes from giving the AI a clearly defined responsibility, the right context, the right tools and a safe architecture in which it can act.

And sometimes, the best Agentic AI use case begins by asking a simple question:

Why are we transferring this customer to a human agent, and what does that agent actually do next?

How are you measuring AVA performance beyond retention and containment?

Are you already connecting virtual agent outcomes with downstream business indicators such as repeat contacts, resolution and final customer outcomes?

Thank you so much, @Phaneendra Avatapalli! I'm really glad those points stood out to you.

Keeping each AVA focused on a clear responsibility, while using Architect for deterministic orchestration, was one of the most important design decisions in this project. It helped us improve control, scalability, and governance without losing the flexibility of the conversational experience.

And I completely agree about measuring beyond containment. Retention is important, but understanding customer experience, operational impact, and what happens after the interaction gives us a much better view of the real value delivered.

Thanks again for taking the time to read and share your thoughts!

Mateus Nunes Thank you for taking the time to share such a comprehensive breakdown of the project. I really enjoyed reading it. I particularly liked the emphasis on specialised AVAs with clear responsibilities, while keeping deterministic orchestration in Architect. The focus on measuring business outcomes beyond containment was another great takeaway. There are some valuable design and governance lessons here that will be useful for anyone planning an AVA implementation. Thanks again for sharing your experience.

For those interested in the complete project journey, here are more details about how we approached the architecture, rollout, governance and measurement strategy at Solve4ME.

About the operation

The project was developed for a large Brazilian retail operation with nationwide post-purchase support across digital and physical channels.

Because of the scale of the operation, even a small improvement in retention, routing or resolution can represent a significant impact on customer experience and human service capacity.

The problem we wanted to solve

Customers contacting the operation about delayed orders were frequently transferred to human agents.

However, in many of these interactions, the agent was not responsible for investigating or resolving the delivery issue.

The agent's main role was to understand the situation, collect the necessary information and create a ticket for the N2 team, which was responsible for analyzing and resolving the problem.

In other words, the human agent was acting primarily as an intermediary between the customer and the team that could actually take action.

At Solve4ME, we identified this journey as a strong use case for an Agentic Virtual Agent.

The goal was not simply to provide an informational answer or avoid a human transfer.

The AVA needed to understand the customer's context, identify the appropriate delayed-order journey and perform the correct operational action.

Why we did not create one large AVA

At first glance, all the interactions appeared to represent the same use case: a customer had a delayed order and might need a ticket to be created.

However, during the discovery and mapping process, we identified different contexts, order stages, previous customer interactions, business rules and available actions.

Even when the final action appeared similar, the context required to reach that action was different.

For this reason, we designed a suite of specialized AVAs instead of creating one generic agent responsible for the entire delayed-order journey.

Each AVA received:

• A clearly defined responsibility
• A specific conversational context
• Business instructions related to its journey
• Access only to the required tools
• Clear handoff and fallback behavior

Genesys Cloud Architect remained responsible for deterministic orchestration, eligibility rules, routing and fallback.

The AVAs became responsible for understanding the conversation, collecting the necessary information and executing the appropriate action.

This separation was one of the most important design decisions in the project.

It reduced ambiguity between similar scenarios, prevented AVAs from accessing unnecessary actions and made testing, auditing and future maintenance safer.

AVA does not eliminate the need for good solution design.

It changes where that design happens.

The quality of the solution depends on clear agent boundaries, well-defined tool contracts, orchestration, instructions, knowledge curation, testing and governance.

Starting with a controlled rollout

We intentionally did not begin with a nationwide launch.

The solution was initially made available to only a portion of customers.

During this period, our team monitored real conversations, reviewed execution histories and evaluated whether the AVAs were correctly identifying each situation and performing the expected actions.

The controlled rollout allowed us to identify edge cases and refine the experience while the exposure was still limited.

We adjusted instructions, tool descriptions, value mappings, system messages and orchestration rules based on actual production behavior.

This stage was extremely important.

Real customer conversations often reveal situations and language variations that are difficult to reproduce through isolated testing alone.

Once the main journeys were stable and the necessary corrections had been implemented, the solution was expanded across Brazil.

Results observed so far

The project has already produced significant improvements:

• 85% retention within the AVA journey
• Overall flow retention increased from 79% to 84%
• A gain of 5 percentage points in overall retention
• Transfers to human service decreased from 21% to 16%
• Before the AVA implementation, CSAT was not measured specifically for this journey. With the new solution, this measurement was introduced, and 61% of customers reported that the experience helped or helped a lot.

These results are not only about containment.

They mean that fewer customers need to wait for a human agent whose main responsibility would be to perform an operational step that the AVA can execute immediately and consistently.

They also allow human agents to focus on situations where investigation, judgment, negotiation or more complex problem-solving is actually required.

What happened to Average Handle Time?

One important point is that Average Handle Time should not be analyzed in isolation after this type of automation.

We identified the possibility of a slight increase in human AHT.

However, this does not necessarily represent a loss of efficiency.

Before the AVA implementation, the human queue contained a combination of simple operational contacts and more complex cases.

Once the AVAs began retaining many of the simpler and more repetitive interactions, the contacts that continued to reach agents naturally represented a higher concentration of complex situations.

The average interaction handled by a human therefore became more demanding.

This creates a change in the contact mix:

• Fewer repetitive contacts reach agents
• A greater proportion of human interactions requires investigation
• Agents spend more time on cases where their expertise is necessary
• Total transferred volume decreases, even if the average duration of the remaining contacts increases slightly

For this reason, AHT should be evaluated together with retention, total transferred volume, total handling hours, repeat contacts, resolution and customer satisfaction.

The goal is not necessarily to make every remaining human interaction shorter.

The goal is to use human capacity where it creates the most value.

The next measurement layer

The results measured so far demonstrate the impact at the customer service entry point.

Our next goal is to connect the AVA journey with what happens after the operational action is completed.

We plan to evaluate indicators such as:

• Time until N2 resolution
• Repeat contact rate
• Correct categorization and routing
• Orders successfully recovered
• Final customer and order outcomes
• Total cost to serve

One of our hypotheses is that faster, more consistent and correctly categorized ticket creation may help the responsible team act earlier and potentially prevent some delayed orders from reaching undesirable outcomes.

This still needs to be measured, so we are not treating it as a confirmed result.

However, it represents an important potential business impact beyond containment.

As Brazilian market context, reporting that cites Ebit | Nielsen estimates that reverse logistics represents approximately 7% of the costs involved in e-commerce operations. This is a general market reference and does not represent a measured result from this project.

The benchmark helps explain why the next phase should examine the complete order outcome, rather than measuring only whether the initial interaction was retained.

A canceled or returned order can create impacts related to transportation, product inspection, inventory availability, reprocessing, refunds, additional contacts and the potential loss of the original sale.

The future measurement strategy will therefore focus not only on whether the AVA contained the interaction, but also on whether the journey contributed to a better final outcome for the customer and the operation.

Governance was part of the solution

As the number of specialized AVAs increased, governance became an essential part of the project.

At Solve4ME, we implemented systematic configuration reviews, validated the tool inventory available to each AVA, checked API value mappings, curated the knowledge content and documented the relationship between the AVAs and the Architect orchestration.

Some of the most important lessons came from small configuration details:

• Deterministic business logic should remain in Architect or functions, rather than depending only on natural-language instructions
• Guidelines and guardrails have different purposes
• System messages must be consistent with the customer's language
• API values must match exactly what the tools and instructions expect
• An AVA should have access only to the actions required for its responsibility

When multiple specialized agents coexist, a small inconsistency can change the outcome of an entire conversation.

Architecture, testing, auditing and documentation were therefore just as important as the conversational experience itself.

What comes next

We are evaluating how the same specialized AVA strategy can support other post-purchase journeys.

These journeys may introduce new eligibility rules, customer contexts and operational actions, making clearly defined AVA responsibilities even more important.

This project reinforced an important lesson for us:

The value of Agentic AI does not come only from creating a more natural conversation.

It comes from giving the AI a clearly defined responsibility, the right context, the right tools and a safe architecture in which it can act.

And sometimes, the best Agentic AI use case begins by asking a simple question:

Why are we transferring this customer to a human agent, and what does that agent actually do next?

How are you measuring AVA performance beyond retention and containment?

Are you already connecting virtual agent outcomes with downstream business indicators such as repeat contacts, resolution and final customer outcomes?

That is excellent feedback Mateus and thank you for sharing!

Question for those that are leveraging AVA for the voice channel. Is there a graceful or recommended method for asking the AVA to wait for customer input?

Example if your AVA provides an instruction set that includes asking the caller to download a mobile app and this download / install process could take say 2 to 4 minutes, can you instruct AVA to provide the instruction and wait patiently? A digital bot seems to handle this more gracefully, but hoping there are maybe some guidelines or configuration tweaks to improve and allow the AVA to wait when voice channel is in use.

Thanks!

Thank you so much, @Phaneendra Avatapalli! I'm really glad those points stood out to you.

Keeping each AVA focused on a clear responsibility, while using Architect for deterministic orchestration, was one of the most important design decisions in this project. It helped us improve control, scalability, and governance without losing the flexibility of the conversational experience.

And I completely agree about measuring beyond containment. Retention is important, but understanding customer experience, operational impact, and what happens after the interaction gives us a much better view of the real value delivered.

Thanks again for taking the time to read and share your thoughts!

Mateus Nunes Thank you for taking the time to share such a comprehensive breakdown of the project. I really enjoyed reading it. I particularly liked the emphasis on specialised AVAs with clear responsibilities, while keeping deterministic orchestration in Architect. The focus on measuring business outcomes beyond containment was another great takeaway. There are some valuable design and governance lessons here that will be useful for anyone planning an AVA implementation. Thanks again for sharing your experience.

For those interested in the complete project journey, here are more details about how we approached the architecture, rollout, governance and measurement strategy at Solve4ME.

About the operation

The project was developed for a large Brazilian retail operation with nationwide post-purchase support across digital and physical channels.

Because of the scale of the operation, even a small improvement in retention, routing or resolution can represent a significant impact on customer experience and human service capacity.

The problem we wanted to solve

Customers contacting the operation about delayed orders were frequently transferred to human agents.

However, in many of these interactions, the agent was not responsible for investigating or resolving the delivery issue.

The agent's main role was to understand the situation, collect the necessary information and create a ticket for the N2 team, which was responsible for analyzing and resolving the problem.

In other words, the human agent was acting primarily as an intermediary between the customer and the team that could actually take action.

At Solve4ME, we identified this journey as a strong use case for an Agentic Virtual Agent.

The goal was not simply to provide an informational answer or avoid a human transfer.

The AVA needed to understand the customer's context, identify the appropriate delayed-order journey and perform the correct operational action.

Why we did not create one large AVA

At first glance, all the interactions appeared to represent the same use case: a customer had a delayed order and might need a ticket to be created.

However, during the discovery and mapping process, we identified different contexts, order stages, previous customer interactions, business rules and available actions.

Even when the final action appeared similar, the context required to reach that action was different.

For this reason, we designed a suite of specialized AVAs instead of creating one generic agent responsible for the entire delayed-order journey.

Each AVA received:

• A clearly defined responsibility
• A specific conversational context
• Business instructions related to its journey
• Access only to the required tools
• Clear handoff and fallback behavior

Genesys Cloud Architect remained responsible for deterministic orchestration, eligibility rules, routing and fallback.

The AVAs became responsible for understanding the conversation, collecting the necessary information and executing the appropriate action.

This separation was one of the most important design decisions in the project.

It reduced ambiguity between similar scenarios, prevented AVAs from accessing unnecessary actions and made testing, auditing and future maintenance safer.

AVA does not eliminate the need for good solution design.

It changes where that design happens.

The quality of the solution depends on clear agent boundaries, well-defined tool contracts, orchestration, instructions, knowledge curation, testing and governance.

Starting with a controlled rollout

We intentionally did not begin with a nationwide launch.

The solution was initially made available to only a portion of customers.

During this period, our team monitored real conversations, reviewed execution histories and evaluated whether the AVAs were correctly identifying each situation and performing the expected actions.

The controlled rollout allowed us to identify edge cases and refine the experience while the exposure was still limited.

We adjusted instructions, tool descriptions, value mappings, system messages and orchestration rules based on actual production behavior.

This stage was extremely important.

Real customer conversations often reveal situations and language variations that are difficult to reproduce through isolated testing alone.

Once the main journeys were stable and the necessary corrections had been implemented, the solution was expanded across Brazil.

Results observed so far

The project has already produced significant improvements:

• 85% retention within the AVA journey
• Overall flow retention increased from 79% to 84%
• A gain of 5 percentage points in overall retention
• Transfers to human service decreased from 21% to 16%
• Before the AVA implementation, CSAT was not measured specifically for this journey. With the new solution, this measurement was introduced, and 61% of customers reported that the experience helped or helped a lot.

These results are not only about containment.

They mean that fewer customers need to wait for a human agent whose main responsibility would be to perform an operational step that the AVA can execute immediately and consistently.

They also allow human agents to focus on situations where investigation, judgment, negotiation or more complex problem-solving is actually required.

What happened to Average Handle Time?

One important point is that Average Handle Time should not be analyzed in isolation after this type of automation.

We identified the possibility of a slight increase in human AHT.

However, this does not necessarily represent a loss of efficiency.

Before the AVA implementation, the human queue contained a combination of simple operational contacts and more complex cases.

Once the AVAs began retaining many of the simpler and more repetitive interactions, the contacts that continued to reach agents naturally represented a higher concentration of complex situations.

The average interaction handled by a human therefore became more demanding.

This creates a change in the contact mix:

• Fewer repetitive contacts reach agents
• A greater proportion of human interactions requires investigation
• Agents spend more time on cases where their expertise is necessary
• Total transferred volume decreases, even if the average duration of the remaining contacts increases slightly

For this reason, AHT should be evaluated together with retention, total transferred volume, total handling hours, repeat contacts, resolution and customer satisfaction.

The goal is not necessarily to make every remaining human interaction shorter.

The goal is to use human capacity where it creates the most value.

The next measurement layer

The results measured so far demonstrate the impact at the customer service entry point.

Our next goal is to connect the AVA journey with what happens after the operational action is completed.

We plan to evaluate indicators such as:

• Time until N2 resolution
• Repeat contact rate
• Correct categorization and routing
• Orders successfully recovered
• Final customer and order outcomes
• Total cost to serve

One of our hypotheses is that faster, more consistent and correctly categorized ticket creation may help the responsible team act earlier and potentially prevent some delayed orders from reaching undesirable outcomes.

This still needs to be measured, so we are not treating it as a confirmed result.

However, it represents an important potential business impact beyond containment.

As Brazilian market context, reporting that cites Ebit | Nielsen estimates that reverse logistics represents approximately 7% of the costs involved in e-commerce operations. This is a general market reference and does not represent a measured result from this project.

The benchmark helps explain why the next phase should examine the complete order outcome, rather than measuring only whether the initial interaction was retained.

A canceled or returned order can create impacts related to transportation, product inspection, inventory availability, reprocessing, refunds, additional contacts and the potential loss of the original sale.

The future measurement strategy will therefore focus not only on whether the AVA contained the interaction, but also on whether the journey contributed to a better final outcome for the customer and the operation.

Governance was part of the solution

As the number of specialized AVAs increased, governance became an essential part of the project.

At Solve4ME, we implemented systematic configuration reviews, validated the tool inventory available to each AVA, checked API value mappings, curated the knowledge content and documented the relationship between the AVAs and the Architect orchestration.

Some of the most important lessons came from small configuration details:

• Deterministic business logic should remain in Architect or functions, rather than depending only on natural-language instructions
• Guidelines and guardrails have different purposes
• System messages must be consistent with the customer's language
• API values must match exactly what the tools and instructions expect
• An AVA should have access only to the actions required for its responsibility

When multiple specialized agents coexist, a small inconsistency can change the outcome of an entire conversation.

Architecture, testing, auditing and documentation were therefore just as important as the conversational experience itself.

What comes next

We are evaluating how the same specialized AVA strategy can support other post-purchase journeys.

These journeys may introduce new eligibility rules, customer contexts and operational actions, making clearly defined AVA responsibilities even more important.

This project reinforced an important lesson for us:

The value of Agentic AI does not come only from creating a more natural conversation.

It comes from giving the AI a clearly defined responsibility, the right context, the right tools and a safe architecture in which it can act.

And sometimes, the best Agentic AI use case begins by asking a simple question:

Why are we transferring this customer to a human agent, and what does that agent actually do next?

How are you measuring AVA performance beyond retention and containment?

Are you already connecting virtual agent outcomes with downstream business indicators such as repeat contacts, resolution and final customer outcomes?

Congrats for these successful results and thanks for sharing! There is a lot of good info here! Nice approach to specialized AVA...

Mateus,

Great case and a very interesting approach.

We're moving beyond "How many interactions did the AVA retain?" and starting to ask "What business outcome did it help achieve?"

As these solutions mature, automation metrics become only part of the story. The real value comes from improving the end-to-end journey, reducing operational effort, increasing resolution quality and ensuring that human expertise is applied where it creates the greatest impact.

To me, that's what separates deploying AI from truly transforming an operation.