Stop Re-Explaining Your Business to ChatGPT Every Morning

Here is a pattern we see in almost every company we train. Someone opens a new chat. They explain what the company does, who the client is, what the deliverable is, what tone to use, and what format to return. They get a solid draft. It saves them thirty minutes. The next morning, they do the whole thing again.

That is the ceiling of prompting, and most teams spend a year sitting on it. The next step up is not a better prompt. It is saving the context once so nobody has to type it again.

Prompt, Project, Custom GPT

These three words get used interchangeably, which is part of why people stay stuck. They are different things.

• A prompt is one instruction in one conversation. Everything you explain applies to that chat and dies with it.
• A Project is a workspace that holds related chats, plus instructions and reference files that apply to all of them. Open a new chat inside the Project and it already knows the background.
• A Custom GPT is a configured assistant built for one job. It has written instructions, its own reference documents, and a defined output. You can share it with your team, and everyone who uses it gets the same behavior.

A prompt is telling a temp what to do today. A Project is giving them a desk with the reference binder already on it. A Custom GPT is a trained team member who knows the process and does it the same way every time.

Pick the right task first

Not every job is a good candidate for a Custom GPT. The ones that work share four traits:

• You do it at least weekly.
• The output is text or a document.
• You can tell good from bad when you see it.
• There is a right way to do it that currently lives in someone's head.

Proposal drafts, client onboarding responses, job descriptions, service reports, and follow-up emails all qualify. Strategy does not. Anything requiring a judgment call you would not delegate to a new hire does not either.

For this walkthrough, we will build a proposal drafter.

Building a Custom GPT, step by step

1. Gather your raw material. Pull three to five of your best past proposals, the ones you would be happy to receive. Add your pricing structure or scope boilerplate, a short description of your services, and any notes on how you talk about your work. This is the single highest-leverage step. The assistant will only be as good as the examples you hand it.

2. Write the instructions. This is the configuration field where you define the job. Cover five things: who it is writing as, what information it needs from the user, what the output should contain, the rules it must follow, and what to do when something is missing. Be blunt. Write it the way you would brief a competent new employee who has never seen your business.

A workable version reads something like this:

You write project proposals for a Denver commercial services company. The user will give you the client name, scope, and budget range. Produce a proposal with these sections: summary, scope of work, timeline, investment, next steps. Match the voice in the attached examples. Never invent pricing. If the budget range is missing, ask for it before writing. Keep the summary under 150 words.

3. Load the reference files. Attach the examples and boilerplate you gathered in step one. These become the assistant's knowledge, and it will pull from them rather than guessing.

4. Add conversation starters. Two or three sample openers so a teammate who has never used it knows how to begin. Something as simple as "Draft a proposal for a new client" removes the blank-page hesitation.

5. Save and share it to your workspace. On a business plan, you can publish it internally so your whole team uses the same one. This is the step people skip, and skipping it is how you end up with five slightly different assistants doing the same job.

Test it like a new hire, not a magic trick

Before anyone uses it on live work, run three jobs you already know the answer to. Feed it the inputs from proposals you have already sent and compare what comes back.

When it gets something wrong, resist the urge to fix the output. Fix the instructions. Every failure maps to a missing line:

• It invented a price. Add an explicit rule that pricing comes only from the attached documents.
• The tone is off. Your examples are not representative, or you need a sentence naming the tone directly.
• It rambles. Set a length limit per section.
• It guessed instead of asking. Tell it which fields are required and what to do when they are absent.

Two or three rounds of this usually gets you to something a team can rely on. Budget an hour for the build and a second hour for the tuning.

The same idea in Claude

If your team runs on Claude instead, the equivalent is a Project. You create it, add custom instructions that define the role and rules, and upload the same reference documents to the project knowledge. The mechanics differ slightly, but the concept is identical.

Pick whichever platform your team already pays for and build there. Running both at once is how a rollout dies of small friction.

The part that is boring and matters

Three things to settle before this spreads across your company.

Use business accounts, not personal ones. Business and team tiers give you administrative control, workspace-level sharing, and different data handling than free consumer accounts. If the assistant contains your pricing and client language, it should not live in someone's private login.

Decide what reference material goes in. Your service descriptions and past proposals are usually fine. Signed contracts, client financials, and anything with personal information usually are not. Make that call deliberately rather than discovering it later.

Review it quarterly. Pricing changes. Services change. An assistant trained on last year's material will confidently produce last year's answers.

What changes when it works

The obvious gain is time. The real gain is consistency. Right now most employees’ task processes exist in their instincts. A Custom GPT is the first time most small businesses actually capture a standard and give everyone access to it.

It also changes onboarding. A new hire in week one can produce a competent first draft, because the institutional knowledge is no longer something they have to absorb by osmosis over six months.

Start with one. Pick the task your team complains about most, build the assistant, and use it for two weeks before you build a second. The teams that end up with a dozen working assistants got there one at a time.

H1 AI Consulting offers training on how to identify tasks that can become Custom GPTs within your organization, while also building and fine-tuning them alongside you. Book a 30-minute discovery call to talk through this process with your team.