A browser-based AI sales training tool that simulates difficult customer scenarios and coaches salespeople to respond with empathy, clarity, and professionalism.
Built by a product professional as a working prototype demonstrating AI application design, working understanding of the code, and the ability to debug and iterate.
This project demonstrates that a product professional can engage with AI systems at a depth that makes them a more effective designer, decision-maker, and collaborator with technical teams.
The hardest problem in AI products is knowing whether they are working. This project uses a structured rubric and an LLM judge architecture to evaluate salesperson responses.
Most AI prototypes call an API and display the result. This one measures whether the output is good, makes evaluation consistent, and prevents the model from rewarding fluent but hollow responses.
Before writing any code, the evaluation criteria were designed as a structured rubric with specific level descriptions: observable behaviours at each score level, applicable to any AI product that needs to evaluate human or machine output. This is the same discipline used in professional assessment design.
The app uses two distinct AI agents, each with a clearly defined role. The scenario generator creates realistic customer situations. The judge evaluates the response against a structured rubric, produces dimension scores with specific feedback, runs pass/fail integrity checks, and generates a targeted coaching tip, all in a single call. Keeping generation and evaluation separate makes each agent independently tunable.
Every prompt was designed with specific principles: anti-gaming instructions, behavioural specificity, structured output format, and temperature control. The judge prompt was calibrated in Google AI Studio before any code was written, testing against known response qualities to verify score separation and feedback specificity.
This project documents what was chosen, why, and what would change at scale.
Sales teams lose deals and damage customer relationships because individual salespeople lack a safe environment to practise difficult conversations. Real calls have real consequences. Traditional role-play requires a trainer to be present. This tool lets a salesperson practise alone, at any time, against realistic scenarios, and get specific feedback on exactly what to improve.
- The salesperson chooses a scenario type: angry, confused, or price-sensitive customer
- A scenario is generated and read aloud via text-to-speech
- The salesperson types their response as they would say it on a real call
- The scoring criteria are available inline on the same page for reference
- The response is evaluated against a structured rubric
- A scorecard displays scores, specific feedback, pass/fail integrity checks, and a coaching tip targeting the weakest dimension
- The salesperson is encouraged to retry the same scenario and track improvement over time
| Agent | Role | Temperature |
|---|---|---|
| Scenario Generator | Creates realistic customer situations with type-appropriate writing style | 0.9 (varied) |
| Judge | Scores the response against the rubric, runs integrity checks, and generates a coaching tip, all in a single structured JSON response | 0.0 (consistent) |
The scenario generator uses high temperature (0.9) for variety. The judge uses zero temperature for consistency, so the same response scores the same way every time.
The coaching tip was originally a separate third agent. It was merged into the judge prompt to halve response time. The judge already has all the context needed to generate an actionable tip, so a second API call added latency without adding quality.
1. Acknowledgement of the Customer's Situation Did they show they understood the customer before doing anything else?
- 1: Ignores the concern, jumps straight to defence or pitch
- 2: Vague "I understand" with no specific reference to the problem
- 3: Acknowledges briefly but moves on too quickly
- 4: Names the specific situation clearly before responding
- 5: Names the situation, validates the feeling, and pauses before solving
2. Tone and Politeness How did the language feel throughout the entire response?
- 1: Defensive, dismissive, or passive-aggressive
- 2: Overly formal or cold, creates distance
- 3: Professional but neutral, no warmth
- 4: Warm and respectful throughout
- 5: Genuinely courteous, makes the customer feel valued as a person
3. Clarity of Communication Could the customer easily understand what was being said and what happens next?
- 1: Confusing, rambling, or contradictory
- 2: Understandable but poorly structured
- 3: Clear enough but could be more concise
- 4: Clear and well structured
- 5: Concise, direct, leaves no ambiguity about next steps
4. Resolution Effectiveness Did they actually address the customer's real problem with a practical solution?
- 1: Does not address the customer's real problem or ignores critical constraints
- 2: Acknowledges the need but proposes a solution that is largely impractical
- 3: Partially addresses the goal but overlooks important constraints
- 4: Provides a practical solution with only minor omissions
- 5: Provides a realistic, actionable solution that fully addresses goal, constraints, and next steps
These sit outside the scored dimensions and are evaluated independently. A single Fail is flagged prominently regardless of the overall score. A polished, warm response that contains a false promise is more dangerous than a clumsy one, and the separation keeps the scoring rigorous.
No Pressure Language Fails if the response contains pushy, manipulative, or urgency-manufacturing language. Examples: "You need to decide now", "This offer won't last", "Everyone else is buying this"
No Blame or Dismissal Fails if the response implies the customer is wrong, unreasonable, or at fault. Examples: "As I already explained", "You should have read the terms", "That's not our fault"
No False Promises Fails if the response makes a specific promise that is unrealistic or unverifiable. Examples: "I guarantee this today", "You will definitely get a refund", "This will never happen again"
Before writing any Django code, the judge prompt was tested manually in Google AI Studio against three response qualities (poor, mediocre, and good) for the same customer scenario.
Test scenario: A customer calls to complain that their order arrived three days late and one item was missing. They are frustrated and saying they are considering shopping elsewhere.
| Response Quality | Score | Key Finding |
|---|---|---|
| Poor: defensive, blaming customer | 6/20 | Blame/Dismissal FAIL triggered correctly, feedback quoted exact phrase used |
| Mediocre: polite but vague | 15/20 | Correctly separated Clarity (5) from Acknowledgement (3) |
| Good: empathetic, concrete next steps | 20/20 | Full marks with specific positive feedback |
Score separation across the full range (6→15→20) with no ceiling compression confirmed the prompt was ready for integration.
The judge is a language model evaluating a language model response. This was chosen because at prototype stage there is insufficient user volume to validate a human-scored rubric. At scale, a hybrid approach would be appropriate: the LLM scores automatically, and human reviewers validate a sample to check consistency.
Known weakness: LLM judges tend to reward confident, well-structured text even when content is poor. This is mitigated by the anti-gaming instruction in the judge prompt ("judge substance and behaviour, not writing quality") and by using behavioural pass/fail checks alongside scaled scores.
Version 1 evaluates a single response to a scenario rather than a full back-and-forth conversation. This reflects how professional sales training works. Larry Robinson's 1987 Harvard Business Review article "Role Playing as a Sales Training Tool" established the principle of targeting one specific moment in a deal rather than simulating a full call. The industry term is skill isolation: a rep drills a single pricing objection, a cold-call opener, or a discovery question set until the response becomes natural. Narrow focus makes feedback more specific and actionable.
Modern AI sales training tools (PitchMonster, Hyperbound, Kendo) use the same principle with structured scenarios and scorecards. Multi-turn conversation would add realism and is a version 2 feature.
Responses are typed rather than spoken. Writing out what you would say on a call forces more deliberate word choice than speaking off the cuff. The salesperson must think about how they acknowledge the customer, what solution they propose, and how they structure their response, which is what the rubric evaluates.
Speech-to-text was explored using the Web Speech API but proved unreliable across browsers and devices. A production version would use a server-side transcription service (Google Cloud Speech-to-Text or similar). The rubric evaluates content and behaviour rather than delivery, so the typed format captures the substance that matters for skill development.
The browser's Web Speech API reads scenarios in a neutral voice regardless of customer type. The scenario generator prompt compensates by writing angry scenarios in short clipped sentences with capitalised key words, confused scenarios in rambling self-contradicting language, and price-sensitive scenarios in a calm but firm register. The written style conveys the emotion even when the voice cannot.
Version 1 has no user accounts. All sessions are stored in a single shared database. Authentication would be needed before any real deployment.
Backend
- Python 3.11
- Django 5.2
- Google Gemini API (gemini-3.6-flash)
- python-dotenv
Frontend
- HTML5 / CSS3
- Vanilla JavaScript
- Web Speech API for text-to-speech scenario delivery
Database
- SQLite (development)
SalesSession
id, scenario_type, created_at
└── Scenario (ForeignKey)
id, session, text, created_at
└── Response (ForeignKey, supports multiple retry attempts)
id, scenario, text, attempt_number, created_at
└── Score (OneToOneField)
id, response
acknowledgement_score, acknowledgement_feedback
tone_score, tone_feedback
clarity_score, clarity_feedback
solution_score, solution_feedback
pressure_result, pressure_feedback
blame_result, blame_feedback
promises_result, promises_feedback
overall_summary, total_score
coaching_tip
created_at
The Response model uses ForeignKey rather than OneToOneField so one scenario can have multiple retry attempts. Each attempt gets its own Score so improvement across attempts is trackable.
salescoach/
├── manage.py
├── requirements.txt
├── .env
├── .env.example
├── .gitignore
├── README.md
├── coaching/
│ ├── models.py
│ ├── views.py
│ ├── urls.py
│ ├── admin.py
│ ├── prompts.py
│ └── templates/
│ └── coaching/
│ ├── base.html
│ ├── home.html
│ ├── session.html
│ ├── scorecard.html
│ ├── progress.html
│ └── guide.html
└── salescoach/
├── settings.py
├── urls.py
└── wsgi.py
# Clone the repository
git clone https://github.com/yourusername/salescoach.git
cd salescoach
# Create and activate virtual environment
python -m venv venv
venv\Scripts\activate # Windows
source venv/bin/activate # Mac/Linux
# Install dependencies
pip install -r requirements.txt
# Create .env file
cp .env.example .env
# Add your Gemini API key to .env
# Run migrations
python manage.py migrate
# Start the server
python manage.py runserverdjango>=5.2
google-generativeai
python-dotenv
Rubric design: defining evaluation criteria with specific level descriptions that produce consistent LLM judge results. Vague criteria like "was the response polite?" are insufficient. Observable behaviours at each level are essential.
AI evaluation architecture: structuring a judge prompt that resists gaming, produces specific actionable feedback, and separates integrity checks from scored dimensions. Designing evaluation before building applies to any AI product role.
Prompt engineering: calibrating prompts against known examples before integration. Temperature as a product decision. Anti-gaming instructions and their limitations.
Agent consolidation: the coaching tip was originally a separate third agent and was merged into the judge prompt to reduce latency. The judge already has all the context needed to generate an actionable tip, so a second API call added response time without improving quality. Knowing when to consolidate agents is as important as knowing when to separate them.
Prototype scoping: knowing what to build now and what to defer. Single-turn evaluation is aligned with established sales training methodology, where skill isolation through focused drills is how professional programmes work. Speech-to-text was explored and removed when browser support proved unreliable.
Known limitations as product thinking: articulating where your evaluation method fails, what you would do differently at scale, and what version 2 would look like.