Request Types

There are a few basic types of request that come from customers:
  • The customer is asking for EDUCATION
  • The customer is reporting a BUG
  • The customer is requesting a FEATURE
  • The customer wants a THEME MODIFICATION


Request Levels

Most tickets also fall into one of three levels of priority / severity:  

  • LEVEL 1 issues can be resolved by the CS lead without assistance
  • LEVEL 2 issues require input from the lead dev (and/or others on occasion)
  • LEVEL 3 issues are serious and/or time-sensitive. Everyone in the company should be notified

The distinction between the levels can depend somewhat on the CS person's knowledge and confidence, and there's always going to be room for growth. You're absolutely expected to try your best to understand the issue and find a solution, but you're not expected to handle a ticket yourself unless you're confident in the response. It's better to double-check than to provide incomplete or inaccurate information.


Classification
You have to know what kind of ticket you're dealing with in order to handle it properly. Before attempting to do this, you must completely understand the root issue yourself. The root issue may not be evident in the customer's question, so this process can require a lot of work. This may mean logging into the customer site to try to find an example of their issue. It may mean trying to reproduce it on a testing site you control. It may mean searching through your email, ticket history, or company documentation. If it's still not making sense, you may need to ask the customer some follow-up questions. (This shouldn't be your first step, even if the customer's original message was extremely deficient of details.)

This process is not always 100% cut-and-dried. The point is to consider things using these lenses and guidelines, not to have a rigid system. Here are some example ticket classifications:


Embedding / Uploading Video

Zach simply wanted to know how to display a video on his site. This kind of thing, where we have a well-established answer, is textbook LEVEL 1 EDUCATION. (This answer could / should even be published publicly.)


How do I change the Page Name of a Custom Page?

Brooke accidentally gave a custom page the wrong name / URL when she created it, and would like to change it. KC explains that it can't be changed and suggests another approach. This could have turned into a feature request if the customer made a convincing argument that changing the current behavior would be a big win, but as it is, it's LEVEL 1 EDUCATION.


Custom Field Names

Jason Troop suggested a feature to allow field names to be customized to match on-site circumstances. This feature already exists, so he just needed to be shown how it works. LEVEL 2 EDUCATION


Printable full schedules

Ryan asked if the paperwork could include a printable full-season schedule. Steve had asked about it as well. We shipped the feature and notified each of them. FEATURE REQUEST


Tasks not showing on dashboard

Nick B has checklist items attached to old (archived) leagues, but they don't appear on the dashboard. This looks like a bug at first. For better or worse, though, the reports are designed to leave out all archived leagues. Knowing this, Nick can make do, so it ends up being handled like LEVEL 2 EDUCATION.


$1 Payments in Players Pay

Ryan noticed that a custom question adjustment in a Players Pay league was not being applied until after the player had paid. (Payment was required for players to confirm their spots.) This left them with a balance equal to the amount of the adjustment. We verified this as a bug and fixed it in the next release. LEVEL 2 BUG.


Icons for sports

Steve Arsenault asks for some icon changes to the home page of his theme. This is a THEME MODIFICATION.


"Sent" box

Brooke wants to know if there's a place in League Lab where she can view all emails sent through the built-in emailer. We've handled this as an education issue / rejected feature request for a long time, no there's no way to do this but (a) you can CC yourself to keep a copy and (b) if you're using email templates you should be able to look at the account notes and know what was in the email and (c) you should use the checklist system to make sure work isn't duplicated. Now, because it's come up so often and our answers don't seem to be satisfying folks, we're working toward a feature to address the underlying need. This started as a LEVEL 1 EDUCATION and was escalated to LEVEL 2 FEATURE


Sub Leagues moved to the top of the player page

Nick B started receiving complaints from players who thought they'd been registered for new leagues without their permission, a la Wells Fargo. Nick did some sleuthing that might well have fallen to us, and discovered that the player page had simply been rearranged: A previous registration for a "SUB" league was showing up at the top of the player page, so the player thought it was a brand new registration. This was an unintended consequence of a change we'd made to help with the appearance of player pages after imports. It ended up being handled like a LEVEL 2 BUG even though there was no actual programming error. 


