Hi all! Long text coming up 🙂 Got quite a few questions regarding Now Assist best practices for knowledge articles, and would love some thoughts.
We've been looking at KB2823162 (Knowledge Article Authoring Best Practices for Now Assist in Virtual Agent), which proposes this as the recommended KB article structure:
- Short summary / purpose (1–2 sentences)
- Symptoms / When to use this article
- Resolution / Answer (MOST IMPORTANT)
- Steps (if procedural)
- Additional Information / Notes (optional)
- Related Articles (optional)
Some context from where i work: we currently structure our knowledge articles with four fields: Title, Description (combining issue/symptom and environment), Resolution, and Internal Resolution.
Question 1 — Fields or content within fields?
When the article refers to "layout", does it mean separate fields, or sections within a single body field? I wouldn't want all of this crammed into one article body, but I probably wouldn't want all of it as separate fields either. How are others interpreting this?
Question 2 — General recommendation or Virtual Agent specific?
Is this a general recommendation for knowledge articles, or specifically for Virtual Agent? I ask because we use — and may introduce more — AI tools that draw from the knowledge base, so ideally we'd optimize for any AI, not just one. Furthermore, we don't want to maintain one template optimized for Virtual Agent and another for agents creating knowledge.
Question 3 — Single template or multiple?
Is the recommended structure designed with a single article template in mind? We currently have one, but might introduce a Q&A and HowTo template later. Should additional templates follow a similar structure? I could imagine that a Q&A article is self-explanatory enough, but maybe the recommendation is that even those should have some kind of short summary/purpose up top.
Question 4 — Clarity of the recommended structure
Would authors find the recommended structure intuitive? A couple of things feel unclear to us:
- Short summary vs. Symptoms / When to use this article — these feel like they overlap. How would you explain the difference to authors?
- Resolution vs. Steps — when does the resolution end and the steps begin? Is that distinction clear enough to work in practice?
Question 5 — Issue field as summary vs. symptom bullets
Looking at KB2823162 itself, their "Issue" section reads more like a short summary or purpose statement than a list of symptoms — which is how many of us, especially those following KCS, tend to write that field. Is that intentional? Is the idea that this field should be a natural language description rather than a bullet list of symptoms?
We use our Description field to capture symptoms and environment as bullet points — partly to make articles scannable for agents, and partly to help end users recognize the article as relevant when they're browsing search results rather than getting an AI-generated response. A label like "When to use this article" doesn't quite fit that use case. Curious how others are balancing this, especially if you're running both AI-assisted search and traditional agent/self-service search.
Question 6 — Symptoms that aren't facts
Related to the above: we list symptoms as the end user experiences them — not as accurate statements of what's actually wrong. Example:
- Symptom in Description: "Files in SharePoint can't be downloaded locally"
- Actual resolution: "You can download locally, but only if you do XYZ"
The symptom is there to help users recognize the article as relevant, not to state a fact. Our concern is that Now Assist picks this up and surfaces it as a direct answer — telling the user they can't download files, when actually they can.
- Is this a real risk, or does Now Assist handle this kind of nuance reasonably well?
- How would you approach it — stricter authoring guidelines, a dedicated symptoms field, something else?
Question 7 — Using GenAI to generate summaries
We don't currently use Now Assist to create knowledge articles, but it strikes me that generating a short summary/purpose field automatically — based on the existing article content — would be a great use case. A read-only field populated by AI from the other fields, essentially. Has anyone tried something like this, and how well does it work in practice?
Thanks
