Casual Chat, Serious Contract

A chat window naturally feels like a light, conversational channel. It’s great for quick questions or simple requests. In this case, though, the task itself is quite heavy from the user’s point of view: cancelling a contract that can affect future billing and service status.

That combination can create a gap:

• The chat UI feels casual and low-stakes.
• The task is financially and emotionally high-stakes.
• Compared to a traditional form, it’s harder to see a solid record of what was processed.

In this flow:

• There was no clear summary of which contract was cancelled and how.
• There was no follow-up email or visible record in a “My Page” section.

So even though the interaction itself was smooth, it was difficult to leave with a strong sense of:

Yes, this is officially done and I have a reliable record.

Chat can still be a great channel here. The experience just needs a bit more visible certainty at the end.

For example, the flow could:

• Show a clear summary in the chat at the end:
• Contract number
• Address
• Plan name
• Cancellation date
• Any important conditions
• Send an automatic Cancellation complete email based on that summary.
• Explicitly say in the email body:

This email is your confirmation and proof of cancellation.

• Optionally, reflect the status in the user’s account and mention when it will be visible there.

This kind of small addition lets the chat remain friendly and lightweight, while still giving the user the feeling that an official, traceable action has been completed.

To cancel, the user was asked to enter:

• Application number
• Full name
• Address
• Phone number
• Plan selection

In practice, the application number should already be a key that links to all the other information. In this flow, though, it behaved more like just one more field among many.

From the user’s side, that means:

• Re-typing information they have already provided once.
• Having to remember details like the plan name, which may not be visible anywhere.
• Holding the anxiety of:

If I choose the wrong option here, will the wrong contract get cancelled, or will it not be cancelled at all?

The important parts here are identity verification and accurate contract matching. Those don’t have to rely on the user re-entering everything.

A lighter flow for the user could look like this:

1. Ask for only what is needed to look up the contract (for example, application number + phone number).
2. Use that to fetch the contract on the backend, and show the full contract summary in the chat:

We found this contract: Plan: X Address: … Cancellation date: …

3. Ask for a simple confirmation:

Do you want to cancel this contract?

with a clear Yes, cancel this action. 4. Send an automatic email confirmation and/or update the user’s account view.

This way:

• The system takes care of using existing data.
• The user’s input load is much lower.
• The operator can focus more on edge cases and support, rather than manual verification.

The flow still protects the company and ensures correctness, but it doesn’t rely on the user doing repetitive, error-prone work inside a tiny chat window.