Set preferred communication channel by customer?

Question

We're beginning to notice two types of customers (coworkers) forming in our help desk when it comes to how they prefer to communicate about their tickets: (1) email and (2) Microsoft Teams. Is there a way to set a preferred communication channel at the customer level?

Alternatives I've considered:

* Create an automation that sets a custom field on each ticket with the preferred communication channel based on the reporter. This would work, but would require the agents to maintain these preferences. I'd like to give the customer the ability to maintain this.
* Add a custom field to the ticket submission form for the user to select their preferred communication channel. Probably the most straightforward option, but adds another field that the user needs to fill out when submitting a ticket.

Has anyone else encountered this? If so, what paths did you consider and what did you ultimately decide to do?

Kaleb King · Answer

I'll look into these options to see what works for us and will make a follow-up post. These were not on my radar, but definitely seem viable.

Thanks @Mikael Sandberg!

Kaleb King · Answer

This sounds like the best solution, but we're not ready to upgrade our subscription from Standard to Premium. We're still working on getting users to adopt this as our help desk solution. I'll definitely consider this option if/when it becomes a core tool and more people are using it.

Thanks @said kouzibry!

said kouzibry · Answer

If you are on Service Management Premium, you could use assets to automatically set the field value based on the customer, given that you have an asset scheme that does the correspondence, for the user to change his preferences, you could add a specific request type called "Edit preferences" for example where the customer could edit not only his preferred communication channel but you could add more preferences.

The upside of this is you won't need to add a field on the creation screen, the customer can change his configuration independently and you'd be able to add more customizations if required.

The downside is, it requires a Premium plan, might be too much work to setup for the value it provides, would require adding one more Request type to the portal with all it's configuration.

If you don't have premium or enterprise plan, the same could be achieved using a project as database along with automation rules, but in my opinion that would mean a lot of work for a small annoyance.

Hope this helps.