Every Monday at 8:40 a.m., Maya opens ChatGPT and types the same paragraph. Role, audience, hard rules, section order. She pastes last week’s bullet notes. She gets a one-page status draft. By week six the ritual still works, but she has forgotten a rule twice, and two teammates now keep their own slightly different versions in sticky notes. Nobody is “doing AI wrong.” They are paying a tax for a recipe that only lives in memory.
This is Part 1 of the Custom GPTs tutorial. A Custom GPT (OpenAI also just says “GPT”) is a saved ChatGPT setup for a specific job: name, instructions, optional knowledge files, optional tools. You open it, and the recipe is already loaded. If accounts, plans, memory, and first-week safety still feel fuzzy, start with Learn ChatGPT from scratch. If Chat vs Work vs Codex and “when is a GPT even the right door” still blur in standups, keep the ChatGPT product map open (especially the plain chat vs Custom GPT part). Everyday writing and planning without agent blast radius live in the ChatGPT everyday tutorial. Multi-step office deliverables live in the ChatGPT Work tutorial. Repo and coding agent work live in the ChatGPT Codex tutorial. Here we build one simple GPT for one repeating task, without actions, without secrets, without theater.
UI labels, plan packaging, and create rights still move. Treat names and rollout notes below as a July 2026 field guide. Re-check chatgpt.com/gpts, GPTs in ChatGPT, Creating and editing GPTs, and openai.com/chatgpt the week you write team policy or promise a department “we’ll all ship GPTs.”
What you’ll learn
- A plain definition of a Custom GPT: saved name, instructions, optional knowledge, optional actions
- How create rights usually work (paid create; Free often still uses GPTs others made)
- How to pick one repeating job that earns a first GPT
- What to skip on day one: actions, secret files, “superbrain” scope
- A step-by-step first build on web ChatGPT, with Preview as your lab
- A worked example: Monday status brief GPT with a short test set
- Mistakes that waste seats or create unreviewed team noise
- What Part 2 goes deep on: instructions, knowledge files, and actions (light)
Custom GPT in one sentence
A Custom GPT is a version of ChatGPT configured for a specific purpose: standing instructions, optional uploaded knowledge, and optional capabilities or connections, all saved under a name people can open again.
You still chat. The model can still be wrong. You still own the output when it hits a customer, a board packet, or a production system. What changes is setup cost. You stop retyping the same role every Monday. Teammates stop inventing five private variants of the same prompt. The recipe becomes a shared, editable object instead of folklore.
Rule of thumb: A GPT is a saved recipe inside ChatGPT, not a full software product with your own database, SLA, and audit trail. Treat it like a well-named template with brains, not like a shipped app.
OpenAI’s help docs say the same idea in product language: GPTs combine instructions, knowledge, and selected capabilities for a more tailored ChatGPT experience. Building is a web editor flow. Mobile can use GPTs; building stays on web for most people. Creating or editing needs a paid subscription on consumer plans (and workspace permission on managed plans). Using GPTs is broader: signed-in users can talk to GPTs they can access, including ones others shared or published, when product rules allow.
What a GPT is made of (day-one view)
You do not need every knob on the first build. Learn the layers so you know what to touch and what to leave alone.
| Piece | What it is | Day-one advice |
|---|---|---|
| Name and description | How people find and understand the GPT | Boring and clear beats clever and vague |
| Conversation starters | Example prompts shown on open | Three realistic jobs, not marketing slogans |
| Instructions | Standing role, rules, format, refusals | This is the spine; write them first |
| Knowledge | Uploaded reference files | Optional; only stable, non-secret docs |
| Capabilities | Built-ins such as web search, canvas, code tools (as product offers them) | Enable only what the job needs |
| Actions / apps | External connections you define or user-connected tools | Skip for first GPT; higher risk and setup cost |
Part 2 of this series goes deep on instructions, knowledge, and a light tour of actions. Part 1’s job is narrower: ship one useful recipe for one repeating task, prove it on real inputs, and stop.

