Your First Custom GPT: What to Build and What to Skip

Ask ten content teams what their first custom GPT does and nine will describe some version of the same thing: it knows our brand voice, it understands our audience, it writes our blog posts. Then ask how often anyone actually uses it. The honest answer is usually “I tried it for a week and went back to the normal chat window.”

That failure is predictable, and it isn’t about prompt craft. A general-purpose writer GPT is a worse version of the tool you already have, because you’ve traded flexibility for a set of instructions that were written before you knew what you’d be asking. When you paste a half-finished paragraph into plain ChatGPT and say “tighten this, keep the client’s phrasing in the second sentence,” you get exactly that. When you paste it into WriterBot 9000, you get something filtered through 2,000 words about your tone of voice, your six audience personas and your ban on the word “leverage”, and you spend the next four minutes undoing the filtering.

The test a candidate has to pass

Custom GPTs are not smarter assistants. They’re frozen configurations: a fixed instruction set, an optional pile of reference files, and a shortcut in your sidebar. Freezing only pays off when the same shape of job comes round again and again.

So before you build anything, run each idea through three questions. Will you run it at least four times a month? Does it have a rigid output format that you could describe to a new hire on one side of A4? And can it be done with information you can hand over at the start, rather than information the assistant has to go and find?

Three yeses means build it. Two yeses means you want a saved prompt in a Notion page or a Slack canvas, not a GPT. One yes means you want a chat window and ten minutes.

Applied honestly, that test rules out almost everything teams get excited about and leaves three jobs standing.

Build one: the brief generator

Briefs are the highest-leverage thing a small content team does badly. They’re also gloriously repetitive, which is exactly what you want.

Here’s the shape of the instruction set that works. Note how much of it is refusal and constraint rather than encouragement:

You produce content briefs. You never produce drafts. If asked for a
draft, output the brief instead and say why.

Refuse to proceed until you have all four inputs:
target keyword, the top 3 ranking URLs, buyer stage, the pillar page
this must link to. Ask for whichever is missing. Do not guess.

Output these eight sections, in this order, with these headings:
1. Three working titles, max 60 characters each
2. Search intent, one sentence
3. Primary keyword + 4 secondaries (flag which belong in H2s)
4. The angle the three ranking URLs have all missed
5. H2 outline: purpose in one line each, word count per section
6. Three specifics the writer must source: one number, one named
   tool, one UK example
7. Two internal links, chosen from links.csv in your knowledge
8. What to leave out, and why

Hard cap: 450 words. Long briefs get skimmed.

Upload three things as knowledge: your internal link inventory as a CSV (export it from Screaming Frog, strip it to URL plus a one-line description), your two best hand-written briefs, and your two worst-performing published posts with a note on what went wrong.

The output should look boring, which is the point:

4. THE ANGLE
All three ranking pages treat this as a beginner explainer and
stop at "define your goals". None of them show a sequence or an
owner. Our angle: the build order, costed in hours, for a team
that has no engineer.

6. SPECIFICS THE WRITER MUST SOURCE
Number: the character limit on the GPT instructions field
Tool: one named alternative (Claude Projects or Gemini Gems)
UK example: a UK agency or in-house team, not a US SaaS brand

8. LEAVE OUT
No section on fine-tuning. No API talk. No "the future of AI".

Timings from teams who’ve done this: a hand-written brief takes 35 to 45 minutes. A generated brief that you then edit takes 10 to 14. Across a 12-post month that’s roughly five hours back, which is the entire justification.

Build two: the voice enforcer

The second GPT is the one people build first and wrongly. Do not build a thing that writes in your voice. Build a thing that marks work against your voice and hands back a list.

Write out twelve rules. Not forty. Twelve, each one testable, each one something a subeditor could tick or cross. Ours look like: sentences over 30 words get flagged. No “in today’s fast-paced world”. Second person, always. Numbers as digits from two upwards. UK spelling, and Oxford comma only where the sentence genuinely needs it. Every claim about performance carries a figure or gets cut.

