Frame
- Translate the AI vision into service scenarios
- Develop the presentation narrative
- Clarify live execution versus simulated screens
DEALER AI AGENT · PRODUCT MANAGEMENT
From an AI demo
to a service tool dealers can trust.
I shaped the demo scenarios and product questions behind an AI assistant for dealer service—connecting what the technology could show with what dealers would need to trust and use it.
Product discovery & proof of concept · 2025Explore the product decisions ↓
PROJECT IMAGE · TO BE ADDEDDealer AI Agent / Venus
Dealer Portal and AI assistant product overview.
01 / OVERVIEW
A new way into
the dealer service workflow.
Dealer Portal supports e-bike service work. The AI exploration asked how a conversational assistant could help dealers find service information, understand issues, and prepare useful summaries within that workflow.
The starting point was a demo for an upcoming brand visit. My work centered on making the scenarios understandable, reviewing what the assistant could actually answer, and connecting the demonstration to a credible product direction.
- Role
- Product planning & demo presentation
- Project
- Dealer AI Agent
- Audience
- Dealers, brand teams & service centers
- Focus
- Use cases, AI response behavior & product discovery
02 / MY ROLE
Connect the demonstration
to a real service need.
Review
- Examine answers against available service data
- Explore system feedback and response guidelines
- Define what a useful report should communicate
Shape
- Prepare dealer discovery questions
- Connect software and marketing priorities
- Explore a phased path toward Dealer Portal AI
My contribution focused on product definition, demo preparation, and evaluation of the experience.
03 / CHALLENGE & STRATEGY
Retrieving information
was only the beginning.
Records without a next step
The assistant could show recent service records, but the limited information made it difficult to explain how the response would help a dealer do their job.
Confident, unsupported answers
When asked to identify unusual patterns or overdue bikes, the assistant produced claims that could not be supported by the available data.
A demo ahead of a product
Positive internal reactions created interest in an early release. Reliability, development cost, and the right entry point still needed to be worked through.
The product question: what can the assistant help a dealer do, using information we can actually verify?
Start with a bounded service task.
The case for AI became more concrete when tied to specific work: looking up records, explaining confusing portal cases, or organizing service information. Broader diagnostic and reporting scenarios needed explicit data and capability boundaries.
04 / DEMO EXPERIENCE
Make the service journey
the story of the demo.
The demo planning connected information lookup with guided support and reporting. Each step needed a clear purpose, an identifiable data source, and an honest explanation of what was live versus illustrative.
- 01
Ask
Use natural language to request service information.
- 02
Retrieve
Bring back the available vehicle and service records.
- 03
Interpret
Explain what the records show and where information is missing.
- 04
Prepare
Explore a useful summary for the next service conversation.
Scenario structure, not a claim that every step was implemented. Recent-record lookup was demonstrated; broader guidance and reporting were part of the exploration.
PROJECT IMAGE · TO BE ADDEDDemo scenario & service-record lookup
Add the demo flow or the Venus service-record response screen here.
Give the report a clear audience.
I explored how individual repair reports could support a shop manager’s monthly overview: service activity, key indicators, error-code trends, and an AI summary. This helped frame what information would be useful beyond a list of records.
PROJECT IMAGE · TO BE ADDEDManager overview & reporting exploration
Add the monthly maintenance overview, error-code trend, or report concept here.
05 / DECISIONS & LEARNINGS
Trust had to be part
of the product scope.
01
Challenge the answer, not just the presentation
I checked the assistant’s explanation of unusual patterns and overdue bikes by asking what sources it relied on. The response exposed unsupported information, making the original question too broad for the data available. The implication was to narrow the scenario to verifiable records before presenting higher-level judgments as a reliable capability.
02
Separate working behavior from the future vision
During demo preparation, I worked through which moments should run live and which should use simulated or prepared screens. This distinction let the presentation communicate the ambition without treating every scenario as a finished feature.
03
Design the waiting experience as well as the answer
I explored specifications for system messages and final responses: when to show tool activity, how to distinguish progress from an answer, and how to keep the language consistent. Clear feedback would help users understand whether the assistant was retrieving information or ready for review.
04
Ask what a dealer would actually use
Dealer discovery preparation focused on repetitive service work, reporting needs, preferred interaction methods, and trust in AI-generated guidance. These were questions to validate, rather than assumptions that a successful demo could settle.
PROJECT IMAGE · TO BE ADDEDResponse review & evidence boundaries
Add an annotated response comparison or AI interaction specification here.
06 / PROJECT OUTCOME
A working demo.
A clearer product question.
The demo received positive reactions from internal marketing stakeholders and became the basis for a wider discussion about service efficiency, trust, cost, and productization.
DEMONSTRATED
Natural-language service-record lookup
IDENTIFIED
Unsupported answers and limits in available data
EXPLORED
Focused service use cases and release options
07 / PRODUCTIZATION
Two entry points.
One longer-term product direction.
Software and marketing brought different priorities to the discussion. Software favored testing assistance in existing service conversations to learn quickly. Marketing proposed opening the demo to a selected group of dealers while continuing to develop the portal experience.
SERVICE-CHANNEL EXPLORATION
Learn from recurring support work
- Explore an MCP-enabled assistant in service conversations
- Start with specific issues such as confusing portal cases
- Use question patterns and feedback to inform priorities
DEALER PORTAL DIRECTION
Bring assistance into the workflow
- Define authenticated dealer access
- Decide when contextual assistance should appear
- Align development readiness with marketing communication
These were development options under discussion. The proposed 60-dealer trial is not presented as a launched pilot, and the final architecture was not established by this exploration.
08 / REFLECTION & NEXT STEPS
A useful AI product needs
more than a convincing answer.
This project sharpened how I evaluate AI experiences: a fluent response is only valuable when it is supported by the available information and helps someone move forward in their work.
My contribution was to connect the demo narrative with these product constraints—surfacing data limitations, questioning the value of the response, and helping frame the path from demonstration to a focused service tool.
TO VALIDATE
Usefulness in real service work
Can dealers act on the answer, or do they still need support to explain it?
TO VALIDATE
Trust and correction
Can users understand the source, recognize missing information, and flag an incorrect answer?
TO VALIDATE
Operational value
Would the experience reduce repetitive questions and cross-time-zone delays at a sustainable cost?
The project established a basis for further validation. Production adoption, time savings, and service-cost reductions are not yet reported here.
← Back to selected work