COPILOT - CUSTOM INSTRUCTIONS
- Jonathan Stuckey
- 3 days ago
- 9 min read
author: Jonathan Stuckey
This article tramples head-long through using Custom Instructions to frame discussions with Copilot and (hopefully) avoid all the tedious trying to jam pre-reqs about the formatting and tone etc. into every prompt.
Prompt rage (disillusionment)
I hear people talk about frustrations with Microsoft 365 Copilot response being worse than other toolsets - as if the quality problem starts in the prompt box. It doesn't. More often the trouble begins earlier, in the quiet little layer where a user tries to define tone, structure, expectations, and working context. It starts when the users assumes the system will treat those instructions as chisled-in-stone - forever. Unfortunately, Copilot (and AI LLM) don't work like that.
Enter Custom Instructions... this is nice little feature embedded in your settings of your profile in Copilot, designed to provide a place to capture all the instructions you want to have preloaded whenever you crack-open the Copilot prompt.
But its not designed to direct Copilot to be 'robotic' (sic) and machine like (ironically). Custom instructions are the starting point for engaging in Chat, but they are not a personality sticker. If we use them we should treat them like operating guidance for Copilot - we have to write them with specificity, context, expectations, and structure.
The practical point is simple: if Copilot keeps producing work that is generic, oddly shaped, or suspiciously fond of tidy little bullet lists that explain nothing of consequence, the answer is rarely “prompt harder”. The answer is define a clearer baseline for how the system should think about your work before you ask it to produce anything at all. That's Custom Instructions (see Resources for background)
Custom Instructions are not magic
They are biasing signals ...or the foundations for the following discussion if you like
Microsoft describes custom instructions in terms of giving Copilot specific guidance about how to respond, including tone, topic focus, and formatting preferences. In other words, the feature exists to bias the model toward a preferred response pattern (i.e. nudge it towards how to work with you)
Well-written instructions improve the starting position for any chat, but don't guarantee that every later prompt, especially one that introduces a new style or an external reference point, will perfectly preserve every prior constraint. Copilot always weighs the immediate request, available grounding, and the shape of the task in front of it.
Microsoft’s prompt guidance reflects this stating that your instruction logic needs: clear goals, context, source, and expectations improve outcomes because the model is constantly resolving among competing signals.
This is why a long Copilot conversation can drift.
The further a thread moves away from the original framing, the more likely the most recent requests begin to dominate the older conversation (prompt) instructions. That doesn't mean the instructions were useless - It means they were treated as part of the context rather than as inviolable laws handed down on tablets from a mountain.
A disappointing answer is not evidence of Copilot's failing. It is evidence that the newer prompt in the conversation won the argument.
So where are the Custom Instructions?
Funnily enough they are are easy to get to, but there's little-to-no built-in support - just a text box for pasting in your rules. [Microsoft's Article]
Basically, open Copilot Chat
Click on ellipsis (...) in top-right corner
Select settings
Under 'Chat settings' dialogue box
Select 'Personalisation'
In 'Custom instructions' click 'Edit instructions'
In the text-box paste in your Declarative Instructions
Paste in Copilot chat instructions Click 'Save instructions'
What Custom Instructions profile should contain
A useful profile does not try to document a whole human being in tragic detail. It captures the parts of working context that repeatedly influence output quality: role, audience, tone, preferred structures, evidence expectations, and the patterns that should be avoided. Microsoft’s own examples and training material point to the same categories, particularly context and expectations, because those are the levers that most directly affect how the Copilot response is shaped.
Custom instructions can include (globally) important things for all chats and conversations (regardless of if in Chat, Browser, or Office app) e.g.
specify use of UK English and professional tone
rejecting hype in favour of authoritative knowledge sources
use explanatory prose over compressed fragments,
define the output structure for different types of work activity,
introducing shorthand triggers that map directly to delivery modes such as working on content for: client, public, technical, or executive.
This is not fluff - it is the operational scaffolding for all other conversations with Copilot.
Many AI-generated “best practice” articles dance around delivery modes and work types with the enthusiasm of a management consultant discovering a whiteboard, but its important to identify that different content types need different structural rules.
For example:
problem root-cause analysis should not sound like a LinkedIn post;
a client decision paper should not read like a product launch;
a public article should not collapse into three decorative bullets pretending to be insight.
A good set of user Custom Instructions should clearly identify these.
Good and bad instruction patterns
The simplest way to improve Custom Instructions is to replace vague preferences with operational rules. Microsoft’s prompt guidance emphasises specific goals and expectations for exactly this reason, but as usual is suspiciously lite on anything broadly useful.
Table: how custom instructions should encapsulate details to support outcomes
Practice | Weak version | Stronger version |
Tone control | “Be professional and sound good.” | “Use UK English. Default to professional-neutral tone. Be confident and helpful without hype, exaggeration, or over-promising.” |
Structure | “Write clearly.” | “Use explanatory text as the primary method. Use tables for repeatable structured content. Use bullets only for summaries or overviews, not for core exposition.” |
Public article behaviour | “Write a blog post for the web.” | “Public: Draft a factual article using Hook → Context → Insight → Evidence → Practical Application → Closing. Use narrative paragraphs for core content.” |
Decision outputs | “Give me a recommendation.” | “Client: Provide conclusion, rationale, scope and assumptions, recommended approach, next steps, risks and mitigations, dependencies, and acceptance criteria.” |
Evidence standard | “Use sources if possible.” | “Use 1–3 authoritative Microsoft sources for feature or licensing claims; prioritise Microsoft Learn, then Support, then blogs.” |
The weak versions read like something written in a hurry five minutes before a meeting, which is fair because that is often exactly what they are. The stronger versions tell the model what success actually looks like, which sharply reduces the chance that it fills the gaps with generic nonsense.
Real examples
A good instruction is one that maps neatly to a known work pattern. For example, if the task is a client-facing recommendation paper, the custom instructions in a profile should not merely ask for a “useful answer”. It should actively invoke the decision pattern that has been defined.
Bad example: “Prepare a response on SharePoint governance options for the client. Keep it concise and professional.”
This instruction is not catastrophic, but it is weak. It does not define the output pattern, does not require risks or assumptions, and says nothing about whether the response is advisory, commercial, or technical. The word “concise” is dangerous because many models interpret it as permission to remove the useful parts first.
Better example: “Prepare a decision-led paper on SharePoint governance options for an external client. Use Discovery → Options → Recommendation → Trade-offs → Plan. Include assumptions, risks, dependencies, and next steps with owners and timing. Use tables where options repeat. Keep the writing client-ready and explanatory rather than list-led.”
This instruction is harder to misread because it uses a structure-selection rule and output expectations. It tells the model what kind of artefact it is producing, who it is for, and what it must contain.
The same principle can apply to any other work-type, such as public writing. The following prompt would produce drift in the Copilot thread - when asked for a blog article and LinkedIn suitability it would nudge the model towards generic web-marketing habits.
Bad example: “Turn this [chat] into a blog post for the internet and LinkedIn.”
That prompt gives the model a channel but almost no editorial discipline. It encourages speed over thought and shape over substance, which is how one ends up with a cheerful stack of headings followed by three anaemic bullet points each, as if the article had been assembled from leftover parts in a content factory.
A stronger version would be to anchor the article in a preferred structure, and explicitly rule out the sort of compressed list format (...which I hugely dislike).
Better example: “Draft a factual article for business and technical readers on how to design effective Custom Instructions for Microsoft 365 Copilot. Use a narrative structure with meaningful exposition, practical examples, and light irreverence. Do not use short list-led sections for core content. Use authoritative Microsoft sources where describing product behaviour or prompt guidance.”
This version of the prompt gives room for personality, but it does not sacrifice control. It tells the model where it may be witty and where it must be accurate, which is a healthier arrangement than letting the machine improvise its own editorial standards.
Common failure modes in instruction design
Failure "modes" there are many (many) of these, but the 3 most obvious and common faux-pas I have seen are:
write instruction sets as a collection of preferences without any binding logic. A profile that says “be clear, be concise, be helpful, be accurate” sounds sensible, but it gives the model almost no practical routing information. Microsoft’s prompt guidance is useful here because it repeatedly stresses the need for clear goals and context rather than vague aspirations.
another classic gaff is over-reliance on prohibitions. If your profile says that bullets should not be used for core content, and that ideas should not be compressed into artificial fragments - those are valid rules. But it is stronger to pair the prohibition with a positive operating instruction, such as “use structured paragraphs for substantive explanation” or “use tables when comparing repeatable options”. That gives the model somewhere to go, not just somewhere to avoid.
mixing permanent profile rules with temporary task instructions until both become muddy. Your permanent profile should hold the stable defaults: language, tone, audiences, evidence threshold, and work modes. The task prompt should specify the immediate objective, format, and success criteria. When those two layers are cleanly separated, the model has less room to invent its own plan and call it initiative.
Dialling in the right level of instruction
If you mash the red-button on Copilot's output quality when you give it instructions on design, and again (and again) from the the repeated refinements of task you ask it to do, then Copilot will ignore the instructions that came at the beginning unless you re-state it should go back to core instructions.
E.g. If we ask Copilot to develop work persona for creating profile Custom Instructions, but later in the same chat we think "this would be great as a guide or article!" - and then instruct Copilot to then create that content, it will cheerfully forget all the Custom Instructions and go back to LLM defaults for creating marketing content - not exactly what we want.
Basically its a bit like: Last-in, First-out for how it should perform the next action.
Where grounding matters more than personality
Custom Instructions help shape form, tone, and behavioural defaults, but grounding determines whether the answer has any right to exist in the first place.
Copilot answers you by connecting prompts to contextual data sources, including work data, web data, and local data attached to the prompt. That matters because a beautifully personalised answer can still be wrong, vague, or unhelpful if it is not grounded in the right source material.
Best practice is not merely to maintain a good profile, it is to combine that profile with explicit grounding whenever the task depends on facts, product features, organisational documents, or current information.
Available Microsoft guidance around context and source supports this approach, and updated Copilot capabilities let users attach or insert work content into prompts move in the same direction: fewer unsupported guesses, more contextually anchored output.
The real goal is not obedience. It is reliable usefulness.
The point of Custom Instructions is not to make Copilot admire your preferences from afar or recite them back like a trained parrot. The point is to improve the odds that the first usable draft is closer to your standard, your audience, and your way of working.
Microsoft presents the Custom Instructions feature in exactly those terms:
"a way to provide specific guidance on tone, focus, and format so responses are better aligned with what you need.."
Used well, Custom Instructions reduce friction, speed up iteration, and make Copilot less likely to produce work that needs a full emotional support rewrite. Used badly, they become a vague blob of preferences that sound thoughtful and govern very little. The difference is structure, clarity, and the discipline to restate task-critical constraints when the work type changes.
In other words, the answer is not to hope the model will remember what mattered six prompts ago. The answer is to design the standing instructions properly, then reinforce the important bits when asking for a specific output.
This is less romantic than the Youtube experts would like to have you believe about the 'magic' of Copilot AI, but it is much closer to how it actually behaves.
Want to know more?
Understanding prompting is one thing, but understanding when, where and how to establish the right controls with features like Custom Instructions takes your that one-step closer to AI. Give me a call and I'll walk you through how to take the next steps.
Resources
About the author: Jonathan Stuckey
Comments