ChatGPT Voice & Audio

Voice Product Prompts: 6 for Designing a Conversation That Does Not Feel Like Software

OpenAI shipped full-duplex voice this week, which means interruptions are handled natively rather than as errors. That removes one problem and exposes another — most voice products fail on conversation design rather than on audio quality. These six prompts are for working out what your voice product should say, when it should stop talking, and what it should never attempt.

⌨️ 6 prompts 🕐 Updated Sep 12, 2026

💡 How to use these prompts: Replace everything in [BRACKETS] with your specific details before sending. Click Copy to copy any prompt to your clipboard instantly.

Design what happens when someone interrupts

Full-duplex makes interruption possible. Handling it well is still a design decision.

I am building a voice product for: [DESCRIBE]

Map out interruption handling. Specifically:
- What the system should do mid-sentence when the user starts speaking
- When it should stop entirely versus finish the current clause
- How it should recover if the interruption was accidental
- What it should never interrupt itself for

Write it as rules I could implement, not principles.

Work out what to say when it does not know

Text products can show a spinner. Voice products have only silence, and silence reads as broken.

My voice product will sometimes fail to understand or lack an answer.

Write the failure responses. For each, tell me:
- What the user actually hears
- How long before it says anything
- Whether it asks again or hands off
- How it avoids a loop

Silence is worse than an imperfect answer in voice. Design for that.

Decide what needs a human

The last line matters. Voice consent is harder to prove than a button press, and that has consequences.

Here is what my voice product handles: [LIST]

For each, tell me whether it should complete the task, confirm before acting, or hand off to a person.

Be strict about anything irreversible — payments, cancellations, anything that sends. A voice confirmation is weaker evidence than a click.

Write for the ear, not the page

Most voice products fail because someone spoke text that was written to be read.

Here is copy written for a screen: [PASTE]

Rewrite it to be spoken. Specifically:
- Break anything a person could not say in one breath
- Remove structure that only works visually — bullets, parentheses, headings
- Replace numbers and symbols with how they are said aloud
- Cut anything that exists only to fill space

Read it back and tell me where it still sounds written.

Plan the latency budget

Full-duplex is unforgiving of jitter. Knowing where the time goes is the only way to fix it.

My voice product does: [DESCRIBE THE FLOW]

Break down where time goes between the user finishing and hearing a response:
- Recognition
- Any backend reasoning or tool call
- Synthesis
- Network

Tell me which step to attack first, and what the user should hear while a slow step runs.

Decide whether voice is right at all

Plenty of things are worse as voice interfaces. Asking first is cheaper than shipping and finding out.

I am considering voice for: [DESCRIBE]

Argue against it. Specifically:
- What is harder by voice than by screen
- Where users would need to remember something a screen would show
- What happens in a noisy or public environment
- Whether the task genuinely benefits from hands-free

Then tell me whether the argument holds.