Custom GPTs: build one for a repeated job

What a custom GPT actually is

A custom GPT is a version of ChatGPT that you configure for one specific purpose. It's still the same underlying model, but you've wrapped it in three things: standing instructions that shape how it behaves, knowledge files it can draw on as reference, and a set of capabilities you switch on or off (web search, image generation, and so on). Once built, it lives in your sidebar and you start a chat with it the way you'd start any chat, except it already knows its job.

The reason this matters for real work is repetition. If three times a week you open a blank chat and type the same 200 words of setup ("You're helping Fernway's operations team; use UK English; here's our tone; here's the policy we follow"), you're paying that setup tax every time, and so is anyone you'd hand the task to. A GPT pays it once. It's the difference between re-explaining a task to a new temp each morning and training one person who then just does it.

Building and editing GPTs requires a paid ChatGPT plan. Using one that someone shared with you often doesn't, which is part of the point: you build the thing once, and colleagues on lighter plans can still use it.

Throughout this lesson we'll build one real GPT: a "Fernway feedback responder" that drafts replies to customer feedback in the house style, following the response rules from the feedback-process brief. It's a good candidate because it's repeated, has a fixed set of rules, and draws on a reference document. Those are the three signs a task is worth turning into a GPT.

Where to build it, and the two ways in

Open Explore GPTs in the ChatGPT sidebar (or go to the GPTs area directly), and choose Create. You'll land in the GPT builder, which gives you two ways to work:

• The Create tab is a conversational builder: you describe what you want in plain English and ChatGPT drafts the GPT for you: name, description, instructions, even a starter set of example prompts. It's a fast way to get a first version.
• The Configure tab is the manual view, where you edit each field directly: the name, the description, the instructions box, the knowledge files, and the capability toggles.

Use the conversational builder to rough it out, then switch to Configure to tighten it. The conversational builder is friendly but vague; the real quality comes from editing the instructions by hand, because that's where you say exactly how the GPT should behave.

Instructions: the standing brief

The instructions box is the heart of a GPT. It's a longer, more permanent version of a prompt: the rules, tone, workflow and boundaries that apply to every conversation this GPT has. Write it as if you're briefing a competent new colleague who'll do this task without you in the room: what the job is, how to do it, what to avoid, and what to do when they're unsure.

You are Fernway Group's customer-feedback responder. Your job: draft a reply to a piece of customer feedback that I paste in.

Rules for every reply:

UK English, warm and professional, never corporate or defensive.
Structure: acknowledge the specific issue, apologise sincerely if we got something wrong (without over-promising), say what happens next, and give a realistic timeframe.
Keep it to about 120 words unless I say otherwise.
Only commit to things our process actually allows (see the knowledge file). Never invent a refund, a discount, or a deadline I haven't given you.
If the feedback is ambiguous or you'd need information I haven't provided, say so and list what you'd need, rather than guessing.
Always end your draft with a one-line note flagging anything I should check before sending.

Notice what's doing the work here: the boundaries. "Never invent a refund" and "if ambiguous, say what you'd need" are what make a GPT safe to hand to someone else. A GPT that only knows how to succeed will confidently improvise when it hits an edge case, which is exactly when you don't want improvisation.

Knowledge: reference, not rules

Knowledge files are documents you attach to the GPT so it can draw on them when answering. You can attach up to 20 files. The key distinction, and the one people most often get wrong, is this: knowledge is for reference material, instructions are for rules and behaviour. Put your customer-response policy, your product facts, your style examples in knowledge. Put "always use UK English, always structure it this way" in instructions. If you bury a hard rule inside a long knowledge document, the GPT may or may not surface it; a rule in the instructions is applied every time.

For our feedback responder, the natural knowledge file is the response guidance: what we can and can't offer, the standard timeframes, a couple of example replies in the right voice. Upload that once, and every reply the GPT drafts can lean on it.

When you draft a reply, check the response-guidance file for what we're allowed to offer for this type of issue, and apply the standard timeframe from that file. If the file doesn't cover this situation, tell me that explicitly instead of assuming; quote the closest relevant line so I can judge.

Test it before you trust it

This is the step that separates a GPT you rely on from one that just demoed well. Before you use it for real, and definitely before you share it, throw awkward cases at it and watch what it does.

Test with: a normal case (does it follow the structure?), an ambiguous case (does it ask, or does it guess?), an out-of-scope case such as a customer demanding something the policy doesn't allow (does it hold the boundary, or does it invent a refund to be helpful?), and a hostile case (does it stay warm and professional?). You're not checking whether it can write; you know it can. You're checking whether it behaves the way your instructions said, especially at the edges.

Test case. A customer writes: "This is the third time I've reported this and nothing's happened. I want a full refund and a month free, or I'm leaving." Draft the reply following your rules. I'm watching to see whether you invent commitments the policy doesn't allow.

When a test reveals a problem, fix the instructions, not just that one reply, then re-run the test. That loop, edit-and-retest, is how a GPT becomes dependable. Two or three rounds usually gets you there.

Try it now

Common mistakes

• Putting rules in the knowledge file. A hard rule buried in an uploaded document may not get applied. Rules, tone and workflow belong in the instructions; knowledge is for reference the GPT draws on, not behaviour it must always follow.
• No boundaries in the instructions. A GPT told only how to succeed will improvise at the edges, inventing a refund, a deadline, a fact, precisely where you least want it. Always include "when unsure or out of scope, do X" rules.
• Sharing it before testing it. A GPT that writes one good reply in the demo can still mishandle the ambiguous or hostile case a colleague hits on day one. Run the awkward tests yourself first.
• Trusting a knowledge-grounded answer because it came from your file (over-trust). "The policy allows a 10% goodwill credit" feels authoritative because the GPT read your document, but it can misread the file, blend two clauses, or apply a rule to a case it doesn't cover. Have it quote the line it's relying on, and check the source for anything you'll actually send or commit to. The file makes the reference handy; it doesn't make the reading infallible.

Keeping current

Custom GPTs, their file limits, and where they live in the interface all change over time. For the current details, see OpenAI's Creating and editing GPTs and Key guidelines for writing instructions for custom GPTs, plus the ChatGPT release notes. Accurate as of 13 July 2026.