Jiberish
Jiberish
Book a working session

AI Training & Workshops

Write an OpenAI prompt your team can actually check

Turn a vague customer-enquiry prompt into a usable task brief, with an example input, review criteria, and links to OpenAI's developer guidance.

Kyle Del FranciaPublished 6 min read
← The Signal — Blog
In this piece

“Help me respond to this lead” leaves several decisions unstated. Is the assistant summarizing an enquiry, qualifying it, or writing a reply? Can it quote a price? Should it propose a delivery date? A useful prompt gives the assistant those boundaries and gives the person reviewing its work something concrete to check.

This exercise is for a small team preparing internal enquiry briefs before a person responds. It applies OpenAI's developer guidance to fictional business material. It does not send a message, connect a customer database, or require an API key. You can practice with an approved text assistant; implementing the same task in an application requires separate setup and testing.

Provider documentation was checked on September 9, 2026. This is a task-design tutorial, not a comparison of models or a claim that every ChatGPT plan includes the same features.

Start with the decision the reader needs

The reviewer needs to know what the customer wants and what remains unanswered. That is a smaller task than “handle this lead,” and it leaves responsibility for the reply with a person.

OpenAI's prompt engineering guide describes separating instructions, examples, and context. Here, that means supplying the enquiry, the relevant business rule, and a defined output. The example below is an original practice brief; it is not an OpenAI template or a Jiberish Labs service commitment.

Task
Prepare an internal enquiry brief for the person handling new work.
Use only the enquiry and business rule supplied below.

Business rule
A project owner must review scope before confirming a price or date.

Enquiry
We want a new website for our landscaping business.
Could it be ready before our spring promotion?
We have photographs, but the service descriptions need rewriting.
We might want online estimates later.

Return four short sections
1. Requested work: include the source phrase for each item.
2. Timing: preserve the customer's wording; do not infer a date.
3. Open questions: only information needed to assess scope.
4. Reply notes: points for a person to consider before responding.

Treat possible future work as optional and unconfirmed.
Do not quote a fee, promise a schedule, or draft a sent confirmation.
If information is missing, identify the gap instead of filling it.

“Before our spring promotion” is meaningful to the customer but gives your team no exact deadline. The prompt should expose that gap. Asking the assistant to sound confident would not resolve it.

Compare the brief with an answer key

Before running the exercise, write down what an acceptable brief must preserve. This is the answer key for the fictional enquiry above, not a report of a tested model response.

ItemAcceptable interpretationNeeds correction
New websiteA public website is requestedTreating it as a confirmed app project
Spring promotionAsk for the promotion date and required launch readinessInventing a calendar deadline
Photographs availableCustomer says they have photographsClaiming the images are licensed, complete, or suitable
Service descriptionsWriting work needs to be discussedAssuming the customer will supply finished copy
Online estimates laterAn optional future capabilityIncluding a working estimator in the initial scope

Open questions should help someone assess the work. In this case, the promotion date, required pages, responsibility for copy, and meaning of “online estimates” are useful. A long intake questionnaire generated from habit would make the brief harder to use.

If the draft gets one of these wrong, change the instruction addressing that error and run it again. Keep the original input so you can compare the revision fairly. Then try an enquiry with a firm deadline and no optional features. A correction that helps one example should not make the next one less accurate.

Add examples only when they clarify a recurring mistake

If the assistant repeatedly treats future ideas as committed scope, supply a small example showing the distinction:

Example of how to interpret optional work
Input: We may add customer accounts next year.
Desired interpretation: Customer accounts are a possible future
phase. Confirm separately; do not include them in agreed work.

OpenAI describes input/output examples as a way to demonstrate a pattern. Choose examples that reflect the cases your team actually reviews, and keep them consistent with the written rules. OpenAI's guidance on examples.

Model guidance matters here. OpenAI's reasoning best practices recommends trying direct instructions first for reasoning models and adding examples when needed. It also advises against requesting step-by-step internal reasoning as a default prompting technique. That advice has a defined model scope; it should not be turned into a universal rule for every provider and model.

For this business task, ask for source phrases and unresolved questions. Those are useful review artifacts. They let a person check the answer without needing a narration of the model's internal process.

Keep the prompt and the application responsibilities separate

A prompt can describe the brief you want. Your application still needs to control who may access an enquiry, where the draft is stored, and whether anyone can send it. The instruction “do not send” is not a substitute for withholding send permissions from an automated workflow.

If you move this exercise into software, give the developer the prompt, the answer key, examples that previously failed, and the intended human review step. Agree how missing information and an unavailable model should appear to the reviewer. The lead-handoff planning example covers the surrounding workflow.

For a team learning to write and review these briefs, AI Training for Teams can use your approved tasks and review criteria. Connecting the method to existing tools belongs in a separately scoped AI Automation project.

Recheck the task when the model changes

Save the model identifier or displayed model name, date, prompt, and reviewed examples together. Consult the OpenAI API changelog and the guidance for the model you actually use before changing an integration. API announcements do not establish availability in a particular ChatGPT account.

After a change, compare supported facts, unresolved questions, and review effort on the same examples. Keep the version that meets the agreed standard. A release announcement is a reason to investigate a change; your team's task determines whether to adopt it.

Put this into practice

Bring the decision you’re working through.

A working session is a chance to review your goal, the tools or website you have, and the help you need. We’ll identify a sensible next step and discuss scope before any project commitment.

AI Training for Teams →AI Automation →Book a working session