Building a Custom GPT for Your Content Marketing Team

Most custom GPTs built by content teams die within three weeks. The pattern is predictable: someone spends an afternoon in the GPT Builder, names it “Content Assistant”, pastes in the brand tone-of-voice deck, shares the link in Slack, and watches two colleagues try it once. The output reads like everything else ChatGPT produces, so everyone goes back to the main chat window and the GPT sits in the sidebar as a small monument to wasted enthusiasm.

The ones that survive have something in common. They do one narrow job, they’re loaded with the specific artefacts your team already argues about, and somebody owns them. This page covers how to build that second kind, using a four-person in-house team as the worked example throughout.

What a custom GPT is actually made of

A custom GPT is a saved configuration wrapped around a base model. You are assembling five things:

• Instructions, a system prompt with a limit of roughly 8,000 characters. This is your main lever.
• Knowledge, up to 20 uploaded files that the GPT searches when relevant.
• Capabilities, toggles for web search, image generation and Code Interpreter (the data analysis sandbox).
• Conversation starters, four suggested prompts that appear on the launch screen. Underrated: these are how you teach a colleague what the thing is for without writing documentation.
• Actions, optional API calls defined by an OpenAPI schema.

Nothing here fine-tunes a model. The GPT has no memory of yesterday’s session, it does not learn your voice over time, and it will not improve because you used it a lot. Quality comes entirely from what you put in those five boxes. If you’re weighing this against the other options in your stack, the wider comparison of scheduled automations, repurposing pipelines and bespoke assistants lives on the parent guide to AI content automation.

You need a paid tier. Plus is around £20 a month per seat and lets you build and share GPTs by link. Team, roughly $25 to $30 per user per month depending on billing cycle, adds workspace-only sharing and keeps business data out of training by default. For a team of three or more who want a shared GPT that isn’t published to a public link, Team is the version worth having.

Pick a job small enough to describe in one sentence

“Help us with content” is not a job. “Turn a keyword, a transcript and our ICP notes into a 400-word brief in our house brief format” is a job.

Narrow scope does two things. It makes the instructions writable, because you’re describing one output format rather than hedging across twelve. And it makes failure legible: when the brief comes back without a search-intent line, you know exactly which instruction to fix.

Jobs that work well for small content teams, in rough order of return on effort:

1. Brief builder. Highest value, because briefs are where most quality is won or lost, and because brief-writing is the bottleneck when you’re commissioning freelancers.
2. House style editor. Takes a finished draft and flags voice, structure and banned-phrase violations without rewriting it.
3. Repurposing splitter. One long asset into a defined set of derivative formats with your channel rules baked in.
4. Performance interrogator. A GSC or GA4 export plus Code Interpreter, answering “which pages lost clicks quarter on quarter and what do they have in common”.

Build the first one. Ship it. Build the second only after the first has survived a month of real use, because you will learn things in that month that change how you write the second.

The knowledge files that make the difference

Here is where most builds go wrong. People upload the 40-page brand book PDF and expect magic. Retrieval works by finding relevant chunks, so a single sprawling PDF gives you unpredictable slices of a design-heavy document, complete with page furniture and pull-quote fragments.

Convert to plain markdown and split by topic. One concept per file, named so you can reference it directly in your instructions. For a brief-builder GPT, six to eight files is the sweet spot:

