One Customer, Two Problems: Designing AI for Multiple Service Requests

The customer problem behind this workflow

Single-keyword routing is built for neat menus. Real household and small-business enquiries are rarely so neat. Customers add problems as they remember them, change devices, or switch from troubleshooting to asking about cost.

A system that creates a brand-new case for every sentence can be just as confusing. We need to tell an additional issue from a correction and a genuinely separate request.

How we designed the YITM workflow

YITM’s shared intent approach represents the customer’s purpose and, where supported, multiple concerns. We distinguish “also my phone screen is cracked” from “actually it’s a desktop, not a laptop”. The first adds an issue; the second corrects a fact.

The receptionist should ask only for critical missing details, keep human-readable summaries and invite the customer to review before submitting. In a business context, a website plus booking form and follow-up automation may be one project with several deliverables rather than three unrelated sales requests.

What we built, tested and learned

The Stage 1 acceptance scenarios include adding a cracked phone screen, explicitly starting a separate Wi-Fi enquiry, correcting the device brand and describing both broken email and a slow laptop. These are useful regression cases precisely because they test relationships between messages.

We treat them as engineering scenarios, not evidence of a deployed production accuracy rate. The browser and QuoteMe handover still need verification for the particular live release.

What this could improve for YITM and other businesses

A properly organised summary can make job allocation and quoting easier for the YITM team. It can also help customers check that both problems are included before sending their request.

The same pattern suits trades and local services: an electrician may need to separate a failed light fitting from a new outdoor power point while retaining one customer's conversation.

Local business perspective: Epping, Wollert and Melbourne North

Our own service work in Melbourne’s northern suburbs provides a practical test bed: customers want a clear next step, especially when they cannot describe a technical problem. This article is a first-party YITM workflow example, not a claim that an identical automation suits every local business. A café, clinic or trade service should map its own permissions, customer journey and response expectations before copying the pattern.

Compound intent: a practical example

“My laptop runs slowly, and Mum’s email has stopped working.” A helpful assistant recognises that the laptop performance problem and the email problem need distinct details. It should not infer they share the same cause.

A concise follow-up could be: “I can note both. Is Mum’s email failing on the same laptop or on another device?” One question can resolve an important relationship without making the customer fill out two lengthy forms.

Why reviewable summaries matter

Before submission, display both issues in plain language. The customer can remove one, correct a device or choose to discuss them together. Staff may later schedule separate work; the receptionist does not need to decide that in advance.

For a business enquiry such as a website, booking form and follow-up automation, retain the combined customer objective first. A human can break the work into phases and price it after scoping.