Genesys Cloud - Main

Hi Arthur,

I've seen exactly the same pattern in multiple Genesys Cloud Agent Copilot projects.

Many teams initially try to build:

• one article per scenario
• extremely detailed procedures
• highly specific edge-case documentation

And usually the result is:

• duplicated content
• overlapping intents
• noisy recommendations
• lower Copilot precision

In practice, the best results I've seen come from a different approach:

What tends to work better

1. Smaller and focused articles

Instead of:

• "Complete process for billing issue type A/B/C/D"

Prefer:

• "How to validate customer identity"
• "How to resend invoice"
• "Payment negotiation rules"
• "Escalation criteria"

Shorter articles improve:

• retrieval quality
• intent matching
• recommendation confidence

2. Modular knowledge

A modular KB performs much better than giant end-to-end guides.

Copilot is usually better at:

• combining smaller contextual pieces
  than navigating a huge procedural document.

3. Reduce article overlap

One of the biggest issues is having:

• 10 articles
• with 80% similar content

This confuses retrieval and weakens relevance scoring.

4. Optimize for retrieval, not human reading

This is a mindset shift many projects miss.

Traditional KBs are often written like training manuals.
Copilot KBs should be optimized for:

• semantic retrieval
• quick grounding
• contextual recommendations

Not necessarily for full human reading flow.

What has worked best for me

The best performing environments usually have:

• concise articles
• standardized structure
• reusable procedures
• clear titles
• minimal duplication
• separated business rules vs process flow

Large "master documents" tend to perform worse unless they are heavily segmented.

One important point

A very common mistake is trying to map every possible scenario before go-live.

Usually:

• starting with top intents/use cases
• then iterating based on real conversations

produces much better adoption and accuracy.

Your conclusion aligns very closely with what I've seen in production environments as well.

in my experience, trying to map every possible scenario usually backfires. It creates a very heavy knowledge base, with duplicated or very similar content, which makes it harder for Copilot to retrieve the right answer.

What has worked better for me is:

Focusing on broader, well-structured topics instead of edge-case scenarios
Keeping articles shorter and more objective
Using clear headings and consistent structure so Copilot can extract the right pieces of information

I also see better results when the content is written more as guidance (what the agent should do and why), instead of long step-by-step procedures for every variation.

Another key point is avoiding duplication - if multiple articles say almost the same thing, Copilot tends to lose precision.

So overall, I'd definitely lean toward shorter, cleaner, and more generic articles, supported by good organization, rather than highly detailed scenario-based documentation.

It makes sense to move away from huge monolithic blocks of information inside an article to a more "object based" mindset (if that makes sense) if you really think about how LLMs work.

Considering copilot will look for semantically similar "dead" chunks of text, it will most likely match a ton of or articles that are not necessarily relevant for the query.

I'd say break the responsability of each article intead of builing an all-in-one guide and it will very likely produce better results, as you've observed.

Great point, @Arthur Pereira Reinoldes.

I had a very similar experience in Agent Copilot projects as well.

In my view, one of the biggest mistakes is trying to map every possible scenario and create long, highly detailed articles for each one. At first, this seems like a good way to cover the operation, but in practice it often creates huge articles, overlapping content, similar topics competing with each other, and lower precision in Copilot suggestions.

Phase 1 - Building a scalable Agent Copilot strategy

In one of our projects, in a fintech operation, we started by prioritizing the highest-volume contact reasons and building the Knowledge Base around what agents really needed during live interactions.

We also reviewed disposition codes, removed obsolete and redundant options, used predefined responses for key parts of the service script, and integrated Copilot summaries with the CRM through triggers and workflows.

With this combined strategy, the operation reduced AHT from around 15 minutes to around 9 minutes and later expanded Copilot to 100% of chat, messaging, and voice agents.

I shared more details about this first phase here:
https://community.genesys.com/discussion/building-a-scalable-agent-copilot-strategy-lessons-from-a-fintech-operation#bm29beaf14-3256-4d2e-a718-d34f00a8f837

Phase 2 - Knowledge design for generated responses

For phase 2, we started focusing more specifically on Content Search + Copilot generated responses.

One of the most important learnings was exactly what you mentioned: breaking large articles into smaller, intent-focused articles, always thinking about what the customer is actually asking.

This improved precision significantly because Copilot could combine multiple targeted articles instead of relying on one large generic article. In our tests, even when using only clear titles and well-structured content, without adding phrases yet, the accuracy already improved a lot.

My current view is that step-by-step articles are useful when the agent needs to follow an internal procedure, but for Copilot-generated responses, shorter and more focused articles usually work better. They help Copilot understand the intent more clearly and generate answers that are easier for agents to use, especially in chat.