house-brief-format.md          (the empty template + 2 completed examples)
style-rules.md                 (1,200 words max, rules not adjectives)
banned-phrases.md              (a literal list)
icp-and-segments.md            (who we write for, their job titles, their objections)
product-positioning.md         (what we sell, what we don't claim)
internal-link-map.md           (URL, target keyword, one-line purpose)
published-index.md             (every live URL with its angle, to prevent overlap)

Keep each file under roughly 10,000 words. style-rules.md should contain sentences like “Second person. Never ‘we believe’. Statistics get a source and a date in brackets. No sentence over 35 words.” It should not contain “our voice is confident yet approachable”, which is unfalsifiable and therefore unusable.

banned-phrases.md earns its place fastest. Ours runs to about 60 entries: in today’s fast-paced, unlock, delve, game-changer, seamlessly, robust, elevate, leverage, navigate the landscape, it’s important to note. Because the file has a name, the instructions can point at it explicitly, and the GPT will actually check.

Date-stamp your filenames when you revise: style-rules-2026-07.md. When output quality drifts in four months’ time, you want to know which version of reality the GPT is working from.

Instructions: rules, order of operations, and a refusal

Treat the instruction box as a procedure, not a personality description. The structure that holds up under real use looks like this:

ROLE
You produce content briefs for [Company], a UK B2B [category] company. 
You write briefs for freelance writers who do not know our product.

BEFORE YOU WRITE ANYTHING
Check published-index.md. If the requested topic overlaps an existing 
URL by more than about 50%, say so, name the URL, and ask whether this 
is a refresh or a new page. Do not proceed until answered.

REQUIRED INPUTS
Primary keyword, target reader (from icp-and-segments.md), and either a 
source transcript or three source URLs. If any are missing, ask for them 
in a single numbered list. Never invent them.

OUTPUT
Follow house-brief-format.md exactly, including section order and the 
H2 count. Every brief must contain:
- one sentence on search intent, stated as what the reader is trying to do
- 4-7 H2s as questions the reader would actually type
- three internal links pulled from internal-link-map.md, with anchor text
- a "do not say" line drawn from product-positioning.md
- two specific examples or numbers the writer must source (flag as [VERIFY])

HARD RULES
Check banned-phrases.md before returning. British English. 
Never fabricate statistics, customer quotes or case study details. 
If you don't have a number, write [NEEDS DATA: what to find, where].
Default length 400-500 words. Do not write the article itself.

Three things are doing the heavy lifting there. The ordering instruction (“before you write anything”) stops the model from producing a plausible brief that duplicates a page you published in March. The explicit refusal clause is what prevents invented statistics, which is the single most expensive failure mode in AI-assisted content. And the [VERIFY] and [NEEDS DATA] markers give your writers a searchable string, so nothing unsourced reaches a draft by accident.

Set your four conversation starters to real requests, not categories. “Brief a comparison page for [keyword], reader is a Head of Ops” teaches more in one line than a paragraph of onboarding.

Test it against twelve prompts before anyone else sees it

Write twelve test prompts before you open the builder. Include four easy ones, four awkward ones (missing inputs, a topic you’ve already covered, a keyword with mixed intent), and four that should be refused or challenged (a claim you can’t legally make, a request for statistics you don’t have, a topic outside your category).

Score each output 1 to 5 on five dimensions: format compliance, voice, specificity, factual honesty, and whether it did the duplicate check. Your ship threshold is an average of 4 or above with no individual score below 3. Twelve prompts times five dimensions takes about 40 minutes to work through and will surface two or three instruction fixes you’d otherwise discover via a colleague’s annoyed Slack message.

Keep those twelve prompts in a file. When you edit the instructions in six weeks, you re-run them. Without a fixed test set you have no way of knowing whether your edit improved things or just moved the problem.

Actions are rarely worth it at this team size

Actions let the GPT call an external API: pull a keyword’s data from Ahrefs, create a row in Airtable, post a draft to your CMS. Technically straightforward if you have an OpenAPI schema and an API key. Practically, they need auth handling, they break when an endpoint changes, and nobody on a three-person content team wants to be the person who owns that.

Copy and paste is not a failure state. For a brief-builder, the honest workflow is: run the GPT, read the output, paste it into Notion or Asana, edit the two things that need editing. Twenty seconds of friction. If you genuinely want the output landing somewhere automatically, a Zapier or Make step triggered from your project tool will be cheaper to maintain than a custom Action, and n8n is worth a look if you’d rather self-host.

One exception: turning on Code Interpreter and uploading a GSC export costs nothing and changes what a measurement GPT can do. Ask it to compare two date-range CSVs and list pages with a click decline above 20% alongside their average position change, and it will write and run the pandas for you.

What it actually saves, and what to watch

Run the numbers for your own team rather than trusting a vendor figure. A four-person team producing eight briefs a month, at 45 minutes of senior time per brief, spends six hours monthly on briefing. A working brief GPT takes that to roughly 12 minutes per brief including the edit pass, so about 1.6 hours. Call it four hours a month recovered, which is one extra piece of content or, more usefully, four hours of the editorial judgement that AI can’t do.

Watch the edit ratio instead of vanity usage. Every time someone has to substantially rewrite the GPT’s output, they log the prompt and what was wrong, in a shared doc, one line each. After 30 days you’ll have a list of 10 to 20 entries, and clustered patterns in that list are your next version of the instructions. Two recurring complaints we’ve seen: H2s drifting into topics the transcript didn’t cover, and internal links chosen by keyword match rather than reader journey. Both were fixable in four lines of instruction text.

On data handling, check before you upload. Team and Enterprise workspaces don’t train on your business data by default; Plus has a toggle you have to find. Client material under NDA, customer names, anything with personal data in it: run that past whoever owns your data policy first, because a knowledge file shared across a workspace is a processing decision whether or not anyone called it one.

The teams that get real value from this treat v1 as a draft of a process rather than a tool they’ve finished. Your correction log is the roadmap, and the second GPT you build will take about a quarter of the time the first one did.