infotech
Before you begin
Three things to keep in view.
- Define one useful task and the people it serves.
- Evaluate knowledge and actions with realistic examples and exceptions.
- Plan the handover to people and the ownership of the live experience.
Describe the task in operational terms
Start with what a user is trying to achieve. Finding a maintained answer, checking the status of a request and initiating a transaction are different tasks. Each needs different information, permissions and a different definition of success.
Keep the first scope bounded enough to understand. Identify which requests the agent should handle and what happens outside that scope. A clear task is easier for users to recognise and easier for the delivery team to test than a broad promise to assist with everything.
Put it into practice: Write down the task, audience and completion criteria in plain language.
Know the information behind the answer
Review the knowledge or business records the task depends on. Check whether the source is maintained, whether the terms are understandable and whether the intended users can access it. A source can be technically connected and still be unsuitable for a dependable answer.
Assign someone who can review the content and resolve questions about it. Include examples where the information is missing, contradictory or out of date. These situations help define the agent’s response and the route back to a person who can help.
Put it into practice: Test the source with questions a real user would ask.
Treat actions as business transactions
An agent that takes an action needs more than a conversational response. Define the required inputs, the system it uses and the permissions under which it operates. Decide which actions require confirmation or approval and what the user should see after completion.
Include unsuccessful situations in the design: a record cannot be found, a required field is missing or a connected system is unavailable. The experience should explain what happened and how the task can continue without creating uncertainty about whether work was completed.
Put it into practice: Make the result of an action visible and understandable.
Build an evaluation set before launch
Gather representative questions and tasks with the business owner. Include common requests, ambiguous language, incomplete information and cases outside the intended scope. Agree what a useful answer or successful handover looks like.
Evaluate the experience consistently as it changes. A good demonstration with a few selected questions is not enough to understand everyday performance. Review the failures, identify whether the cause is knowledge, design or integration, and use that evidence to prioritise improvements.
Put it into practice: Use the same evaluation examples to compare successive versions.
Give the live experience an owner
Plan who maintains knowledge, reviews feedback and approves changes to the agent. Define a support route for users and an operational route for issues with connected systems. Those responsibilities should be in place for the first release.
Begin with an audience that can provide useful feedback and a task whose outcome can be observed. Review both adoption and quality. The next stage should reflect what the organisation has learned about the experience, rather than simply adding more sources or actions.
Put it into practice: Agree how evidence from real use will shape the next release.
Explore Microsoft guidance
Make it specific to your business.
Bring a process, a priority or a decision you are working through. Our team can help you explore the Microsoft capabilities and implementation choices that fit.
Start a conversation