Customer Support

Edit This Doc

General Customer Support

Platform help, training, Zendesk and [email protected] requests which forward to Zendesk.

  • Zendesk for communication to customers
  • Customers without contracts (developer community) is not immediate
  • 1h Support expectations and response times
    • Giselle Between 12am-8am PT
    • Kim Between 8am-5pm PT
    • ??? Between

Bugs - Internal Developer Support Needed

When a customer reports a bug, first try to recreate the issues, record your findings using a tool like https://www.loom.com/ and follow this process:

  • Immediately write support issue via our Github repo using the Bug or Feature template as necessary. The main repos are:
    • Manager UI
    • Accounts UI
    • Instances API
    • Accounts API
    • WebEngine

List of Contacts to Reach out to and Assign Github Issues

Product Owners

  • Instances API: Chris Roberts
  • Web Engine: Randy Apuzzo
  • Manager Interface: Stuart Runyan
  • Accounts interface: Stuart Runyan
  • Accounts API: Chris Roberts
  • Web Application Firewall: Stuart Runyan
  • Customer Services: Stuart Runyan

Escalation

When a platform or product issue occurs there a specific order of escalation that should be followed.

  1. Triage the issue and determine it's severity. This will take judgement on your part. In general it can be thought of as follows.

    1. An issue the customer has a work around for. Low severity.
    2. An issue the customer is blocked by. Medium severity
    3. An issue affecting all customers that is blocking them. High severity.
    4. Platform/instances are offline. Critical severity.

  2. Report issue with appropriate escalation and location.

    1. Low severity, maybe the issue just needs to be recorded in github and will be addressed with available time.
    2. Medium severity may necessitate a real time conversation on slack. Potentially @ mentioning in the product owner.
    3. High severity can make sense to direct message the product owner to get a timeline on a solution.
    4. Critical severity is all hands on deck. Reach out to any and all product owners, across all channels, until a response and the issue is recognized.

  3. Escalate issue. Typically escalation will follow the flow of; main thread slack message, @ mention specific person, direct message specific person, phone call and/or text message specific person. How far you take the escalation should be based on your judgement of the severity or priority of the issue being reported.

Services Support

  • 24h ? Based on SLA
  • Direct through Dominic

Customer Support Tips

A few things to keep in mind when triaging customer support requests. Either in email, chat apps, VoIP or webcam.

DRY (Don’t Repeat Yourself) (Slack)

If you have responded to a question on a channel/thread/etc and @mentioned another user, do not DM that user immediately to let that user know you need them to respond. A side channel is only appropriate if you need additional information from another user that you don’t think needs to be @mentioned into a conversation or if a response becomes critical.

For example: An account question? Don’t side channel after @mentioning. Site down? Absolutely side channel after @mentioning. In a critical case like that try elevating side channels until you get a response.

Elevating Channels (slack)

The order of elevation should be. Channel > @mention in channel > DM user > Phone call. A good rule of thumb is to avoid DMs. DMs can keep helpful context hidden if additional support reps are added into the conversation.

One support person at a time

When someone is triaging a support request let them handle it from start to finish. If you have helpful information feel free to pass that along on a side channel. This is important because having multiple voices answering customer questions can be overwhelming. It also makes it difficult for the customer to track the progress of their inquiry.

Clear hand offs/takeovers

When you need to elevate a support request to someone else who may have the answer, make it clear who will continue the conversation with a customer.

For example: If you hand off, inform the customer that they are being handed off to someone else for help and will answer their questions moving forward. Vice versa if you need to takeover a conversation, thank the prior support agent and communicate you will handle the issue going forward.

Avoid third person

Remember when messaging with a customer you are talking to a person so treat the tone as if they were in the room.

For Example: Using @name mentions when referencing someone. Just like in life we enjoy it when people use our names.

Account Knowledge

We service a lot of customers and as such it’s totally okay not to know all the details of the account. Especially if it is a detail that is not first-party to Zesty.

For example: Where a customer's DNS is managed.

When it is directly related to Zesty, inspire confidence in the customer by letting them know you are working to collect the information they are asking for if not at your fingertips. Remember you are the product provider so if you can’t get an answer about a Zesty question then how could the customer possibly find out.

Customer Private Channels

Try to avoid DMs and keep all conversations in a customers channel. The historical information can be helpful when researching past conversations on the same topic. As well as it keeps everyone publicly accountable. Although the private channels are meant as a way to have more straight forward conversations around a customer’s private information, remember that you are still a representative of Zesty and your speech should reflect a professional manner. That is, clear and concise communication.

Questions questions questions

Always default to asking more questions if you do not understand the original question, context or if there is any confusion. It’s okay not to know everything!!! As such it’s totally okay to have to defer an answer until you’ve gotten sufficient information, either from the customer or internal resources.

Details details details

Make sure you get all pertinent details:

  • Instance ZUID
  • Item ZUID
  • Steps to recreate
  • Loom video of the issue if possible

Threads! (Slack)

When responding to a customer question. Always does so as a thread. It helps keep the conversation context in a single place and avoid confusion of multiple conversations happening in the main thread.

Doing vs Building vs Fixing

At this point we are "feature complete" in the sense that we have built the product to provide a large amount of functionality and it does so well. Whenever fielding a request, ask yourself is the customer asking me to do something, build something or fix something.

Doing Something

We typically won't. As we don't provide services, the product should offer all the value. Now you will need to be judicial about this. As maybe the "doing something" can be shown how to do it by creating education material that empowers that customer to accomplish the task themselves. As well as sometimes a request to do something is good insight into something we should be building (read: automating).

For Example:

  • Customer: I need to change content across a set of data. Is this something you can do for me?
  • Support: No this isn't a service we offer. You'll need to manually change the content or you can use our API/SDK if that works for your situation.
  • Customer: Okay

… Support wonders if this could be a feature and talks to product team …

  • Support: Hi, I wanted to check back in and see if you were able to achieve this change?
  • Customer: We haven't changed this content as of yet.
  • Support: Well I mentioned this to our product team and they think we can provide an automated solution. Is this something you'd be interested in?
  • Customer: Yes! Definitely.
  • Support: Great. I'll connect you with one of our product managers so they can get a better idea on your use case and see if what we can provide will solve your needs.

Building Something

This is the lifeblood of our product. Hearing out our customers needs, tracking them, and providing solutions will continue to be relevant and delight our customers. But each of these requests needs to be evaluated, scoped and scheduled. Also not every request to build something will end up being something we do. In general these should be captured in Monday and elevated to engineering to ensure they're aware.

For Example:

  • Customer: Can the health app do wildcard routes?
  • Support: No it is only designed for page to page redirects.
  • Customer: Is this something you would be able to add?
  • Support: Let me bring up this request with our product team.

Fixing Something

With these requests the first thing that should be done is to qualify the expectation. That is, is what the user expects of this feature what it was designed to do. If yes and it doesn't, that is a bug request. If no, then that is a feature request. By determining which one the "fix something" request is you can then determine who to capture, elevate and respond to the request.

For Example:

  • Customer: Someone I invited can't accept the invitation?
  • Support: Does this person see the invite when they log into accounts.zesty.io?
  • Customer: Yes
  • Support: And clicking accept doesn't give them access to that instance?
  • Customer: No
  • Support: Okay. That is not the expected behavior. It sounds like there may be a bug with that experience. I'll bring this issue up with our product team immediately.

…

  • Support: Hi. Our product team has confirmed that there is a bug with this feature. They are actively working on a solution.

Support, Docs, and Onboarding

Please refer to decision tree below to determine when a new docs needs to be created and when the OP needs to be modified to add new content.
onboarding doc decision tree