ChatGPT Custom GPTs: How to Build and Prompt One

The Problem the Team Faced

A customer support lead at a mid-size e-commerce company built a custom GPT to help her team draft replies faster. Within the first week, it had told a customer their refund was approved and processing -- a promise no one on the team had actually made, and one the GPT had no authority to give. The customer, understandably, expected the money to show up. The team had to walk it back, which is a far worse conversation than the one the GPT was supposed to make easier.

This is the failure mode that shows up most often with chatgpt custom gpts: people build them to save time on a specific task, but skip defining what the GPT is explicitly not allowed to do or say. And a GPT without stated boundaries will confidently fill that gap with plausible-sounding but unauthorized answers.

The Wrong Approach

Her first version of the custom GPT's instructions was short and focused entirely on tone and helpfulness, with nothing about limits:

You are a helpful customer support assistant for [Company]. Help 
customers with their questions about orders, shipping, and returns. 
Be friendly and empathetic.

What this does: gives the GPT a role and a general tone, but nothing about what decisions it's actually authorized to make -- which means it has no signal that "approving a refund" is fundamentally different from "explaining the refund policy," and will treat both as equally within its role.

⚠️ Common mistake: Defining a custom GPT's personality and helpfulness in detail while leaving its actual authority and boundaries unstated. A GPT that sounds confident and helpful but has no defined limits will extend that confidence to decisions it was never meant to make.

The Correct Prompt

The fixed version explicitly separates what the GPT can explain from what it cannot decide:

You are a customer support assistant for [Company]. You CAN: explain 
our shipping policy, order status based on provided tracking info, 
and our stated return window (30 days). You CANNOT: approve refunds, 
make exceptions to policy, or promise specific outcomes ("your refund 
will be processed"). For any request outside what you CAN do, respond: 
"I'll flag this for our team to review directly, since it needs a 
human decision." Never imply an action has been taken that you 
haven't actually confirmed.

What this does: the explicit CAN/CANNOT split, plus a clear fallback response for anything outside its authority, gives the GPT a hard boundary instead of an implicit one -- and the instruction against implying unconfirmed actions directly targets the exact failure that happened with the refund promise in the first place.

⚡ Pro tip: For any customer-facing custom GPT, explicitly list what it cannot do, not just what it can. Most instruction failures come from an unstated boundary, not a stated one being ignored.

Results and What Changed

After the fix, the support lead ran two weeks of monitoring on flagged conversations. The GPT correctly deferred refund and exception requests to a human roughly 40 times, with zero instances of implying an unauthorized action had been taken. Customer-facing accuracy on policy questions it was actually meant to answer stayed just as strong as before -- the boundary didn't make it less helpful on its actual job, it just stopped it from overreaching into decisions it was never supposed to make in the first place.

A different team at a software company building an internal onboarding GPT hit a related but distinct issue: their GPT would answer questions about company policy confidently even when it was working from an outdated document that had been updated since the GPT's knowledge was originally set up.

You are an onboarding assistant using the attached employee handbook 
as your source. If a question seems like it might have changed 
recently (compensation, benefits, remote work policy), remind the 
user to verify with HR directly rather than treating your answer as 
final, even if you're confident in what the document says.

What this does: flagging specific categories prone to frequent change, rather than a blanket "always double check everything," keeps the GPT useful for stable information while adding a safety net specifically where policy documents tend to go stale fastest.

How to Apply This to Your Situation

Before building any custom GPT for a customer-facing or decision-adjacent task, list out every action or claim it might plausibly be asked to make, and sort each one into "can do directly," "can explain but not decide," and "must defer to a human." That sorting exercise, done before writing a single line of instructions, is what prevents the refund-promise failure from happening in the first place.

A recruiting coordinator building a custom GPT to answer candidate FAQs applied this same sorting process before launch, and caught in advance that questions about salary negotiation needed to defer to a human recruiter rather than get answered directly by the GPT -- something she hadn't initially considered a real risk until she went through the exercise carefully.

You are a candidate FAQ assistant for [Company]'s hiring process. You 
CAN answer questions about interview format, timeline, and general 
role responsibilities from the job posting. You CANNOT discuss salary 
negotiation, benefits specifics, or make any commitment about hiring 
decisions or timeline guarantees. Defer these to: "Our recruiter will 
cover that directly -- I'll make sure they know you asked."

What this does: pre-identifying the sensitive categories (salary, hiring decisions) before launch, rather than discovering them reactively after a bad interaction, is the difference between a proactive boundary and a boundary built in response to a mistake that already happened.

Testing Before Launch

The support lead from the opening example now runs every new custom GPT through a specific adversarial test before it goes live: deliberately trying to get it to overstep its stated boundaries, rather than only testing the happy path where users ask reasonable questions.

I want to test this custom GPT's boundaries. Simulate 5 different 
customer messages that might try to get an exception, refund promise, 
or policy override, ranging from a direct request to a more indirect, 
emotionally framed one ("I've been a loyal customer for years..."). 
Show me how the GPT responds to each.

What this does: testing with emotionally framed edge cases, not just direct requests, catches a specific failure pattern where a GPT holds firm against a blunt ask but softens under an appeal to loyalty or hardship -- exactly the kind of message a real customer is more likely to send when they actually want an exception made.

⚠️ Common mistake: Testing a custom GPT only with straightforward, polite questions before launch. Real users, especially ones motivated to get an exception, phrase requests in ways designed to find the soft spot in a boundary -- test for that deliberately rather than discovering it in production.

A team building a custom GPT for internal IT support ran into a milder version of the same authority problem: their GPT would sometimes suggest workarounds for security policies when a user described being blocked by one, treating the user's frustration as a signal to be more "helpful" by finding a loophole.

You are an IT support assistant. If a user is blocked by a security 
policy (VPN requirement, permission restriction, etc.), explain the 
reason for the policy and the correct process to request an exception 
through IT. Never suggest a workaround that bypasses the policy, even 
if the user seems frustrated or the request seems reasonable.

What this does: explicitly naming frustration as a factor that should NOT change the response is what prevents the GPT from reading user emotion as a cue to relax a boundary it's supposed to hold consistently regardless of how the request is framed.

⚡ Pro tip: If your custom GPT enforces any kind of policy or boundary, explicitly state that user frustration or a sympathetic framing should not change the response. Otherwise, the GPT may treat emotional appeals as new information rather than recognizing them as the same request in different packaging.

Next Steps

Before launching any custom GPT that interacts with customers, candidates, or employees on a decision-adjacent topic, run through the CAN/CANNOT sorting exercise explicitly, and build in a clear deferral response for anything outside the "can" list. Test it with a handful of edge-case questions before it goes live, not after -- and specifically include the emotionally-framed edge cases, since those are the ones most likely to slip past a boundary that only gets tested against polite, direct requests.

If you're building multiple custom GPTs across different teams, it's worth keeping a saved library of instruction structures -- the CAN/CANNOT framing, the deferral language, the staleness caveat -- so each new GPT starts from a proven pattern instead of rediscovering these boundary issues independently, one embarrassing incident at a time. PromptABCD works well for storing and reusing instruction templates like this across a growing set of custom GPTs.