-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define some first-line and second-line support processes #1068
Comments
cc @sgibson91 who I believe has some notes about support processes at other organizations that we could use for comparison. |
Notes on Managed Service Provider (MSP) first-line support protocolsI had a chat with my partner who has done first-line support in a couple of companies and this are my notes from that discussion.
Responding to tickets
Prioritisation of tickets
P5: Service request - This is an "I would like..."-style ticket
SLAs regarding timeframes for carrying out support-related tasksThese are the timeframes we agree with a client for resolving problems. They should be defined in number of working hours within our active support hours bracket (I'm cheating in the example below).
P5: Resolve within 5 working days unless it needs to be a project Communications during P2/P1 eventsP2: Provide updates every 2 hours Have a comms template for these events. From what was described to me, this is very similar to the top half of our Hub Incident issue template. Includes a timeline of the event, the symptom reported, etc. These comms should still go out regularly, even if the update is still "we're investigating". What channels do these comms go out on? Mailing lists, forum posts, twitter? After the event is resolved, compile and release an autopsy report. This is very similar to the second half of our Hub Incident template. Covers what went wrong, how did it go wrong, what are the steps to prevent it happening again or minimise disruption if prevention isn't possible. Support Tiers
This is potentially something we could fit into our alpha service pricing matrix Guidelines for what is in scope of our support modelWe need to define these (maybe on a per client basis?) and be strict about it. The "maximum capitalist company" thing to do might be:
I'm not 100% convinced that's the right thing for 2i2c to do, just presenting it here as one aspect I learned about. One guideline I do think we should implement is that clients should give us at least two weeks notice for when a requested change (low priority) needs to be ready by, e.g., if we are managing their image and they request a package. We should avoid the situation of a request for a package comes in and 2 days later, the client says they really need it. In the meantime, we've been battling timeout builds/pushes or whatever. If a low-priority request comes in with less than two weeks notice, then we make no promises to have it ready by the time the client needs it. Disadvantage(And a pretty big one IMO) This style of MSP support requires time-tracking in order to bill the client for, e.g., overtime on support hours, projects generated from support tickets, etc. |
Some info from a friend at a tech companyI also had a conversation with a friend at a tech company about this that runs internal and external software services (not mentioning company or friend's name for privacy purposes). Here's a short breakdown of their process: Roles they use
When a support request comes in Here's what happens:
How this interfaces with development They do development in parallel with these operations tasks, and each team member has ongoing projects with deadlines associated with them. Occasionally, there are enough operational tasks that they realize they won't hit their deadlines. When this happens, the Project and Team Managers discuss with one another and agree on a plan forward, potentially to move back the deadlines for their projects. |
Thank you both for sharing these pieces of information! |
Update@yuvipanda had some great ideas in #1154 for steps in this direction, along with process notes shared from Sarah. I think we should make a quick push to document some of that, since the content is mostly there. We could also use this as an opportunity to update our SLA docs a little bit to make them more clear. |
I'm going to close this one and say it was completed by merging the following PR: We can continue to iterate on these team processes over time! |
Background and proposal
There are often cases where our support process is under-documented. For example, a few questions that people weren't sure how to answer:
We should document some rough guidelines for these common questions, and also provide references to documentation about how to carry out first-line support.
Implementation guide and constraints
Another way to approach this is to ask "what are some common support situations, and what should we do in each situation?" We can draw from our experiences thus far to agree on some team practices to follow.
Updates and ongoing work
Add items below as we learn more
Refs
The text was updated successfully, but these errors were encountered: