Tech Support Plan

From FreekiWiki
Jump to navigation Jump to search

This page left here for historical purposes. -- Mkille (talk) 14:29, 24 September 2013 (PDT)

See here for a Luiz assesment of what needs to happen.


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.



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.

So the stakeholders and the stakes, as I see them are:

FG Sales
  • Added value to systems
  • Better sales
  • Repeat customers/satisfied customers
FG Production
  • Feedback to improve process
FG Mission
  • Increased usability of the systems we refurbish
  • Increased acceptance of Free and Open Source Software
End users/Recipients
  • More incentive to volunteer.
  • More satisfied with the product.
  • Resume fodder
  • Rewarding volunteer experience


  • Usability of systems
  • Customer satisfaction
  • Feedback to production
  • helps further mission
  • gives volunteer techs a resume-building and rewarding experience


  • 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


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.


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

Continuing issues


Demand for tech support in recent months has dramatically increased. As a result, there can be a backlog of boxes going back several days.

"Lost" boxes and paperwork

Occasionally paperwork gets separated from the boxes being worked on. This problem can generally be solved these days using printme, rt tickets and general sleuthing, but it is much better if the separation never happens in the first place

"And another thing"

Occasionally a tech support issue never seems to end. The adopter/customer brings the box in for one issue, and then once that is solved, brings up the next thing and the next.

Long Term goals

For the last several months of 2009, my primary goal has been 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.


Getting and maintaining Full Coverage Tech Support has been the main priority and will remain so for the foreseeable future. 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.


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.


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.

Expanded support

We have been looking at ways of offering more services without overwhelming our resources. One that we have looked at lately is data recovery for donors who want to get pictures, documents or other files off of their drives. I expect we will always be looking at possibilities like this, some of which we will adopt while discarding others.

How to get there

Volunteer recruitment and retention

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 but there is never any room to be complacent. Here we need to make sure there is work for them to do (not a problem right now but sometimes can be), that they have the support they need to do the job (tools, direction, empowerment), that their work environment is supportive(ditto empowerment, listening to complaints and suggestions), and that they feel their efforts are appreciated(frequent thank yous for jobs well done, for figuring out problems, for documenting solutions).

Supportive environment
  • one of the important elements here is that there be a clear path of action. It is extremeley 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.
  • 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".
  • I have been finding that the most effective appreciation seems to be a thank you at the end of the day/shift, but I also make clear that I can be used as a job recommendation. I also think we should create a certificate of appreciation for techs who have stayed for 6 months or more.


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.


There are a number of places where the procedures need to be cleaned up, especially where a system needs to be replaced. This is very easy when the box is a standard freekbox or store box, but is more complicated when it is not possible to replace one box with something exactly equivalent. This is especially true with high end store boxes and laptops. In those cases, we have been falling back on offering store credit, which is not as satisfactory for the customer as getting an exact replacement, but is often the best we can do. Part of the plan is to clean up procedures like this as much as possible, so there is no guesswork for the tech.

Similarly, we have been in transition to charging more for certain kinds of support, such as adding wireless cards, upgrading to more recent versions of Ubiuntu for special needs, etc. I expect that making all this clear and reasonable will take quite a bit of work.


I have been very pleased to have been able to make the changes so far without adding staff time to tech support coverage. This is a testament to the abilities and dedication of the volunteers, but I don't think we should stay with that as a status quo. We should add some hours for a staff person to be able to cover tech support hours in case of need and to spend time training volunteers. This doesn't need to happen immediately and is not anywhere near a full-time position, but it should be part of our planning.


This diagram was created for the 2007 plan, but with some modification is still applicable.

Change Tech Support as necessary to support build, adoption and sales in a changing tech market
Good (for Free Geek) Bad (for Free Geek)
(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.)

  • We create the boxes, so we have the ability to modify production specs and installed programs
  • We can always replace boxes with difficult problems

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.)

  • Tech support must often make up for the adopters (buyers) lack of linux knowledge
  • Quality control can be iffy, resulting in extra work for tech support and a bad experience for the adopter
(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.)

  • The Linux distros are constantly improving, making it possible to give the adopter a better experience with less work
  • More and more people are interested in actually using the OS we put on the box

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.)

  • The economy could get dramatically better and the pool of available techs to volunteer could dry up.

See also Trends and Attributes | What do we want to do?