Then instruct the GPT to output a table and nothing else:

| Line | Rule broken | Found | Suggested |
|------|-------------|-------|-----------|
| 14 | Sentence >30 words | "Because when you..." | Split at "because" |
| 22 | Banned phrase | "game-changing" | "faster" or delete |
| 31 | Claim with no number | "significantly better" | Add the % or cut |

Three rules make this work rather than annoy. No rewriting the whole piece. No commentary on how good the writing is. No flagging anything that isn’t one of the twelve rules, ever. Tone advice generated on the fly is what makes house-style bots insufferable.

Agencies get one real exception to the “don’t build many GPTs” principle here: if you run five clients with genuinely different house styles, build five voice enforcers with the same skeleton and different rule files. Copying a working configuration and swapping the knowledge takes about fifteen minutes.

Build three: the metadata batcher

Nobody’s career was made by writing meta descriptions, and nobody’s team has ever been fully caught up on them. This is the job that most rewards a frozen configuration, because the inputs and outputs are both machine-shaped.

Crawl the site in Screaming Frog, export URL, H1 and current title, and paste 20 rows at a time. The GPT’s instruction set is mostly arithmetic: titles under 60 characters, descriptions between 120 and 155, primary keyword inside the first 65 characters of the description, no two descriptions on the site opening with the same three words, output as CSV with no preamble.

url,title,meta_description
/ai-content-briefs/,"Content Briefs That Stop Generic AI Drafts","Write briefs that force specifics: sources, numbers and angle. A template and two worked examples for small UK content teams."
/voice-guidelines/,"House Style Rules Your Team Will Actually Use","Twelve testable voice rules beat a 40-page guide. How to write them, and how to check work against them in under five minutes."

Twenty rows takes about 90 seconds to process and five minutes to check. A backlog of 300 URLs, which is very normal for a site that’s been publishing for four years, becomes an afternoon rather than a quarter’s worth of guilt.

What to skip, and why

Ideation GPTs are the biggest waste. Idea generation is the one job where the frozen instruction set actively hurts, because you want range and the configuration is a narrowing device. Use a plain chat window with your Search Console query export pasted in.

Research assistants fail for a different reason. Knowledge files are a snapshot, and they rot silently: six months on, your GPT is confidently citing a pricing page that changed in March. If the job needs current information, it needs search, not a file.

Skip the strategy GPT, the “act as our Head of Content” GPT, and anything whose output is advice rather than an artefact. Advice you have to evaluate isn’t saved time.

Multi-step chains also don’t belong in a GPT. When your real want is “when a post publishes, generate four LinkedIn variants and drop them in Airtable for approval”, you want Make or Zapier doing the moving and a GPT doing at most one step inside it. That distinction, and how the pieces fit together, is the whole subject of our guide to automation, repurposing and custom GPTs.

The build order for a five-person team

Sequence matters more than the individual configurations, mostly because enthusiasm is finite and the first fortnight is when it’s highest.

Weeks 2, 3 and 5 are the ones teams skip, and they’re where the value is. A first-pass instruction set is always too polite and too vague. You find that out by watching what you edit in the output, then pushing those edits back into the instructions as rules. The instructions field caps at 8,000 characters, which is roughly 1,200 words: plenty, if you’re writing rules, nowhere near enough if you’re writing an essay about your brand.

One warning about knowledge files, since this is where second-time builders overreach. You can attach up to 20 files, and you should attach two or three. Every extra document is another thing the model might retrieve when it shouldn’t, and retrieval noise looks exactly like the model being stupid.

Now for the part nobody puts in the guides on how to build a custom GPT. Put a recurring reminder in your calendar for eight weeks after you launch each one, and when it fires, write a brief by hand before you look at the GPT’s version. If yours is meaningfully better, the instructions have drifted out of date with how you actually work, and twenty minutes of editing them is the highest-return thing on your list that week.