I shared more details about this second phase here:
https://community.genesys.com/discussion/evolving-a-scalable-agent-copilot-strategy-knowledge-design-for-generated-responses#bm944e7b8c-37a2-4812-b0ea-870ecacf2a3c

Phase 3 - Knowledge Fabric and external knowledge sources

More recently, for newer customers, we have also been adopting Knowledge Fabric, integrating external knowledge sources such as Salesforce, ServiceNow, or SharePoint.

The Fabric intelligence has shown very promising results in building AI-generated answers and surfacing relevant articles. However, these integrations also bring some limitations, such as supported article formats, content size, and the fact that images are not interpreted in the same way as text-based knowledge content.

So, even when using Knowledge Fabric, content structure and formatting remain a huge differentiator.

For me, the best approach is not only "short vs. long articles," but designing the Knowledge Base with Copilot behavior in mind:

Clear intent per article
Smaller and more focused content
Strong titles
Less overlap between similar articles
Procedural content only when needed
Customer-facing language when the goal is generated responses
Good formatting even when using external knowledge sources
Continuous testing with real operation scenarios

We are still testing article granularity, phrase strategy, external knowledge integrations, reporting impact, and authoring guidelines, but so far the results strongly support a more focused and modular knowledge design.

Curious to hear how others are balancing procedural articles, AI-ready content, and external knowledge sources for Copilot generated responses.

Great point, @Arthur Pereira Reinoldes.

I had a very similar experience in Agent Copilot projects as well.

In my view, one of the biggest mistakes is trying to map every possible scenario and create long, highly detailed articles for each one. At first, this seems like a good way to cover the operation, but in practice it often creates huge articles, overlapping content, similar topics competing with each other, and lower precision in Copilot suggestions.

Phase 1 - Building a scalable Agent Copilot strategy

In one of our projects, in a fintech operation, we started by prioritizing the highest-volume contact reasons and building the Knowledge Base around what agents really needed during live interactions.

We also reviewed disposition codes, removed obsolete and redundant options, used predefined responses for key parts of the service script, and integrated Copilot summaries with the CRM through triggers and workflows.

With this combined strategy, the operation reduced AHT from around 15 minutes to around 9 minutes and later expanded Copilot to 100% of chat, messaging, and voice agents.

I shared more details about this first phase here:
https://community.genesys.com/discussion/building-a-scalable-agent-copilot-strategy-lessons-from-a-fintech-operation#bm29beaf14-3256-4d2e-a718-d34f00a8f837

Phase 2 - Knowledge design for generated responses

For phase 2, we started focusing more specifically on Content Search + Copilot generated responses.

One of the most important learnings was exactly what you mentioned: breaking large articles into smaller, intent-focused articles, always thinking about what the customer is actually asking.

This improved precision significantly because Copilot could combine multiple targeted articles instead of relying on one large generic article. In our tests, even when using only clear titles and well-structured content, without adding phrases yet, the accuracy already improved a lot.

My current view is that step-by-step articles are useful when the agent needs to follow an internal procedure, but for Copilot-generated responses, shorter and more focused articles usually work better. They help Copilot understand the intent more clearly and generate answers that are easier for agents to use, especially in chat.

I shared more details about this second phase here:
https://community.genesys.com/discussion/evolving-a-scalable-agent-copilot-strategy-knowledge-design-for-generated-responses#bm944e7b8c-37a2-4812-b0ea-870ecacf2a3c

Phase 3 - Knowledge Fabric and external knowledge sources

More recently, for newer customers, we have also been adopting Knowledge Fabric, integrating external knowledge sources such as Salesforce, ServiceNow, or SharePoint.

The Fabric intelligence has shown very promising results in building AI-generated answers and surfacing relevant articles. However, these integrations also bring some limitations, such as supported article formats, content size, and the fact that images are not interpreted in the same way as text-based knowledge content.

So, even when using Knowledge Fabric, content structure and formatting remain a huge differentiator.

For me, the best approach is not only "short vs. long articles," but designing the Knowledge Base with Copilot behavior in mind:

Clear intent per article
Smaller and more focused content
Strong titles
Less overlap between similar articles
Procedural content only when needed
Customer-facing language when the goal is generated responses
Good formatting even when using external knowledge sources
Continuous testing with real operation scenarios

We are still testing article granularity, phrase strategy, external knowledge integrations, reporting impact, and authoring guidelines, but so far the results strongly support a more focused and modular knowledge design.

Curious to hear how others are balancing procedural articles, AI-ready content, and external knowledge sources for Copilot generated responses.