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

Sole Product Designer

Sole Product Designer

Period

2026

2026

Team

Product Manager, Content Designers

Product Manager, Content Designers

Scope

AI-assisted customer support

AI-assisted customer support

Guided service flow

Guided Lovable prototype starting a lost parking fine reference recovery journey with vehicle registration.

Scripted chat route

Scripted chat prototype starting the same lost parking fine reference recovery task.

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.

I pushed to widen discovery

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

Guided prototype asking for the PCN issue date after matching the vehicle record.
Guided prototype returning the verified parking fine reference and deadline.

The working logic also covered multiple records, alternative verification and escalation.

Scripted chat route

Request → same verification → same result

Scripted chat prototype collecting the same vehicle registration and issue date.
Scripted chat prototype returning the same verified parking fine reference and deadline.

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