A conversation that sounds natural can make a computer feel remarkably capable. Google’s May introduction of LaMDA demonstrates why that idea attracts attention. For a business considering conversational software, however, the first useful distinction is between keeping a conversation going and giving an answer someone can safely act on. The customer asking about an order needs the second, even if the first makes the demonstration memorable.
Read the announcement as research
Google describes LaMDA as conversation technology developed for open-ended dialogue and discusses concerns including bias and misleading information. The announcement is a research development, not a release of a general-purpose assistant that a retailer can immediately connect to every part of its business. That boundary matters when turning an interesting demonstration into a product proposal.
The research raises worthwhile design questions. What information should a business assistant rely on? Which actions should it be allowed to take? How should it recognise that a person needs a colleague rather than another fluent sentence?
Begin with a narrow service moment
Imagine a customer asking whether a replacement part fits a product. A useful answer depends on the model, the part specification and the source of the compatibility information. A pleasant conversation without those facts can leave the customer more confident and less well informed. That is a worse outcome than clearly acknowledging that a detail needs checking.
A first project might therefore focus on finding and presenting approved information, with a clear route to a person for uncertain cases. The point is to solve one recognisable service problem before deciding that the assistant should handle every question the business receives.
Separate an explanation from an action
Answering a general delivery question is different from changing an address or issuing a refund. The latter actions require identity, permissions and business rules. A conversational interface should not make those requirements disappear merely because it can express the request in ordinary language.
Map the task in the same detail as a conventional interface. Identify the information needed, the confirmation the customer should see and the record the team must retain. If the operation cannot be completed, the conversation should leave an honest account of what did and did not happen.
Design the handover before the personality
A human colleague should receive enough context to continue the task without asking the customer to repeat everything. Decide which part of the conversation is relevant and what information should remain private. The customer should know when the responsibility has moved to a person and how to expect the next response.
A business assistant ultimately needs to help someone reach a dependable answer or complete a task. Fluent dialogue may make that route more comfortable. It must also leave room for missing information, a clear limit on authority and a handover to the person who can resolve the question.
