Before you start: what needs to be ready
Deployment only goes smoothly if you have three things in place before your first click in Copilot Studio:
- Scope. A list of the 10–20 most common requests the agent should take over (e.g. “VPN password reset”, “folder access request”, “printer not working”). These define what the agent must be able to do — and what it deliberately doesn't do.
- Knowledge sources. Up-to-date instructions, FAQs and procedures in one place — ideally a SharePoint site or a set of files. Knowledge scattered across emails and people's heads is the most common reason an agent “doesn't work”.
- Escalation target. A specific ticketing system (Jira Service Management, ServiceNow, Zendesk, a SharePoint list) and the fields that must be filled in when a ticket is created.
On the licensing side you need access to Copilot Studio and a Power Platform environment where the agent will live. If the agent is going into Microsoft Teams, you'll also need admin approval to publish the app.
Step 1. Create the agent and describe its role
In Copilot Studio choose Create → New agent. Instead of the conversational mode, go to Configure and enter manually:
- Name — the one employees will see, e.g. “IT Assistant”.
- Instructions — a few sentences describing the role: who the agent is, who it helps, what tone it uses, when it should open a ticket instead of guessing. Example: “You are the IT department's assistant. You answer concisely, in English, based only on the knowledge provided. If you can't find the answer or the user asks for an action (granting access, reporting a fault), open a ticket in the system and give its number.”
The instructions are the most important half-page in the whole project. Come back to them after every testing session.
Step 2. Connect knowledge
In the Knowledge tab add sources: a SharePoint site, specific pages, files or a public website. A few rules that save weeks of fixes:
- Connect a narrow, current set of documents, not “the whole department drive”. The more outdated content, the more wrong answers.
- In the agent settings, turn on the option that limits answers to the knowledge you provided (generative answers only from your own sources). Without it the agent will “fill in the gaps” from the model's general knowledge.
- Check permissions: the agent sees documents on behalf of the signed-in user. If content sits somewhere the employee has no access to, the agent won't use it either.
Quick knowledge test
In the test pane on the right, ask 5–10 real questions from your scope list. At this stage you care about one thing: does the agent answer based on the documents and does it cite the source? If it makes things up or points to the wrong procedure — fix the sources before moving on.
Step 3. Add a create-ticket action
This is where the agent stops being a search box and becomes real relief for first-line support. In the Actions tab add an action — the easiest way is a ready-made Power Platform connector for your system (e.g. “Create issue” for Jira, “Create record” for Dataverse or a SharePoint list).
For each action set:
- Description in natural language — this is how the agent recognises when to use the action. E.g. “Creates a new service ticket when the user reports a fault or requests a permission change”.
- Inputs — the fields the agent will ask the user for before running the action: short title, problem description, priority, location. Mark which ones are required.
- Output — the ticket number and link, which the agent gives the user in its reply.
A good practice is confirmation before saving: the agent shows the collected data and asks “Shall I open a ticket with these details?”. This cuts down on junk tickets.
Step 4. Design the conversation flow
Copilot Studio can drive the conversation generatively based on the instructions and action descriptions alone (orchestration). For key paths, however, it's worth adding explicit Topics to stay in control:
- Greeting — a short note on what the agent can and can't do, plus a sentence saying the conversation may be recorded for quality purposes.
- Escalation to a person — triggered by phrases like “I want to talk to a human”; opens a ticket with the full conversation history and gives the expected response time.
- Fallback — what the agent says when it doesn't understand; after two failed attempts it should offer to open a ticket itself.
Step 5. Test on real cases
Prepare a set of 20–30 scenarios: simple questions, tricky questions, requests for action, attempts to extract information outside the scope, typos, mixed languages. Write down the expected result for each. Run them in the test pane and check:
- whether answers match the documents and cite a source,
- whether the action creates a ticket with all fields filled in,
- whether the agent refrains from running the action when the user is only asking,
- whether it escalates instead of guessing when it lacks knowledge.
Turn on analytics in Copilot Studio — after publishing, it will show which topics are “falling apart” and where to add knowledge.
Step 6. Publish and share in Teams
Click Publish. Then in the Channels tab turn on Microsoft Teams and generate an install link. You have two ways to share it:
- With individuals — a self-install link, good for a pilot with 5–10 users.
- With the whole organisation — an admin approves the app in the Teams Admin Center and pins it, e.g. for selected teams.
Start with a 1–2 week pilot in one department. Collect feedback, refine the instructions and knowledge, and only then roll it out further.
Maintenance: what to do after deployment
A service desk agent is not a “set it and forget it” project. A minimum maintenance rhythm:
- Weekly — review analytics: resolution rate, topics that escalate, unanswered questions.
- Monthly — update knowledge sources with new procedures; remove outdated ones.
- After every change in the ticketing system — check that the action still maps the right fields.
The most common mistakes
- Too broad a scope at the start. An agent “for everything” answers everything poorly. Better to handle 15 topics well than 60 badly.
- Knowledge without an owner. If nobody is responsible for keeping documents current, answer quality drops week by week.
- No confirmation before an action. The result is duplicate and empty tickets.
- Skipping the pilot. Publishing to the whole company at once turns the first week into firefighting.