My team and I are having a hard time adapting to Tickets but we want it to work as tracking our conversations that require engineering/technical assistance is quite difficult! Does anyone have any best practices or tips on how they are currently managing back office tickets when working with other teams?
Here’s an example:
Our support team may get an issue that requires us to get assistance from our engineering team. Currently we create a back office ticket, fill out all the necessary fields that our engineering team needs and assigns the ticket to the engineering queue.
When the engineering team needs more information, they’d prefer not to keep the ticket in their queue so they send it back to support, essentially leaving us with double the amount of tickets till we get the information from our clients to send it back to the engineering queue.
Appreciate any insight!
Page 1 / 1
Hi Erin,
That seems like an organisational challenge.
I would recommend your team use a slightly different approach.
You can create a back office ticket and assign it to your engineering team's inbox.
The ticket will be tied to the conversation with your customer.
Engineers can switch off automatic ticket assignment in each of their workspace settings. (Look at the screenshot below).
..and leave the ticket unassigned in their inbox until it is resolved..
To ask for the update from the customer, they can just send a cross-post note, which will be visible in the Conversation with the Customer.
That way, you can keep your ticket count in check and still have full control over communication with the customer.
Please let me know if that was the answer you were looking for
Hello @Erin J
I’d suggest a small improvement here:
When a ticket is assigned to the engineering team, instead of unassigning it, snooze could be used. This way, the back-office ticket would disappear from the list of open tickets in their inbox, wouldn’t clutter the workspace while in a waiting state, and would return after the specified time for a final decision (if the customer hasn’t provided the required information). Moreover, this wouldn’t break the SLA rules, as it would help track the actual time spent by the engineering team on the issue - benefiting both sides. It’s also possible to exclude time spent in the snooze or awaiting on customer states from SLA calculations beforehand.
Similarly, in the other direction, while the engineering team is working on the issue, the conversation remains snoozed, and a cross-post note will wake it as soon as there are updates in the back-office ticket.
P.S. There is still a small issue where snoozing/unsnoozing a back-office ticket or changing its status wakes the conversation unnecessarily. I’ve already created an idea regarding this here