Acting on a Ticket

The customer should receive a response to each ticket within one business day of submission. This doesn't necessarily mean the ticket will be resolved; an education issue or bug may take longer, but the customer should be assured we're working on it. This first reply (even a request for more info) should always include either an apology or a simple acknowledgement of the customer's experience. This can be anything from a somber admission of guilt and pledge to fix the issue all the way down to simple validation: "I'm sorry your captain is having issues signing in," or "I know what a pain it can be to wrangle team shirts for a huge tournament!"


Education

Education issues are owned from start to finish by CS staff. If you need education yourself and can't get it by research or experimentation, escalate by the usual means.


Bug

Before passing on a bug, you should do your best to reproduce the bug on the customer's live site or on a test site. There are lots of education issues that look like bugs to new customers, and experience will help you to recognize these. If something really looks like a bug, compile as much info as you can on it and escalate it. It should be considered a Level 3 bug if it involves an inaccessible site, broken registration or payment, or serious data corruption. If the customer is panicked and can't be calmed, that may also warrant Level 3 escalation. In any case, the customer should be notified quickly that we're investigating, and again as the process evolves. Once we have a fix ready for the next release, notify the customer and close the ticket. 


Feature Request

CS staff need to divide feature requests into two categories: Those that have a chance and those that don't.


If you can determine that a feature has little or no chance of surviving a triage session, there's no sense in letting the customer think we're working on it or thinking about it. In that case, you should (a) suggest alternate ways of handling the root problem and (b) assure the customer that this isn't making the cut because we're working on enhancements that'll be of much greater value to everybody. (If it comes up again and again, the assessment may change, of course...)


If a feature request really seems like a good, feasible improvement, it should be entered into the triage queue. The customer should be informed that we'll discuss it at our next triage meeting and that we'll let them know if we do end up implementing it someday. There's no need to wait for further input or give the customer more detailed estimates.


Theme Modification

There's some amount of filtering here, as well. If the customer is asking for a change to something that's not part of the theme ("I want my schedule grid to have a green background!") then it's actually a feature request. The customer may also be asking for something that (a) is a terrible idea or (b) won't really achieve their true goal. Assuming the request is valid, though, escalate to the lead dev with a request for feasibility and a time estimate. Assuming it's feasible, translate the time estimate to a quote and reply to the customer. When the customer authorizes the work based on the quote, (a) notify the lead dev, (b) create a card at the top of the Backlog in the Dev Planning board. DELETE ->, and (c) close the ticket. 



Escalation / Feature Development / Seeking Input

The standard procedure for escalating an issue or feature is by email or creating ticket through Freshdesk:

  1. Add a private note to the ticket asking for the specific info or action you need. You're not just passing on the ticket, you're asking a teammate for the particular missing pieces you need to complete your own work on the ticket. If you're notifying more than one person, be sure to direct each request to a specific person.
  2. Notify the issue to the person / people who need to provide the info and/or take action. You can also notify anyone else you think needs to be in the loop.


For a Level 3 issue, also use Slack to alert the whole team. 


Issues Originating Outside of Freshdesk

No matter how an issue arises, it should go through the same process of classification and filtering as above. If it's a bug or education request that requires further follow-up, it should be manually entered into Freshdesk. (Email forwarding may work in some cases as well, but be sure to view / edit the ticket in Freshdesk to make sure it's complete and accurate.) Be sure to include as much context as possible, for your teammates who were not privy to the original communication.


Reasonable feature requests from outside sources can go straight to the triage queue without hitting Freshdesk. 


Accountability
The Tickets page has an UNRESOLVED filter that shows all outstanding tickets, and this list of tickets is the primary accountability mechanism for the CS function. The CS lead is responsible for making sure every unresolved ticket is handled appropriately, and for closing tickets once they no longer need attention. The base expectation for customer service is that every unresolved ticket be unresolved for a good reason, and always moving toward resolution. There's no hard time limit, but it should be extremely rare to find a ticket more than a week old.


When an issue is escalated, the CS person should expect a response within a business day and follow up if none is forthcoming.