Support prioritization

We have many factors to consider in order to determine priorities and as such, we need very clear boundaries and definitions to ensure there is only ever a single number one priority and it’s straightforward to determine what that is.

Priority definitions

All work is assigned a priority per these definitions:

  • p1: All customer (including those in the pre-sales process) reported issues per our contractual p1 service level agreement definition here (even Cloud customers, though we don’t have SLAs for them at this time).
  • p2: All customer (including those in the pre-sales process) reported issues per our contractual p2 service level agreement definition here.
  • p3: Any internally identified goals/tasks/projects.

Time allocations

80% of our time is spent on p1 and p2 work (with p1 work being rare). 20% of our time is spent on internally identified goals/tasks/projects. We protect this time with our focus blocks as outlined in our team schedule.

Making hard choices

Sometimes we have too much work to keep it simple. In these situations, we will put forth our best effort and unless something about the situation requires us to deviate, we follow this order of priority:

  • Pre-sales customers first
  • Enterprise customers second
  • Team customers third
  • Free customers fourth
  • Open source fifth
  • Internally driven work last

When we have a normal amount of work, we help when help is needed and even with a SLA of 24 hour response time, we still strive to get back to customers (including pre-sales) within a couple of hours most of the time.

When we have an unusually large amount of work or more folks are out than normal, it is fine if customers (including pre-sales) have to wait. In such situations, we will communicate proactively, letting them know that we have team members arriving in another few hours who will be able to help them.

Priority assignment

Priority is always assigned by us, sometimes with input from the customer and/or other internal teams/practices/contractual obligations. We will only expect engineering to drop everything for p1 if it really cannot wait a day. Either way, the idea is that we expect very few p1 issues overall, so the need to drop everything should be rare. This also means that it’s okay for p2 issues to sit a bit before engineering takes a look and decides timing for work. The onus will be on support to provide all the necessary context for engineering to decide how to handle p2 issues.