Nichole Endline

Hello!

We were also having some operational struggles as a result of customers using the ‘mark as solved’ button (primarily due to our desire to include solution notes in tickets before setting to ‘solved'). When we implemented something similar to what you describe above, we got negative feedback from customers, because the trigger design gave the appearance to customers as if the ‘mark as solved’ button did not work. Given the frustration it generated, we abandoned this approach quite quickly.

So, we changed course: instead of preventing the action from happening, we designed triggers to detect when it DID happen. By doing this, we avoided creating any frustration and were able to add a special tag to have these tickets filter into a specific view. From this view, our engineers/managers were able to review tickets marked as solved by customers and add a solution note before the status moved to a ‘closed’ , uneditable state. We also had the added bonus of improved reporting about customers marking their tickets as solved since we were proactively identifying them via this new flow.

Food for thought :)