
AI-assisted service support
Building a fair comparison for AI chat
A generic chatbot had already been selected. I used Lovable to build two working routes for the same service task, holding the rules and outcome constant so chat could be compared fairly with direct self-service. Both were research prototypes; the chat route was scripted and did not use a live language model.
Role
Period
Team
Scope
Guided service flow

Scripted chat route

Working Lovable prototypes · Two ways into the same task: a direct service page and a scripted chat route.
The situation
A chatbot was chosen before the problem was understood
The programme began with a generic chat route already live and an ambition to expand AI-assisted support. The risk was treating chat as the answer before defining which problems it should solve.
beyond validating the chosen solution.
An eight-participant study showed that finding information and reaching a person were different support needs. Simple, repeatable tasks called for a direct, low-effort route; blocked or sensitive journeys could require reassurance and human accountability.
I turned the team’s evidence into six principles for AI-assisted support and a set of hypotheses. One required a working comparison: for a bounded information-recovery task, would chat add value over direct self-service?
Decision
Chat had to be compared with direct self-service on equal terms
I used Lovable to turn that hypothesis into two working prototypes. The guided route checked the vehicle record, asked only the next verifiable question, handled multiple records, offered fallback verification and escalated when self-service could not continue. The scripted chat route presented the same core journey one message at a time.
For the matched comparison, both routes used the same task, issue-date verification and result. Holding the service logic and outcome constant meant future research could assess the interaction model rather than differences in capability or content.
The work deliberately separated AI-assisted prototyping from an AI-powered product. The chat route was scripted. A later hypothesis would test AI as an interpreter of free text, while service rules retained control of verification and the returned outcome. That third variant remained a proposed experiment.
Guided service flow
Registration → verification → result


The working logic also covered multiple records, alternative verification and escalation.
Scripted chat route
Request → same verification → same result


A scripted version of the same task. No free-text interpretation or live LLM.
Working Lovable prototypes · Working comparison prepared for research. No interaction preference had been established at handover.
Outcome
The roadmap widened beyond a generic chatbot
The work widened the proposed roadmap from a generic chatbot to support defined by what it needed to know, what it could access and what it could help users resolve.
Senior leadership responded positively to the playback.
The prototypes were requested at handover and created a concrete foundation for subsequent research. They had not been user tested or taken into delivery.
View next case study