7 Comments

Summary:

Some tools to provide for your clients in order to minimize support after project handover.

cutcord“First, just let me say that I’m touched that you enjoyed my services so much that you want to continue our relationship long after the engagement has closed. Flattered, even. Still, for a freelance contractor, time is money, and you’re not paying me for mine any more, so at some point this has to stop. It’s not you, it’s me, I’m sure you understand.”

The above is a conversation I’ve had to have with clients time and time again, although not in those exact words, of course. Often, I later realized, it actually was my fault. In the early days of my career, I wasn’t providing clients with enough of an end-to-end solution. I short-sightedly forgot that when you’re transferring IP, it’s important to make sure that the client (and all of the client’s staff who will be involved) will be able to use whatever it is I’ve produced for them, for as long as the tool is in active use.

What that shouldn’t mean is that I end up acting as tech support for the rest of my days. What it should mean is that I provide them with enough resources up front that they don’t have to call me every five seconds to ask how to change or update something. Here are some tools you should provide to help make the handover as one-way as possible.

FAQ

Preferably generated through actual use cases and interactions with client staff. For example, if you’re providing a client with a web site, these might be questions that they themselves will receive from clients, like “What is the optimal browser for viewing the site?”, or they might be questions that client staff have about the update/modification process, like “What size images work best for the site’s homepage?”

User Guide

You’ve seen them, you’ve used them, now it’s time to make one. A user guide is an invaluable tool for any kind of deliverable you may be producing for a client. Usually, user guides are living documents and will continue to grow and be added to by client staff.

My advice for producing these is to start with a best-in-class survey, so dust off those that you’ve received packed with software, hardware, etc. and get a feel for the genre. Also, try to strike a balance, if possible, between visual and textual learners, by providing both ample descriptions and screenshots where appropriate. Also, use Clear Writing principles to maximize readability.

Quick Reference Card

Chances are, the people you’re turning over your deliverable to are no more inclined to read through an exhaustive manual or guide to find out what they want then you are. Hence the beauty of the Quick Reference Card. There are plenty of these documents available online, so it isn’t hard to find reference documents to work from.

The danger here is to go overboard and try to provide too much information. Remember, it isn’t supposed to be a manual.

You can also provide different versions of these documents for different stakeholders. Someone producing content might need a flow chart outlining the content approval process, for example, while someone responsible for changing code might need a basic HTML reference.

It can be hard to anticipate every possible question that a client will have after the project is handed over, but after a while you’ll get used to guessing the kinds of things they’ll expect answers to, and all of the above documents will be the better for it. Even if you’re not a pro, though, start using these documents and I promise your phone will ring less, or at least less for the wrong reasons and more for the right ones.

What strategies do you use for minimizing support after handing over your projects? Is some support inevitable?

By Darrell Etherington

You're subscribed! If you like, you can update your settings

  1. I wish I knew about this much earlier. Like you, I spent hours on clients that ask me several questions post-delivery, even after I’ve already addressed those things during the project. We might not be able to answer all their questions with the methods above, but at least it’ll minimize the “urgent” emails and phone calls we get.

    Share
  2. [...] Eliminate Unnecessary Tech SupportProviding thorough documentation can reduce unpaid tech support queries from clients. [...]

    Share
  3. [...] the project scope. While there’s nothing wrong with going the extra mile from time to time, constant support for even the most irrelevant tech issues can be a drain on your time and energy. Instead of [...]

    Share
  4. [...] Eliminate Unnecessary Tech SupportProviding thorough documentation can reduce unpaid tech support queries from clients. [...]

    Share
  5. [...] our work output, I have to teach them how to use it well. But this often burdens me with hours of repetitive tech support. With the use of email marketing services, I can keep clients updated with the latest industry [...]

    Share
  6. [...] the right documents and manuals that they can refer to. Darrrell wrote about this more extensively in a previous post, where he suggested the use of FAQs (Frequently Asked Questions), user guides, and a quick [...]

    Share
  7. [...] Cut the Cord: Eliminating the Tech Support Side of Projects (tags: business resource moxey self) [...]

    Share

Comments have been disabled for this post