Writing with Copilot

"My Director asked me to use Copilot and has now said they don't like my written work because it sounds as though it's written with Copilot". We heard this from a delegate at a workshop recently, and we're sure they’re not alone: many are being actively encouraged by their managers to use Copilot in their writing, but some of those managers are then unhappy with the result.

The main reason for that is that there's a difference between a copilot and an autopilot. One helps you fly the plane, the other flies it for you. When was the last time you spotted that someone had used Copilot to write to you, and how did that make you feel? Used well, Copilot saves time, improves accuracy and helps you spot the gaps in your own writing. Used badly, it creates extra work, lets inaccuracies slip through, and strips out any sense of who wrote it. The question worth asking isn't whether to use Copilot for writing, it's how to use it so it stays a copilot, not an autopilot.

Copilot can do a great many things inside a public sector organisation. This piece focuses on one specific application, the writing itself: the letters, briefings, complaint responses, guidance and everyday correspondence that public sector teams produce every day, and what changes when a generative tool becomes part of producing them.

What changes when writing goes through Copilot without a shared standard

Copilot licences have been issued across many public sector organisations over the past year or two, generally with a technical and compliance guide attached and very little beyond it. The guide explains what the tool is permitted to be used for but it rarely explains how to get good, accurate, reader-appropriate writing out of it.

The result is uneven. Some people barely use Copilot for writing at all, because they are unsure of it or worried about what it means for their own role. Others lean on it heavily, and if they do use it badly the writing that comes out shows the difference: sentences run long, perfectly eloquent words that mean very little, and the point of the piece arrives several paragraphs later than it should. None of this is about the tool, it is about the absence of a standard for how to use it - it’s not you, it’s your prompting.

Is what I write with Copilot discoverable?

There is recent guidance from the Information Commissioner's Office worth knowing about. Where Copilot generates part of a response and something in that process turns out to be wrong, it can become part of the discoverable chain of events behind that response. The practical implication is straightforward: know exactly what has gone into a piece of writing before it goes out, and be able to account for it if asked. None of that is a reason to avoid Copilot, but it is a reason to check the facts, figures and claims it produces before they go into anything that leaves your desk.

Why doesn't asking Copilot to add empathy work?

We've watched this go wrong with a team working through their complaint responses. They had started asking Copilot to make replies sound more empathetic, and the tool dutifully added lines such as "I can appreciate how frustrating this might feel." That reads a little like a bad speed date, full of "I," "I," "I," when the only person in the room who should matter is the one sitting across the table. Empathy means understanding what is in the reader's mind, not narrating your own feelings back at them to demonstrate your humanity. Sounds like what a machine would say.

We've seen the same instinct misfire in other settings too. In one legal context, an AI-drafted letter to someone affected by a crime opened with the line "I fully understand how you feel about this," which is neither true nor helpful to say to someone in that position. One extreme example in a healthcare setting: a letter that opened with "I understand how you feel after the death of your child." The lesson is that if nobody is thinking hard about who is reading a piece of writing and what state they are likely to be in when they open it, the machine will not do that thinking on their behalf.

A simple way to prompt Copilot properly: the GCSE method

We teach a simple way to prompt Copilot, built around four questions that happen to spell GCSE: Goal, Context, Source and Expectations.

Start with the goal, plainly: what this is for, and what it needs to achieve. From there, set the context: who it's for, what tone is appropriate, and what situation the reader is in. Next, tell Copilot exactly what it's allowed to draw on, the case file (if that’s allowed by your organisation), the policy document, the previous correspondence, and just as importantly what it must not invent or assume beyond that. Last, say what you want back: the structure, the length, the headings and the format.

We've used this structure for complex public sector writing, case review briefings that needed to weigh evidence formally and precisely against a defined legal test, with every section headed clearly and every conclusion traceable back to a named source document. The same structure works just as well for something much shorter, a two-paragraph complaint response or a page of guidance. It stops Copilot guessing at what you want, and stops it inventing detail you never gave it.

One participant on a recent programme could not get Copilot to fit a briefing onto a single page, however many times she asked. The issue was not the tool, it was that nobody had told Copilot how long a page was. Once she added that single line under Expectations, the problem disappeared.

On the training programme we run to support better writing with Copilot, participants build their own version of this as they go: a working set of GCSE prompts for the reports, correspondence, policy summaries and meeting notes they actually write, ready to reuse once the day is over.

Why writing still needs a human check afterwards

The same principle explains why one insurer became more deliberate about how heavily it leans on AI in customer correspondence. Their conclusion was that written replies still need what they call the human in the machine, phrasing and structure that reads as though a person wrote it and thought about the reader, rather than an automated response with a name at the bottom. Prompted properly, Copilot can produce exactly that, and prompted carelessly, it tends to produce the opposite, which most readers notice.

What good public sector writing looks like day to day

Most organisations write for an average reading age of around nine, whether they have ever measured it or not, and people are often surprised the first time they hear that figure stated plainly. It has practical consequences for how a piece of writing should be built. Put the decision or the answer near the start, and explain the reasoning afterwards, rather than saving it for a conclusion the way a detective novel saves its ending. Cut the waffle too - every additional point left on the page gives the reader something new to respond to, so a shorter, more focused piece of writing is usually also a clearer one.

Teaching this without making anyone feel small

Drafting was never taught as a distinct skill in most schools, and the gap is apparent in workplaces of every kind, not only in the public sector. Good training treats that as a starting point to work from, and gives people practical tools and structure to close the gap, rather than treating it as something to feel embarrassed about.

What the programme covers, and how it starts

Teamshaper’s Writing with Copilot programme is built on this thinking. It is a bespoke programme built around a single organisation's own writing, not a generic course. It begins with a discovery phase, including a short questionnaire, so we understand what the team writes: submissions and briefings, correspondence, internal or external communications, analysis and reports, guidance and procedures, complaints and casework. The session itself runs for a full day (face to face or virtually) and is built around the organisation's own tone of voice and the kind of writing people are dealing with, including the latest prompt and loop techniques, using a structure like the GCSE method above, alongside the underlying writing principles. Most versions of the programme include an optional brief follow-up a month later, run virtually, which helps embed results by checking in on progress made. The result, done well, is less redrafting and second-guessing for the people doing the writing, and an organisation's own style embedded across everything the team writes afterwards.

The tool will keep changing quickly, but the underlying job, writing something a reader can pick up once and understand, has not changed at all, and will not change simply because a machine can now draft the first attempt.

More information about our bespoke programme is here.

We also run half-day masterclasses on writing better with Copilot, that’s here.

Our bespoke version of this built specifically for policy teams is here.