Category: Customer Service

What I do as a non-programmer

A few weeks ago Spencer Fry (Carbonmade) posted a nice article about what he does as a non-technical/non-programmer employee/executive at a web-based company. I had already been playing around with a post discussing the same (his is very good) but it inadvertently fell to the wayside while I was…well…doing those things I wrote on my list.

The life of non-programmer at a web-based shop is interesting to say the least. A lot of time is spent either mulling the things that absolutely are necessary to keep the business on an upward trajectory and battling with myself as to whether that thing is actually necessary. That is to say, battling over what to contribute and what not to contribute (I believe the latter is more important than the former in the long run). Additionally, it’s not a rare moment when I’m questioning whether or not I can stay as valuable to the company as our code-contributing staff (who are literally the architects of our future/potential success).

I started in 07 as 50% of our non-programming staff (but 1/3 of our startup). In the early days it was easy to pick up the slack. I was eager to contribute ideas and copy and brainstorming sessions where we laid all of our future successes out like a road map. As soon as I understood the business well enough though, I resigned to do my best to pull my own weight since I was unable to contribute to the code.

Here’s my short list of 9 (but maybe more…) aspects of my non-programming position. Which I might also title my “start up job description”.

1. Test
2. Draw diagrams (but not imaginary screen shots – relational diagrams can help a lot more than “I want this button right here”)
3. find non-technical solutions to user problems
4. be a buffer
5. Build the business: go sell something, find customers, make $
6. Refrain from complexity (don’t spend time asking for additional features, just because you’re not busy doesn’t mean programming staff isn’t chipping away at the most recent revisions, enhancements, bug fixes)
7. write FAQs, site copy, user guide books, make tutorials
8. never use a bug as the basis to add an enhancement
9. PUBLICIZE
  1. Test – never a day goes by when I’m not on the system. I’m a power user. Be it Moodle, proprietary systems or just a home page. No link goes un-clicked, no combination of variables goes untested and no bug is left unearthed. When our programmers think the code is “perfect” it’s my job to point out where things break down or usability becomes confusing or some other practical/common process has been disrupted. I check from different browsers, different operating systems and with different end results in mind. Then I ticket and follow up and repeat. Testing, to me, is really synonymous to providing customer support and it’s either proactive or reactive (so might as well start testing now before you’re trying to test to find out a certain nuance that a user submits later).
  2. Draw diagrams (but not imaginary screen shots – relational diagrams can help a lot more than “I want this button right here”).
  3. find non-technical solutions to user problems. You might also call these “hacks”. If there’s a crazy bug or usability issue, I’ll ticket it. But I’ll also find a way around to ensure it’s not a blocker. Doesn’t load right in IE? Try FF. Doesn’t display in my profile. Unenroll and re-enroll. Blockers get highest priority, so when there’s a back log of those it’s my job to find (and disseminate) workarounds for the non-blocker (but critical) issues. This often means that I’m elbows deep in user interaction, guiding them through ways to fix the issue themselves or fixing this issues remotely to give them the smoothest user experience.
  4. be a buffer: I mentioned earlier that programmers are extremely valuable; that’s why I focus on keeping them out of the focus. The programming staff I’ve worked with is efficient and creates excellent applications for our clients. But they shouldn’t be changing passwords or trouble shooting for specific user issues. This goes the same for the executive/programmer line of communication (if you happen to be at a bigger company). Distractions are costly. If there’s a road map that is worth following, it’s only a matter of time before a client need 0r CEO idea brings you off course. Creating a buffer can help your app “stay the course”.
  5. Build the business: go sell something, find customers, make $, organize paperwork, manage finances (this stuff is the simplest when you’re getting started but it grows and grows in proportion to success).
  6. Refrain from complexity: don’t spend time asking for additional features, just because you’re not busy doesn’t mean programming staff isn’t chipping away at the most recent revisions, enhancements, bug fixes.
  7. write FAQs, site copy, user guide books, make tutorials. I would say that this is probably the 2nd most important role, besides customer support and satisfaction.
  8. never use a bug as the basis to add an enhancement.
  9. publicize/socialize: manage twitter, blog about the business, do the presentation circuit. Whatever you can do to spread the word about your business should be done and done well.

The best customer is a DIYer

If you work in customer service in a web-based company, the best type of customer you can ask for is a “do it yourself-er”, that shares their discoveries.  Why?  For a few reasons:

  1. The best characteristic of a DIYer is that they’re usually tech savvy.  They’re using your site not because they’ve been forced to or because it’s the first thing they found.  They use it because they’ve surveyed other offerings and decided that your’s is either the best, has the potential to be the best, or has some other advantage over a competing service.  (They also tend to know the “lingo”.  So supporting them from page to page over the phone or asking for a URL to the issue tends to be a simple task; not a formidable request.)
  2. another great advantage of a DIYer is that they’ll trouble shoot your site for you.  Whether your using an open source application or building a proprietary platform/application, the DIYer familiarizes themselves with the environment.  They read your FAQs and they engage the tutorials/training materials you’ve created and at that point (and only at that point) if they don’t know how to do something or are finding an insurmountable error they contact you.
  3. by contacting you they point out holes in your support/help foundation (because they know and are familiar with what you have provided and exhaust those resources before contacting you.  If you can identify these individuals early (and keep them) then they’ll be a great resource in deciding your customer support, help documentation, and even the software roadmap to improve usability.

It’s possible that you refer to these types of customers as something else (allies, models, etc.), but I’m sure you’ll agree that these customers are the best to have (even better than customers that are silent even in the face of buggy software of outages).

I bring this up because non-DIYers often take up the most time and are the most costly to appease.  In some cases getting them squared away is near impossible (or perhaps actually impossible, though I reject the notion that there’s a customer issue that cannot be resolved.  I’ll die trying.).

In closing, if you’re trying to build a product for a market that is devoid of non-DIYers (seniors, or 1st time internet users) then be prepared.