Skip to main content
During a sales call, useful coaching has to answer different questions: what should the representative do next, how does their delivery sound, and what does the customer need? The rep’s voice can answer the first two, but customer needs also require the customer’s actual earlier words. Treating the rep’s tone as the customer’s would give the wrong advice. This cookbook builds a sales-coaching backend with the Tazo Python SDK. It streams the rep’s audio itself to three sessions and supplies earlier conversation as text. Each session answers one focused question, and the backend prints feedback as answers arrive. The runnable script and recordings are in the cookbook repository.

Why three persistent sessions

A streaming session takes one question. Open three sessions for one rep reply, send the same audio to each, and keep them open throughout that reply. This avoids starting three new connections for every second of audio. Use audio_scope="turn" so each evaluation hears the reply so far. A 1,000 ms evaluation interval requests frequent feedback; it does not guarantee that answers arrive every second. The interval applies to each of the three sessions, and every evaluation uses your account’s inference allowance.

Setup

Use Python 3.11 or newer:
The example replays a nonempty mono 16 kHz PCM16 WAV of at most 30 seconds at microphone speed. It requires only Tazo. The source app’s web UI, transcription and simulated voice partner are outside this recipe.

Define the coaching questions

The option descriptions tell Tazo what each choice means. Keep them distinct and short: they share the request’s text budget with the instructions and history. Each question includes NO_TOOL for insufficient evidence. These sales questions are condensed from the source project’s coaching definitions.

Supply history and decide when to trust feedback

History contains only turns before the attached reply, with explicit rep and customer roles. It is supplied by your application; Tazo does not transcribe it. With a live call, refresh that history when a new reply starts. Do not append the current reply’s transcript as if it were something the customer said. The helper rejects an oversized request instead of silently dropping turns. Keep the relevant context short enough for each question’s 1,000-character budget. A choice needs at least 65% confidence and a 12-point lead over the runner-up to clear the review gate. NO_TOOL always needs review and is represented as null in the output.
Confidence describes certainty in a choice; it is not a rating of the rep’s performance. Delivery labels describe an audible impression, not a diagnosis or proof of inner feelings. The receiver below also forces customer feedback to review when no earlier customer text is available, even if the model guesses a confident label.

Stream a reply and consume feedback

Each question gets one sender and one receiver. wav_chunks removes the WAV header and validates the audio format; pacing imitates a microphone. Frames respect the negotiated message limit, and a numeric turn limit is checked when present. A None turn limit means the service has not advertised a cumulative cap. At the end of the recording, commit the turn, consume its final decision, call finish(), and keep receiving through normal closure. The final answer must cover the full reply. A provisional update can change as more speech arrives.

Run all three questions together

The three tasks share a client and receive identical WAV samples. A failed question cancels its siblings, and context managers close the sessions. There is a 180-second deadline for this recorded-reply example; it is separate from the audio duration limit.
From the cookbook repository root:
The supplied history is a JSON list in this format:
Every output line contains question, event, choice, confidence, needs_review and all option probabilities. Output from the three sessions can interleave. The speech fixtures are synthetic macOS voices. These were observed in a live SDK 0.1.2 check; choices, confidence and the number of intermediate updates vary between runs: The discovery clip illustrates why the application checks evidence as well as confidence: the model selected a customer need without any customer history. The solution clip shows why a close runner-up should keep feedback in review.

Build on it

  • Connect a live microphone. Replace the WAV sender with paced PCM16 frames. Gate capture during partner playback and silence; this example assumes its input is already a rep reply.
  • Start the next reply. Open fresh sessions with updated earlier dialogue when the rep speaks again. Longer live replies need turn-limit handling if a numeric limit is advertised.
  • Change the scenario. Replace the question specifications with interview improvement, answer direction or support-call coaching. Keep role attribution explicit.
  • Show useful feedback. Display the chosen suggestion and its review flag; retain the probabilities for inspection rather than converting them to a performance score.

Limitations

  • The thresholds are starting points, not calibrated guarantees. Clear speech can still produce low-confidence or incorrect coaching; the example results show both uncertainty and unsupported guesses.
  • Feedback is advisory. The backend does not speak for the rep or execute the suggested move.
  • History is fixed for a reply. An incorrect or missing transcript can mislead contextual questions, and long history is rejected by the local budget check.
  • Failed streams are not reconnected or replayed automatically. Earlier printed updates remain provisional if a later error prevents the final answer.
The full Call Coach source adds a voice partner, more scenarios and a web interface. The runnable adaptation retains the upstream MIT notice.