Difference between revisions of "Tech Support Plan"
| Line 53: | Line 53: | ||
The second part is keeping the volunteers satisfied with the job, and so far that has been working well. Here we need to make sure there is work for them to do (not a problem right now), that they have the support they need to do the job, that their work environment is supportive, and that they feel their efforts are appreciated. | The second part is keeping the volunteers satisfied with the job, and so far that has been working well. Here we need to make sure there is work for them to do (not a problem right now), that they have the support they need to do the job, that their work environment is supportive, and that they feel their efforts are appreciated. | ||
| + | |||
| + | ;Backup | ||
| + | *one of the important elements here is that there be a clear path of action. It is exptremeley important for tech job satisfaction that they be able to call the shots when deciding whether to replace a defective system. Also, there need to be clear and well-reasoned [[support boundary guidelines]]. | ||
| + | ;Knowledge base | ||
| + | *A lot of tech support, and the reason the best techs are the best techs, involves research and experimentation. Once a solution is found, however, it needs to become part of the knowledge base used by all of the techs so we are not constantly "reinventing the wheel" | ||
===Communication=== | ===Communication=== | ||
Revision as of 17:14, 26 December 2009
Mission
The mission of Free Geek's tech support program is to further the mission of Free Geek as a whole by ensuring the usefulness of the refurbished systems that Free Geek rescues from the waste stream. Tech support does this by repairing systems, configuring systems for special uses, replacing defective systems and by educating end users about the capabilities of the system.
Stakeholders
I created this image as part of the volunteer management class to illustrate the different stakeholders in the tech support process, but actually it leaves out one of the important stakeholders, and that is the techs themselves who provide the actual work and get out of it a combination of experience, an enjoyable (for them) way of giving back to the community, and a boost for their resumes. I always enjoy being able to give a recommendation for a past or present volunteer tech.
Positives
- Usability of systems
- Customer satisfaction
- Feedback to production
- helps further mission
- gives volunteer techs a resume-building and rewarding experience
Negatives
- mishandled support issue can reflect badly on the organization
- does not directly pay for itself
- can be very open-ended, swallow a lot of time and energy
The current situation
Coverage
This is a moving target. Right now, the tech support hours are mostly covered by volunteers. The coordinator needs to do actual tech support only when volunteers fail to show up or when there is a large backlog. Recently, some of the volunteers were moved to morning schedules so that at the beginning of the year, there will be full coverage (noon to 6, actually) on wednesday, friday and saturday. We may also have tuesday morning covered. This leaves thursday mornings still uncovered, but also leaves little room for error if a tech doesn't show up. The current (regularly updated) tech support intern schedule can be seen here.
Record-keeping
Tech support issues are tracked in RT in the support queue. In addition, each box as it comes in gets a work order form attached to it, which includes contact information and info about the box and its issues, as well as a list of any additional items that were left.
Knowledge Base
Regularly occuring issues and their solutions are kept on wiki pages. The full list can be seen by checking out Category:Tech support. These pages are mostly written by the techs who come up with the solutions and sometimes go out of date with changes in the distro we support. There is still a fair amount of information that gets shared by the techs that has not gotten into the wiki pages, and that is a continuing responsibility of the coordinator to prompt for those solutions to get recorded.
The techs
At this point, other than me, the techs are all either volunteers (most of them) or paid through SMS, They have wide range of skills, but all are required to have some experience with the Linux command line. The current job description is here
Long Term goals
For the last several months of 2009, my goal has been largely to increase the number of trained techs to the point that we could open up for more hours. Now that we are reaching that goal, the emphasis is changing and that is reflected below.
Coverage
This has two elements: First, tech support should be open all of the hours that Free Geek is open. We are getting very close to this goal already. Second, tech support should be able to get started working on boxes the day they come in, even if the work takes longer than one day to complete. Since demand varies tremendously day to day, this will be harder to achieve and for some weeks may be impractical, but it should still always be the goal.
Training
A large part of the tech support experience is educational, with experienced techs paired with newer techs, and both sharing information. This has been very informal so far, and I think it has worked really well that way, but in the long run I do believe this process needs to become somewhat more formal. There are three major pieces to doing the tech support job: Following correct procedures, which is something each new tech has to learn; solving puzzles, which needs to be part of the native skill set of a tech if they are to be successful; and developing a knowledge base of linux issues and solutions, which is a two way communication since most of the techs have a fair amount of this when they start that is not already duplicated by what the more experienced techs know. The first of these is something that is amenable to a formal training program. The third part needs to be more loosely structured, with each of the techs adding to a Knowledge Base as they find solutions to problems, and being able to refer to that knowledge base in an organized manner. One of the most empowering parts of the tech support experience (after solving the problems themselves) is to be able to add to such a knowledge base and be recognized for a unique contribution.
Recognition
So far, the primary recognition that a support tech gets is a glowing recommendation for job applications, and I have always been happy to do that. I do want, however, to create a formal thank you in the form of a certificate of time spent volunteering for Free Geek tech support. I don't think it would be a substitute for the recommendation, which is what the techs primarily want, but would be a good addition.
How to get there
Volunteers
There are two pieces to this. The first is making sure there is a way to catch the interest of potential volunteers, and I think that we have that worked out well. The new job description is interesting and Laurel is keeping it out where it can be seen.
The second part is keeping the volunteers satisfied with the job, and so far that has been working well. Here we need to make sure there is work for them to do (not a problem right now), that they have the support they need to do the job, that their work environment is supportive, and that they feel their efforts are appreciated.
- Backup
- one of the important elements here is that there be a clear path of action. It is exptremeley important for tech job satisfaction that they be able to call the shots when deciding whether to replace a defective system. Also, there need to be clear and well-reasoned support boundary guidelines.
- Knowledge base
- A lot of tech support, and the reason the best techs are the best techs, involves research and experimentation. Once a solution is found, however, it needs to become part of the knowledge base used by all of the techs so we are not constantly "reinventing the wheel"
Communication
The primary method of sharing information among techs has been face to face communication, but with so many techs spread over so much time, this has its limits. In September, I set up an email list for the techs and this has been very helpful. Starting in January, the plan is to have monthly meetings of all of the support techs. This approach has worked well for similar groups of volunteers such as the front desk volunteers.
SWOT
This diagram was created for the 2007 plan, but is still applicable.
| Good (for Free Geek) | Bad (for Free Geek) | |
|---|---|---|
| Internal (to Free Geek) |
Strengths: Strengths are advantages we have that are internal to Free Geek and helpful to achieving the objective. (Good things we do.)
|
Weaknesses: Weaknesses are problems we have that are internal to Free Geek and harmful to achieving the objective. (Things we do poorly or not at all.)
|
| External (to Free Geek) |
Opportunities: Opportunities are advantages we have that are external to Free Geek and helpful to achieving the objective. (Good things that will or could happen to us.)
|
Threats: Threats are problems we have that are external to Free Geek and harmful to achieving the objective. (Bad things that will or could happen to us.)
|
See also Trends and Attributes | What do we want to do?