How Should Companion Chat Products Recognize When a User Wants to Stop?
A companion chat product should treat a clear stop message as an instruction, recognize when the requested activity is complete, and let the user pause without having to explain why. When the exchange is over, it should close briefly and leave the next move to the user. A practical way to design this is to sort signals by how clear they are, give explicit requests priority, and avoid guessing from a user’s mood or silence.
Start with the user’s words, not a theory about their mood
Messages such as “stop,” “I’m done,” “that’s enough,” “goodbye,” or “let’s leave it here” are direct evidence that the user wants the exchange to end. Build these phrases, along with natural variations, into the product’s stop handling. Treat them as control instructions across the conversation, including during a creative activity or while the system is asking a question.
This follows established conversation-design guidance. Google recommends honoring expressions such as “I’m done” and “forget it,” and says not to second-guess someone who wants to leave an unfinished task when little progress would be lost. Amazon Lex similarly defines a stop intent for phrases that indicate the user wants to end an interaction. (Google’s guidance on conversation endings; Amazon Lex’s built-in stop intent)
The product’s response should acknowledge the instruction once, then end the turn. For example: “Understood. We can stop here.” Do not follow that acknowledgment with another question, an invitation to keep talking, or a request to justify the decision. A stop command should not become a small negotiation in which the user has to repeat themselves.
Treat completion as a natural closing point
A user may finish without saying “stop.” They might ask for a short story and receive it, choose an idea for a weekend activity, or finish revising a message. Once the requested output is delivered and there is no unresolved part of the task, the system can close with a short statement such as “Here’s the finished version” or “That gives you a plan for Saturday.” It need not automatically append “What else would you like to do?”
This is a design inference from guidance to keep conversational responses brief, relevant, and focused on the task. Amazon’s conversation-design checklist recommends minimal steps and relevant messages, and advises against interrupting an experience with an unrelated offer. Applied to companion chat, that suggests making follow-up questions conditional on a real next step, rather than attaching one to every completed answer. (Amazon Alexa conversation design principles)
There are exceptions. If the request has several parts, the product should complete the promised parts or clearly state what remains. If a user asks for a draft and a revision, returning only the draft is not a completed task. But once the agreed scope is satisfied, an open-ended prompt can make a finished interaction feel unfinished. A concise closing keeps the system from quietly expanding the user’s task.
Make pausing easy to express and easy to resume
Pausing is different from ending. “Let’s pause,” “I’ll come back to this,” “one moment,” or “save this for later” may signal that the user wants a break while preserving the work. Where the product supports conversation history or saved drafts, it can confirm what will remain available in plain language. If it cannot preserve the current state, it should say so before the user leaves when that limitation matters.
Keep the pause user-controlled. Do not require an explanation or suggest a reason for the break. If the product has a visible pause or close control, label it clearly and give it a predictable result. W3C guidance on user control says that changes of context should be initiated by the user or have a mechanism to turn them off; that principle supports clear controls and predictable behavior around transitions. (W3C guidance on Change on Request)
The product should also distinguish a pause from an explicit stop using the words and actions available in the interface. A pause can preserve a draft or place in a task if the feature supports that. A stop should end the current interaction. Do not claim that a conversation is saved unless it actually is, and do not treat leaving the app or going quiet as a request to send more messages.
Use a clear order for ambiguous and explicit signals
A useful signal hierarchy for implementation is:
Explicit stop or goodbye: end the exchange promptly.
Explicit pause or save request: pause or save if supported, then confirm the result briefly.
Completed request: provide the requested result and close without requiring another turn.
Unclear message: ask one short clarifying question only when the ambiguity blocks the task.
Silence: wait or end the active session according to the product’s normal behavior; do not infer an emotional state.
This ordering is a practical design proposal, not a published measurement or universal classifier. Its purpose is to keep direct instructions from being overridden by softer assumptions. For instance, “That’s enough” should take precedence over a system’s prediction that a related suggestion might be welcome. A question such as “Do you mean stop here, or save this for later?” is suitable only when the user’s wording genuinely leaves those outcomes unclear.
If a product supports a consequential action or risks losing significant work, a confirmation may be appropriate to protect that work. Keep the confirmation specific and easy to answer: “Stop now and discard this draft?” For ordinary conversation where little progress would be lost, repeated confirmation creates needless friction. Google’s guidance makes the same distinction: don’t double-check an exit unless significant progress will be lost. (Google’s guidance on conversation endings)
Keep the closing response short and complete
A closing message should do one job: make clear that the system has understood the user and that the interaction has ended or paused. Suitable examples include:
Stop: “Okay. We’ll stop here.”
Completed creative task: “Here’s the revised poem.”
Pause with saved work: “Paused. Your draft is saved in this chat.”
Pause without a save feature: “Okay. You can return to this chat later, but I can’t save a separate draft.”
Use only statements that match the product’s actual behavior. Avoid an emotional appeal, a guilt-laden line, or a new question. A closing can be warm without asking the user to reassure the system or continue the interaction. The design goal is a clear ending the user can trust.
Test the boundary cases, not only the obvious commands
Review short conversation examples across ordinary use: a direct stop during a story, “that’s enough” after a recommendation, a finished writing task, a request to pause midway, and an ambiguous “maybe later.” Check that each case leads to the intended behavior and that a follow-up question does not appear after a clear stop or completed task.
Also check for false positives. “Stop using that phrase and try another” contains the word “stop” but is an instruction within the task, not necessarily a request to end the chat. Interpret words in context, while keeping a dedicated stop control available when the system gets the language wrong. Amazon’s documentation describes a built-in stop intent for common stop phrases; a companion chat product can use the same basic idea while tailoring recognition to its text or voice interface. (Amazon Lex’s built-in stop intent)
Track practical failures such as a stop request followed by another question, a completed task that triggers an irrelevant prompt, or a pause that loses work despite implying it was saved. These are observable behavior checks, not judgments about what a user feels. They help teams improve the interaction without trying to diagnose users from their wording.
A simple rule for a respectful ending
When the user clearly ends the exchange, stop. When the agreed task is complete, close briefly. When the user asks to pause, preserve their control and explain the available save behavior. Ask a follow-up only when it is needed to finish the request or resolve a real ambiguity. This gives companion chat products a concrete way to recognize endings while leaving ordinary choices, timing, and continuation with the user.