Redesigning the cancellation flow
How an improvement to a critical step of the journey helped reduce operational errors, decrease rework and bring more traceability to the process.
Project rebuilt for portfolio purposes with anonymized information and reconstructed visual elements.
Overview
In a document request and management product, cancellation was a sensitive step of the journey. Done without enough context, it could waste resources, create operational rework and increase dependency on the Customer Success team to manually intervene in requests.
Context
The project started from the perception that part of the operational tickets received by the CS team was related to errors in document requests, cancellation requests and doubts about when to cancel or how to fix an already open request. In practice, this indicated the current flow was not helping users make the right decision at the moment of cancellation.
The problem
Document cancellation was handled with little guidance. In many cases, users canceled a request without full clarity about the consequences of the action, or turned to the internal team to mediate a decision that should have been simpler within the product experience itself.
- more operational tickets for CS;
- potentially mistaken cancellations;
- loss of visibility into the most recurring reasons behind these actions.
Project goals
- reduce improper cancellations;
- decrease operational rework;
- reduce CS team dependency on simple requests;
- create traceability for cancellation reasons;
- improve governance and process analysis.
My role
I worked on investigating the problem, aligning with stakeholders, understanding the current journey and designing the interface solution to better structure decision-making at the moment of cancellation. My focus was to turn a critical, previously under-contextualized action into a safer, more understandable flow, useful for both users and operations.
Discovery and process
To better understand the problem, I considered signals from operations and from the user experience, mainly the volume of tickets related to request and cancellation errors, the need for manual CS intervention, the lack of standardization in cancellation reasons and the absence of structured data to understand the root cause of these occurrences.
- mapping the current journey to understand doubts, impulsive decisions and operational dependency;
- aligning with partner areas to understand impact on support, operations and governance;
- structuring an experience that provided more context before confirming a cancellation.
Project process
Solution
The proposed solution structured cancellation as a guided flow, not just an isolated action. The main improvements were a required cancellation reason, contextual confirmation before completing the action, a complementary observation field, more traceability and a better foundation for continuous product improvement.
Flow screens
Proposed journey
Results and impact
- 28% reduction in tickets related to cancellation and request correction;
- 22% drop in cancellation requests handled manually by CS;
- 41% increase in the traceability of cancellation reasons, with more structured data for analysis;
- less operational rework in request flows with origin errors;
- greater visibility into misuse patterns and recurring doubts in the journey.
With the new approach, cancellation stopped being just an operational action and started working as a point of control and learning within the journey. Structuring the reason, the contextual confirmation and the improved traceability helped reduce related tickets, decrease manual interventions and bring more clarity about the most recurring causes behind cancellations.
Learnings
This project reinforced for me that seemingly simple operational flows can have a direct impact on cost, efficiency and user experience. It also showed how UX decisions can go beyond usability, helping reduce errors, improve governance and generate intelligence for the product.
Note: as this is an older, confidential project, this case was rebuilt with anonymized information and metrics representative of the project context, preserving the product reasoning and the nature of the solution.