-
You should be constantly testing case issues in the testing environment. This is the best way to learn the system.
-
Stay up to date on emails. You may not always have time to answer right away, but you can at least read them as they come in so you don't miss anything important. Emails are much harder to catch up on than they are to maintain, so try to schedule a regular time every day to review them.
-
Review your entire queue at least once a week to make sure no tickets are falling through the cracks, or going too long without a response from the customer (I recommend reviewing your queue like this every day). Find tickets where work on the ticket has stalled and reach back out to the customer to see where they are at and try to get the ball moving again.
-
If you need to move a ticket to a teammate's queue for any reason, make sure to let them know you have done so.
-
Before sending a ticket to any other queue, make sure to make a note summarizing the case issue and why it is being moved.
-
Don't be afraid to pick up tickets about things you don't understand and then ask for help answering them. Taking tickets for modules/integrations you don’t understand well can be a great opportunity to learn more about that module/integration.
-
Something that can help is making notes about tickets you can reference later. Especially if you learned something new on that ticket. I keep notes in OneNote and I have a page for each module in Sedona (CM, AR, AP, etc..)
-
Remembering the names of companies and individual customers can, over time, help you better diagnose their issues, as you begin to learn the sort of things that trip them up specifically. Try calling them by name, and putting their companies' names in emails to help you remember.
-
If customers reach out to you directly or tack on new issues to your current case, ask them to please submit a new case instead. Explain to them why this is to their benefit, that it ensures their issue is still seen and addressed even if you are unavailable or with another customer. There are three main reasons we do this:
-
One small question may not seem like an issue, but if you get in the habit of answering questions without tickets they will pile up, and customers will begin contacting you more and more to try to get a fast answer rather than waiting their turn.
-
If you answer a question without a ticket and then that customer asks someone else about that issue we have no way of knowing what is going on if we don't have a ticket to look at. This is especially important if you are sick, or not in the office.
-
Additionally, if a customer tries to blame you for an error in their system and there is no ticket, then we have no trail of what happened.
-
-
It is important to apologize when you have made a mistake. But sometimes customers are upset about situations that are not anyone’s fault. If we apologize in those situations customers often get the wrong impression from that apology, and it can upset them more. Here is an example of an actual email someone had with a customer where a sorry went wrong:
"Our Development team is aware of several issues that need to be fixed but I do not have a date to give you in which this will be done. Sorry. "
The customer responded:
"That’s not a resolution, that’s a Sorry, better luck next time. I’m a bit disappointed right now."
A better response may have been:
"Our next release is scheduled for xxx. I will reach out to development to see whether or not this will be included in that release. The answer will depend on space in the development schedule and whether or not the item passes QA."