Plan reality: create vs use
As of OpenAI’s public help pages around mid-2026, GPTs are available to signed-in ChatGPT users for conversation when they have access. Creating or editing GPTs requires a paid subscription. On managed Business, Enterprise, or Edu workspaces, create rights can also depend on admin settings and roles. Free users often can still open GPTs others made or shared, within product and workspace rules. Exact plan names (Go, Plus, Pro, and team plans) and create rights change by market and year. Confirm on your account before you promise “everyone will build one.”
| Question | Practical answer (hedge and re-check) |
|---|---|
| Can Free users chat in ChatGPT? | Yes, within Free limits. |
| Can Free users create Custom GPTs? | Usually no on consumer plans; paid create is the common rule. |
| Can Free users use someone else’s GPT? | Often yes when shared or available under product rules. |
| Where do you build? | Web ChatGPT GPT editor; mobile is mainly for use. |
| Do Business/Enterprise change the story? | Yes: workspace controls, sharing, and data settings matter. |
| If you cancel paid create rights? | Help notes: you may still use GPTs you made, but not create or edit until paid again (confirm current help). |
If you are the only person with a paid seat, you can still create a GPT that teammates open when sharing allows. That is an ownership and budget question, not a free-for-all. Name who pays, who maintains, and who retires dead GPTs. Part 3 of this series covers team sharing without chaos.
Pick one repeating job (not a career)
The first GPT fails when the job sentence starts with “help with everything.” Successful first GPTs sound like a calendar entry:
- “Turn weekly bullet notes into a one-page leadership status.”
- “Rewrite support replies in our calm tone with no invented refunds.”
- “Score a draft brief against our checklist and list missing sections.”
- “Explain this metric definition pack in plain English for new analysts.”
- “Turn meeting notes into action items with owners and open questions.”

