RASHMI
The Anatomy of a Misleading Feature Request
This was a feature request that I did not build.
80%
reduction in internal message leaks
0
engineering effort for a mis-built feature (avoided)
NPS
Improved Net Promotor Score of the product
CONTEXT
Three actors. One tangled communication.
The platform is a B2B ticketing portal used by Managed Service Providers (MSPs). Customers raise tickets via email; these become threaded conversations inside the portal. Every message — triggered email notifications to all parties.
THE REQUEST
What stakeholders asked for
"We need the ability to edit message history before forwarding conversations to clients, as internal discussions and notes are sometimes included in outgoing communication."
Role
Product Designer - End-to-end design, owned research, product design
Team
2 Engineers, 1 PM
UNDERSTANDING THE PROBLEM
The leak happens by design
I mapped out a real conversation flow.
Since the notification mails are triggered from the MSP inbox, when managers see the mail notification, they reply to it - assuming that it goes to the technician only.
However, it goes to the client portal as well. However, an email notification is not triggered.
This becomes a part of the history in the email histories of notifications.
So the subsequent message, intended for the client, carries with it the internal conversation in its history.
MESSAGE 1
Client raises a request
Client raises a request
This becomes a ticket - visible on Portal - Client side as well as MSP side
An email notification is triggered from the inbox integration
Email notification reaches technician & manager (this depends on settings)
EXPECTED BEHAVIOR
Manger makes internal communication via notes
Ideally, MSP manager is expected to open the portal and go to the Notes tab, tag the technician and make an internal communication
MESSAGE 2
Manger replies to the email notification
This email is from the inbox integration (support@msp.com)
This appears like he is making an internal communication
However, this reaches the client portal
But no email notification is triggered to the client
Client does not check the portal (mail is the preferred medium of communication)
MESSAGE 3
Technician replies to the Client
This reply (made from MSP side of Portal) reaches the client portal and triggers a mail notification for the client
The mail - with a quoted text - contains the internal communication between Manager & Technician
PROBLEM REFRAME
How might we give MSP teams the ability to communicate internally within a ticket thread — without those communications reaching the client?
FOUR APPROACHES
One winner
I explored four directions, evaluating each against simplicity, scalability, tech effort, and whether it was preventive or merely reactive.
QUESTION 1
Is Edit History needed ?
NO LONGER A CHAT INTERFACE
This is will change the chat interface to mail interface. This will mess up the lifeline of the product - for solving an error scenario.
REACHES CLIENT PORTAL
This solution aims at fixing the leakage as a “quoted text” not as a message that has reached the client portal
REACTIVE APPROACH
This is a reactive approach. An MSP technician is already busy out doing umpteen tasks & context switching. Is there a way to reduce his task load ?
WHY IT WORKS ?
Straight forward approach with better control to the user.
OPTION 2
Reply from a particular message
NEED TO PAIR WITH EDIT HISTORY
NO LONGER A CHAT INTERFACE
REACHES CLIENT PORTAL
REACTIVE
SCALE - CANNOT BE SCALED
If there are multiple such messages interrupting the client-MSP communication, this idea cannot scale. Message 4 will have 2 & 1 skipping 3 (internal communication) but Message 6 is internal, Message 7 will have 5,4,3,2 & 1 - where 3 gets in the way.
OPTION 3
Change the functionality
HOW TO ARREST LEAKAGE ?
The reply to the mail notification reached the client portal - what if we arrest this instead and ensure that only mail box integrated mail ID appears in the client portal.
PREVENTIVE APPROACH
The only preventive approach of all the possible options. We are removing the onus from the technician.
TRADE-OFF
This needs to assumption that all such messages are intended for the internal communication & not the client
OPTION 4
Visibility Toggle
VISIBILITY TOGGLE
Individual messages can be hidden.
STILL REACTIVE
The message reached the client portal.
ONUS IS ON TECHNICIAN
The onus is on the technician to make the message hidden. And the mail functionality will be such that this message will not appear in the email history as quoted text.
TECHNICAL TRADE-OFF
Our parser was 80% efficient. There still exists a probability of message leakage.
The winner
VISIBILITY TOGGLE
We also discussed if a confirmation modal was needed for the operation to be performed. We eliminated it and made the best use of UX copy.
Reflections
DECIDING WHAT NOT TO BUILD
To stop and think through and validate the problem statement. Is this the best solution possible. To play the devil’s advocate.
PULLING SIGNAL FROM NOISE
There were so many options presented by the stakeholders - to think through the rationales and trade-offs.
SIMPLEST SOLUTION REQUIRES MAMMOTH EFFORTS
The final solution looks like just another button but we had to invest Herculean efforts to get there.
CHOOSING LESSER DEVIL
The solution did not completely solve the issue, had its trade-offs but was the best option.
IF I ASK MY CUSTOMERS WHAT THEY WANTED, THEY’D SAY FASTER HORSES - HENRY FORD
Solve the disease - not the symptom
PORTAL INTERFACE
EXISTING REPLY WIDGET
CLIENT ASK - SHOW & EDIT QUOTED TEXT
CLIENT ASK - SHOW & EDIT QUOTED TEXT
RASHMI
The Anatomy of a Misleading Feature Request
This was a feature request that I did not build.
80%
reduction in internal message leaks
0
engineering effort for a mis-built feature (avoided)
NPS
Improved Net Promotor Score of the product
CONTEXT
Three actors. One tangled communication.
The platform is a B2B ticketing portal used by Managed Service Providers (MSPs). Customers raise tickets via email; these become threaded conversations inside the portal. Every message — triggered email notifications to all parties.
THE REQUEST
What stakeholders asked for
"We need the ability to edit message history before forwarding conversations to clients, as internal discussions and notes are sometimes included in outgoing communication."
Role
Product Designer - End-to-end design, owned research, product design
Team
2 Engineers, 1 PM
UNDERSTANDING THE PROBLEM
The leak happens by design
I mapped out a real conversation flow.
Since the notification mails are triggered from the MSP inbox, when managers see the mail notification, they reply to it - assuming that it goes to the technician only.
However, it goes to the client portal as well. However, an email notification is not triggered.
This becomes a part of the history in the email histories of notifications.
So the subsequent message, intended for the client, carries with it the internal conversation in its history.
MESSAGE 1
Client raises a request
Client raises a request
This becomes a ticket - visible on Portal - Client side as well as MSP side
An email notification is triggered from the inbox integration
Email notification reaches technician & manager (this depends on settings)
EXPECTED BEHAVIOR
Manger makes internal communication via notes
Ideally, MSP manager is expected to open the portal and go to the Notes tab, tag the technician and make an internal communication
MESSAGE 2
Manger replies to the email notification
This email is from the inbox integration (support@msp.com)
This appears like he is making an internal communication
However, this reaches the client portal
But no email notification is triggered to the client
Client does not check the portal (mail is the preferred medium of communication)
MESSAGE 3
Technician replies to the Client
This reply (made from MSP side of Portal) reaches the client portal and triggers a mail notification for the client
The mail - with a quoted text - contains the internal communication between Manager & Technician
PROBLEM REFRAME
The real question
How might we give MSP teams the ability to communicate internally within a ticket thread — without those communications reaching the client?
FOUR APPROACHES
One winner
I explored four directions, evaluating each against simplicity, scalability, tech effort, and whether it was preventive or merely reactive.
QUESTION 1
Is Edit History needed ?
NO LONGER A CHAT INTERFACE
This is will change the chat interface to mail interface. This will mess up the lifeline of the product - for solving an error scenario.
REACHES CLIENT PORTAL
This solution aims at fixing the leakage as a “quoted text” not as a message that has reached the client portal
REACTIVE APPROACH
This is a reactive approach. An MSP technician is already busy out doing umpteen tasks & context switching. Is there a way to reduce his task load ?
WHY IT WORKS ?
Straight forward approach with better control to the user.
OPTION 2
Reply from a particular message
NEED TO PAIR WITH EDIT HISTORY
NO LONGER A CHAT INTERFACE
REACHES CLIENT PORTAL
REACTIVE
SCALE - CANNOT BE SCALED
If there are multiple such messages interrupting the client-MSP communication, this idea cannot scale. Message 4 will have 2 & 1 skipping 3 (internal communication) but Message 6 is internal, Message 7 will have 5,4,3,2 & 1 - where 3 gets in the way.
OPTION 3
Change the functionality
HOW TO ARREST LEAKAGE ?
The reply to the mail notification reached the client portal - what if we arrest this instead and ensure that only mail box integrated mail ID appears in the client portal.
PREVENTIVE APPROACH
The only preventive approach of all the possible options. We are removing the onus from the technician.
TRADE-OFF
This needs to assumption that all such messages are intended for the internal communication & not the client
OPTION 4
Visibility Toggle
VISIBILITY TOGGLE
Individual messages can be hidden.
STILL REACTIVE
The message reached the client portal.
ONUS IS ON TECHNICIAN
The onus is on the technician to make the message hidden. And the mail functionality will be such that this message will not appear in the email history as quoted text.
TECHNICAL TRADE-OFF
Our parser was 80% efficient. There still exists a probability of message leakage.
The winner
VISIBILITY TOGGLE
We also discussed if a confirmation modal was needed for the operation to be performed. We eliminated it and made the best use of UX copy.
Reflections
DECIDING WHAT NOT TO BUILD
To stop and think through and validate the problem statement. Is this the best solution possible. To play the devil’s advocate.
PULLING SIGNAL FROM NOISE
There were so many options presented by the stakeholders - to think through the rationales and trade-offs.
SIMPLEST SOLUTION REQUIRES MAMMOTH EFFORTS
The final solution looks like just another button but we had to invest Herculean efforts to get there.
CHOOSING LESSER DEVIL
The solution did not completely solve the issue, had its trade-offs but was the best option.
IF I ASK MY CUSTOMERS WHAT THEY WANTED, THEY’D SAY FASTER HORSES - HENRY FORD
Solve the disease - not the symptom
PORTAL INTERFACE
EXISTING REPLY WIDGET
CLIENT ASK - SHOW & EDIT QUOTED TEXT
CLIENT ASK - SHOW & EDIT QUOTED TEXT