Reducing Sales Load & Improving Student Self‑Serve 0→1
B2C
0→1 Product
Conversation Design
ⓘ This project is under NDA. I'd be happy to share the full story during an interview!
Problem
Sales teams were overwhelmed with repetitive questions about properties, pricing, and eligibility - information already available on the platform but not easily accessible conversationally.
Solution:
AI-powered chat using natural language understanding to help student questions by intent and provide confident, sourced answers.
Impact:
Response time: 4–6 hours → <1 minute
Reduction in repetitive sales queries
My Role
Product Designer - I led research, defined solution strategy, designed conversation flows, and collaborated with Product & Engineering.
Constraints
Tight delivery window aligned with peak booking season
Balancing existing and new design system components
Timeline:
0→1 MVP delivered in 4 weeks during booking season.
PROBLEM
The Problem
Amber helps international students find and book accommodation globally. As demand grew, sales teams became overwhelmed 65% of their calls repeated the same questions despite this information being available on property pages.
Discovery Insights (from 6 sales interviews, 50+ transcripts, 12+ call recording observations):
Students needed reassurance, not more documentation
They asked "Does this have in a property?" even when amenities were listed - seeking confirmation, not information.Sales time was misallocated
20% spent on early-stage, low-intent queries when they should focus on students ready to book.The core issue was accessibility and trust
Information existed but wasn't surfaced conversationally when students needed it.
RESEARCH
Design Strategy:
Given the business risk of providing incorrect information (pricing, availability, eligibility), I designed for precision and trust rather than trying to answer everything.
Strategic Principles
01
Answer only what we can answer with high confidence
02
Be explicit when we can't answer - no guessing
03
Maintain human fallback for complex questions
04
Design for trust, Focus on reliability and clarity
What We Included
What We Excluded (And Why)
Property-specific questions (amenities, pricing, availability)
Open conversational chat (too risky)
Process questions (documents, eligibility, next steps)
Personalized recommendations of other properties (insufficient data quality)
Clear "I don't know" responses
Automated bookings (compliance risk)
Why This Mattered: These boundaries maintained sales trust and avoided scenarios where wrong information could cost bookings or damage reputation.
STAKEHOLDER ALIGNMENT
Sales Team Challenge:
"This will give wrong answers and damage trust."
My Approach:
Involved sales in early design reviews to identify risky edge cases. Designed explicit escalation paths so the system complemented their expertise. Built transparency into every response.
Engineering:
Worked closely on intent classification logic, confidence thresholds, and fallback paths. Made design adjustments when technical constraints required it and I deliver a technically sound solution that met user needs.
This avoided last-minute redesigns and kept the MVP realistic.
Why This Architecture?
I designed three paths to match how students actually ask questions. Simple questions get instant answers. Vague questions get clarification. Complex questions go to sales.
This protected trust one wrong answer about pricing could cost a booking. By being honest about what the system could and couldn't handle, both students and sales trusted it. Students got speed. Sales got meaningful conversations.
DESIGN
Solution: Intent-Based Conversation Design
The system routes questions based on intent classification, allowing students to ask naturally while maintaining accuracy. Three Response Paths
Path 1: Confident Answer
When it happens: Clear intent + verified data + high confidence
Students needed reassurance before engaging deeply with the platform.
Path 2: Clarification Needed
When it happens: Question is vague, indirect, or could mean multiple things
Path 3: Escalate to Sales
When it happens: Out of scope / insufficient data / low confidence
Outcome
Response time: 4-6 hours → <1 minute
For common property and process questions handled by chat.
Reduction in repetitive sales queries
Measured by comparing weekly ticket post launch
Reflections:
Good conversation design isn't about making a system seem intelligent - it's about knowing when to step back.
The most valuable design decision was defining clear boundaries around what the system should answer, and designing transparent, respectful handoffs for everything else. Trust is built through honesty about limitations, not by trying to solve everything.