Use this filter before you open the builder:
- Repeats. You (or the team) do this weekly or daily, not twice a year.
- Stable shape. Output format barely changes month to month.
- You can name hard rules. At least three constraints you refuse to drop.
- You have three real past inputs. Fake examples hide weak instructions.
- No external system required. Day one should not need custom API actions.
- No secret payload required. Public or already-approved internal reference only.
If the work is still exploratory, stay in plain chat. The product map series said it clearly: invent the recipe in chat, freeze it, then save it. Building first and learning later is how teams collect five half-broken bots with cute names.
What to leave out of your first GPT
Ambition is the enemy of a first useful recipe.
Skip actions on day one
Actions let a GPT call external APIs you define. That is powerful and higher risk: auth, third-party data handling, workspace domain allowlists, and failure modes that look like “the bot is smart” when the API returned garbage. OpenAI documents a full actions path. You will meet it lightly in Part 2. For Part 1, do not wire anything external. Prove the text recipe first.
Skip secret and live operational files
Knowledge is for reference material, not a vault. Do not upload customer exports, raw HR notes, unreleased forecasts, API keys, or “the whole shared drive as a zip.” Prefer public docs or internal docs you are already allowed to share in the way this GPT will be shared. Version file names with dates. If the file changes every day, you will maintain the GPT more than you use it.
Skip “replace Work or Codex” fantasies
A Custom GPT does not replace Work for multi-step office agent jobs that gather across files and produce decks or sheets. It does not replace Codex for repo work with diffs and tests. Those are different doors in the product map. A GPT is mostly a better way to start certain conversations with a fixed recipe. If your real pain is agentic office packages or code changes, go to those tutorials first.
Prep offline before you open the builder
Write these answers in a note. If you cannot fill them, you are not ready to create.
- Job sentence: “This GPT helps ___ produce ___ for ___.”
- Audience: who reads the output, and what they will do with it
- Hard rules: three to seven constraints (no invented numbers, ask when grain is missing, max length, and so on)
- Output shape: section order, tone, length limit
- Refuse list: what it must decline (legal advice, credentials, confidential systems outside scope)
- Knowledge list: zero to a few stable files, each with a purpose and date
- Owner: human name for updates and retirement
- Test set: three real past inputs and a one-line quality bar for each
A thin starter for instructions (Part 2 expands the skeleton) looks like this. Adapt it. Do not paste secrets into it.
You are a careful weekly status editor for a product team.
Audience: busy directors who skim.
Hard rules:
- Never invent metrics, dates, or customer names.
- If a number is missing, write UNKNOWN and ask one clarifying question.
- Prefer short sentences. Aim for one page equivalent.
- List assumptions in a final section.
Output sections in this order:
1) Headline (one line)
2) What shipped
3) What slipped
4) Risks
5) Asks
6) Assumptions and unknowns
If the user pastes messy notes, reorganize into those sections.
If the notes look like confidential HR data or raw credentials, refuse and say why.
Example of good behavior: if notes say "revenue was up" with no number, do not invent 12%. Write UNKNOWN and ask for the figure and grain.Build path: create the GPT on web
Official create flow (confirm labels if the UI moved):
- Sign in to ChatGPT on the web with an account that can create GPTs.
- Open Explore GPTs in the sidebar, or go to chatgpt.com/gpts.
- Select Create.
- Choose conversational builder or configuration view. For learning, configuration view makes fields visible. Conversational builder is fine if you still paste your offline checklist into the chat.
- Fill name, description, and a few conversation starters.
- Paste your instructions. Prefer concrete steps and one short example over a novel of “don’ts.”
- Optional: upload knowledge files that are allowed and stable. Leave empty if unsure.
- Leave actions alone. Enable only built-in capabilities the job needs.
- Use Preview with your three real inputs. Fix instructions before you share.
- Save or create when Preview passes your quality bar. Keep share private until you trust it.
Help notes worth remembering: drafts save while you edit; use Preview before broad sharing; put rules and tone in instructions, not only in files; knowledge is for reference material; version history exists when you need to roll back (re-check auth if you later add actions and restore an old version).
Name it like a tool, not a mascot
Good: “Monday status brief,” “Support tone rewrite,” “Metric glossary coach.” Bad: “Ultimate Strategy Superbrain 9000.” Cute names hide stale bots. Future-you will search for the job, not the joke.
Conversation starters that teach usage
Write starters that match real work:
- “Turn these messy notes into this week’s status sections.”
- “Score this draft against the section checklist and list gaps.”
- “Rewrite this reply in our calm support tone without promising refunds.”
Avoid starters that promise magic (“own the quarter,” “be my CEO”). Starters train habits. Vague starters train vague use.
Worked example: Monday status brief GPT
Setup: Maya’s team ships product features. Every Monday she turns Slack bullets and ticket titles into a one-page leadership status. She has three past note dumps saved as plain text. Leadership cares about shipped, slipped, risks, and asks. They hate invented metrics.
Job sentence
“This GPT helps product managers produce a one-page Monday status for directors from messy weekly notes.”
Build choices
| Field | Choice |
|---|---|
| Name | Monday status brief |
| Description | Turns weekly product notes into a one-page status with assumptions listed. Never invents metrics. |
| Instructions | Role, audience, section order, refuse invented numbers, refuse credentials |
| Knowledge | Optional: short public-style metric glossary file dated in the name, or none |
| Actions | None |
| Share | Private until Preview passes three real tests |
Test set (do not skip)
Run all three in Preview before anyone else opens the GPT.
| Input | What good looks like | Fail signal |
|---|---|---|
| Notes with clear shipped items and one missing number | Sections filled; UNKNOWN for the number; one clarifying question | Invented “about 12%” or silent omission of unknowns |
| Notes that are pure venting with no facts | Thin shipped section; explicit unknowns; asks for facts | Confident paragraph of empty leadership prose |
| Notes that include a password-looking string or raw personal data | Refuse or strip and warn | Echoes secrets into a polished status |
Maya’s first Preview fails test one: the model softens “revenue was up” into “solid growth.” She adds an explicit example in instructions: if no number, write UNKNOWN. Second Preview passes. She keeps the GPT private for one more Monday of solo use, then shares with two teammates who already know the format. Ownership stays with Maya. That is a complete first GPT story. No actions. No store launch. No avatar redesign marathon.
How first-week use should feel
Open the GPT. Paste real notes. Read the draft like a skeptical editor. Fix facts. Send the human version. If the draft saves you ten minutes of structure work, the GPT earned its seat. If you rewrote every sentence for truth, either the instructions are weak or the job still needs plain chat while you invent the recipe.
Help docs also note that GPTs do not use your saved memory, custom instructions, or previous conversations the way personal Chat settings might. Each conversation with the GPT starts from the GPT’s configuration plus what you put in that thread. That is a feature for consistency. It also means you should not assume “it remembers last Monday” unless you paste context or design for it.
GPTs vs other ChatGPT doors (quick map)
| If your job is… | Prefer | Why |
|---|---|---|
| One-off exploration, still inventing the format | Plain Chat | Flexible; no premature freeze |
| Same role and format every week | Custom GPT | Saved recipe, shareable when ready |
| Multi-step office deliverable (deck, sheet, long doc package) | Work | Agentic office loop, not only a chat recipe |
| Repo edits, tests, diffs | Codex | Software project surface |
| App embedded in your product with audit | API / platform engineering | GPTs are not website embeds |
OpenAI’s own FAQ is blunt on embeds: GPTs live in ChatGPT; if you need an assistant inside your product, use the API. Do not sell leadership on “we shipped a product” when you published a GPT with a friendly icon.
Common mistakes on the first build
Building before the recipe is stable
If section order changes every week, stay in chat. Freeze after a few real runs, then create.
Instructions that try to boil the ocean
Long conflicting rule piles make the model thrash. Prefer short sections: role, hard rules, steps, format, refuse, one example. Help’s troubleshooting advice is practical: shorten, remove conflicts, use “when X, do Y,” add one or two examples, test small changes in Preview.
Knowledge as a junk drawer
A 200-page PDF of everything is not a knowledge strategy. Short, purposeful, dated files beat archives. Put behavior rules in instructions, not only in files.
Actions as day-one theater
External calls multiply failure modes. Prove text quality first. Actions can wait until the recipe is boringly reliable.
Sharing before Preview
Private until three real inputs pass. Team trust is harder to rebuild than instructions.
No owner
Orphan GPTs become folklore. Assign a human. Write a simple retirement rule (Part 3 goes deeper on team process).
Practice this week
- Pick one job that already repeats on your calendar.
- Write the offline checklist (job sentence, hard rules, format, refuse, owner, three tests).
- Create the GPT on web if you have paid create rights. If not, draft instructions in a note and use plain chat until you do, or use a GPT a teammate shares when policy allows.
- Run three real inputs in Preview. Fix instructions once per failure mode, not five knobs at once.
- Keep share private for one real work cycle. Then decide whether anyone else needs it.
What Part 2 covers
Part 2, Instructions, knowledge files, and actions (light), goes inside the three layers you barely touched: how to structure instructions so they stick, how to version knowledge without rotting, and why actions are a deliberate later step with higher risk. You will get a fuller instruction skeleton and a clearer “when to stop at text recipes” line.
Quick recap
- A Custom GPT is a saved ChatGPT recipe: name, instructions, optional knowledge, optional actions/tools.
- Creating usually needs paid (Go/Plus+ and similar); Free users often can still use GPTs others share.
- First GPT: one repeating job, no actions, non-secret knowledge only, Preview on three real inputs.
- Instructions are the spine. Name it like a tool. Own it like a process.
- GPTs do not replace Work, Codex, or real software. Different doors for different jobs.
Sources
Research and further reading used for this article:
- OpenAI Help: GPTs in ChatGPT (what GPTs include, create vs use, privacy notes, FAQ)
- OpenAI Help: Creating and editing GPTs (editor fields, instructions, knowledge, capabilities, actions, Preview, version history)
- OpenAI Help: Configuring actions in GPTs (why actions are a later step)
- OpenAI Help: Troubleshooting GPTs (instructions vs knowledge, Preview iteration)
- ChatGPT: Explore GPTs (create and browse entry point)
- OpenAI: ChatGPT product overview (plan and product context; re-check before policy)
- Analytics Made Simple: Learn ChatGPT from scratch
- Analytics Made Simple: ChatGPT product map
- Analytics Made Simple: ChatGPT everyday tutorial
- Analytics Made Simple: ChatGPT Work tutorial
- Analytics Made Simple: ChatGPT Codex tutorial
