AI Product Development
TeacherTee SDR Training
AI-powered sales practice and evidence-based call coaching
I designed and built an internal SDR training platform for TeacherTee that combines live AI prospect roleplay with real-call transcript analysis.
Both workflows are converted into the same canonical transcript format and evaluated against the same version-controlled TeacherTee sales methodology, producing structured scores, transcript-grounded evidence and prioritised coaching.
- Role
- Product design, architecture, AI system design, implementation, testing and release
- Status
- Production V1.0.0
- Stack
- Next.js · TypeScript · Supabase · OpenAI · WebRTC · Vercel
At a glance
Two ways to improve performance
TeacherTee SDR Training gives the sales team two connected routes into the same evidence-based coaching system.
Shared architecture
Real call or AI practice → canonical transcript → shared scorer → evidence-based coaching.
Practise before calling
Choose a prospect situation and hold a spoken conversation with an AI prospect designed to behave like a real sales contact rather than a coach.
Learn afterwards
Paste or upload a call transcript, confirm the SDR speaker and evaluate the conversation against the same scoring framework used for practice calls.
02
Core workflows
01
Shared scoring engine
Live
Realtime AI voice
V1.0.0
Production release
The problem
Turn a detailed sales method into a repeatable training system
TeacherTee already had a detailed cold-call methodology, but developing SDR performance still relied heavily on human involvement.
Roleplay required another person to be available. Real-call coaching required someone to review conversations manually. Feedback could also vary depending on who reviewed the call and what they focused on.
The goal was not to build a generic AI chatbot. It was to turn the existing sales methodology into a repeatable internal training system that could support independent practice, analyse genuine calls, apply the same standard each time and show the evidence behind its coaching.
Two workflows, one coaching system
Different inputs converge before evaluation
The workflow design keeps transcript preparation and prospect simulation distinct, then gives both the same canonical contract and shared scorer.
01 · Analyse a real call
Human-confirmed roles, consistent scoring input
The SDR can paste or upload a speaker-labelled transcript. The application detects the available speakers, but the user confirms which speaker is the SDR before roles are assigned.
The conversation is then normalised into a canonical SDR/prospect transcript, giving the scoring engine a consistent input regardless of the source format.
- 01Detect speakersApplication identifies available speakers
- 02Confirm SDRUser selects which speaker is the SDR
- 03CanonicaliseTranscript is normalised into SDR/prospect format
- 04ScoreConsistent input for the shared scoring engine
02 · Practise against an AI prospect
Versioned scenarios become scoreable conversations
The SDR chooses from versioned prospect scenarios with different situations and difficulty levels.
Hidden prospect information remains server-side, while the AI reacts to the SDR's behaviour during typed or live voice interaction. Completed SDR and prospect turns are persisted as the conversation develops.
When the call ends, the roleplay is converted into the same canonical transcript format used for real-call analysis. That means simulated and real conversations are judged by exactly the same scoring system.
Architecture
One shared contract connects both workflows
The architecture centres on one shared contract: the canonical transcript. Real transcripts and AI practice calls enter the product differently, but both converge before scoring.
The shared scoring engine then applies the same rubric, evidence rules and coaching logic regardless of where the conversation originated. This avoided duplicated evaluation logic and created one source of truth for SDR performance.
Scoring authority
AI evaluates. Application code scores.
One of the most important engineering decisions was separating AI judgement from scoring authority.
The model identifies competency ratings, transcript evidence, methodology issues and coaching opportunities. The application validates that evidence against the actual transcript before deterministic code applies the frozen scoring weights and methodology-error rules.
This makes the final result more auditable than asking an LLM to generate an arbitrary score out of 100.
- AI assessment
- Evidence validation
- Deterministic scoring
- Coaching report
Domain formalisation
Turning a sales methodology into software
Before connecting the scorer to an AI model, I formalised the TeacherTee SDR methodology into a structured V1 scoring framework.
The rubric covers ten areas including opening execution, context and brevity, questioning, listening, relevance and impact, objection handling, mirroring, meeting lock, decision-maker control and factual discipline.
It also defines observability rules and explicit treatment for major and critical methodology errors. The result is a version-controlled scoring system rather than an open-ended prompt asking whether a call was good.
60%
Method Adherence
40%
Conversational Effectiveness
Frozen scoring contract
Weights and methodology-error rules are applied in application code after validation.
Simulation design
Designing an AI prospect, not an AI coach
A generic conversational model naturally tries to be helpful. That is not useful in a realistic sales simulation.
The prospect engine therefore separates the information visible to the SDR from hidden scenario state.
Server-side scenario state
The AI receives facts about the prospect's authority, existing position, organisation, objections and business impact, but is instructed not to reveal those facts before the conversation earns them.
Behaviour changes resistance
Poor SDR behaviour can make the prospect more resistant. Strong diagnosis can make the prospect more open.
No covert coaching
The prospect is prevented from telling the SDR what to say next. Wrong-contact scenarios reward finding the real decision-maker.
The result is a constrained prospect simulation rather than a chatbot quietly helping the SDR succeed.
Voice session path
- 01Browser audioMicrophone capture begins in the SDR session.
- 02WebRTCAudio moves through a realtime connection.
- 03Realtime AIThe prospect responds in speech and transcript events.
- 04Application stateCompleted turns are deduplicated and tracked.
- 05PersistenceThe call waits for saved exchanges before finalisation.
Only completed exchanges become durable conversation state, and call finalisation waits for persistence to finish.
Realtime system
Making realtime voice reliable
The voice workflow introduced a different class of technical problem.
A single conversation passes through browser audio, WebRTC, realtime AI, transcription, application state and database persistence.
Those systems are asynchronous, so the application needed protection against incomplete exchanges, retries and calls ending before speech had finished saving.
I introduced realtime voice only after the typed practice workflow and scoring handoff were working.
The final implementation includes browser microphone capture, OpenAI Realtime over WebRTC, live transcription, spoken AI prospect responses, persisted conversation turns, recovery logic and call-finalisation safeguards.
This allowed live speech to become reliable application state rather than a temporary model conversation.
Reliability engineering
Hardening beyond the happy path
Once the core workflows worked, the focus moved to reliability. These controls helped move the application from a working AI prototype toward a dependable internal product.
Idempotent requests
Duplicate typed requests and concurrent scoring are controlled before they create duplicate work.
Lifecycle protection
Completed calls are protected at the database boundary, including late writes after a call ends.
Grounded evidence
Referenced turns, speaker roles and quoted transcript evidence are validated before scoring.
Provider timeouts
Provider delays and malformed model output are handled as explicit failure states.
Voice recovery
Incomplete voice persistence and repeated realtime events can recover without corrupting the session.
The application also handles repeated realtime events, malformed model output and incomplete voice persistence. Scoring is idempotent, so an already-scored call reuses its stored result instead of triggering another paid model request.
Product evolution
From foundation to V1.0.0
The sequence reduced risk by establishing reliable data first, then reliable scoring, then simulation, realtime complexity and finally production hardening.
- 01
Foundation
Authentication, data model, transcript ingestion and canonicalisation.
- 02
Intelligence
Scoring framework, structured AI assessment, evidence validation and coaching.
- 03
Simulation
Versioned prospect scenarios, persisted roleplay and realtime voice.
- 04
Hardening
Idempotency, lifecycle protection, recovery and failure handling.
- 05
Release
Security checks, end-to-end QA, production deployment and V1.0.0.
This is product evolution, not a five-day coding diary.
Production implementation
Structured data, protected access and production hosting
The application uses a dedicated Supabase backend for authentication, PostgreSQL persistence and Row Level Security.
Core data is persisted across training sessions, transcripts, practice sessions, individual practice turns and structured scoring results.
Scoring results store more than an overall score. They include competency assessments, transcript evidence, methodology errors, coaching findings and rubric/scorer versions.
The production application is deployed through Vercel.
The V1 codebase also contains 118 automated test declarations across 29 test files, covering transcript normalisation, scoring integrity, evidence grounding, persistence, AI-provider behaviour, realtime voice, idempotency and workflow lifecycle.
Supabase Auth + RLS
Structured scoring persistence
118 automated test declarations
Production V1.0.0
Outcome
A reusable internal learning product reached production V1
TeacherTee SDR Training reached a production V1 with both core workflows operating end to end.
The team responded positively to the product, and it now provides a reusable internal learning tool for practising calls and reviewing real conversations against the same sales methodology.
The value is primarily operational rather than directly financial: more opportunities for independent practice, more consistent coaching, faster feedback loops, reusable evidence from real calls and less dependence on a manager being available for every roleplay or review.
I have deliberately not attached unmeasured claims around conversion uplift, time savings or revenue impact to the V1 release.
What this demonstrates
Product and engineering decisions grounded in an operational method
This project brought together product design, domain formalisation, application architecture, AI system design, full-stack implementation, realtime AI integration, reliability engineering, testing and production release.
The most important capability it demonstrates is the ability to take a real operational problem, formalise the business methodology behind it, convert that methodology into software rules and architecture, and ship the result as a working production product.
01
Product strategy
02
Domain formalisation
03
Application architecture
04
AI system design
05
Full-stack implementation
06
Realtime AI
07
Reliability engineering
08
Testing and release
Work with me
Building practical systems around real operational problems
I work across product, operations and technical implementation to turn complex workflows into usable software.