Home  |   Reports and Articles  |   Online Seminars  |   Donate  |   Blog  |   About Us

Monday, February 22, 2010

What is Customer Service?

by steve backman

It’s as hard or harder evaluating customer service for software you might adopt than evaluating the software itself. Mainstream computing magazines tend to drown us in all the new features without making the time or resources to evaluate how long choices will last.

By contrast, last year’s Idealware.org assessment of open source content management systems advised, in part, that what you select in the end may have a lot to do with confidence in who will be your line of support. While evaluating service from consultants is different from generally anonymous commercial enterprises, there is a lot to be said to looking at standards, positive and negative, set by those with the most resources.

At home we are coming to the end, I hope, of a protracted process of updating our cable access subscription. Last fall, when we added Internet and phone service to our Comcast TV account, we took for granted that since the physical pipe out to the Internet would be the same, service would remain the same or even get better. As it happened, there were some kinks in the upgrade process. Even so, despite the need for several service visits to our house, I come out of this with nothing but admiration for Comcast customer service. And it made me think hard about customer service standards that we and colleagues might have.

Thinking back, I can tick off some lessons and for the most part admired in the response. And before that, let me add, this does not mean I’m necessarily endorsing Comcast products over other options. Please: that's a different article! And the service standards may vary nationally. I did see some at least regional service standards that I found admirable.

1. If you have a customer service response line, monitor it. I’m sure many of us have experienced the routine follow up survey after service on a car or such thing. Usually pro-forma and you don’t really expect much back if you had issues. In this case, after the initial upgrade, before even calling back, I posted honest comments about where we stood on a generic Comcast customer satisfaction form. Definitely not irate, but not entirely happy.

Quite surprised, within a day I got a phone call from a regional office quality assurance manager. She identified herself by name, gave us a direct phone line to her desk, let me know her hours of availability, and said she would stick with us until our issues were resolved. Latoya patiently listened to everything and got the wheels moving. Since then, she has responded to all our inquiries and followed the case through. Very impressive. Thanks, Latoya!

2. Don’t blame the customer. My wife Linda and I had direct contact with a bunch of different field and office staff. At no point did they blame us for being stupid, not following instructions, exaggerating problems, not “reading the manual,” not being able to isolate incidents or any such thing. It was quite refreshing. When they came on site, they questioned us carefully, and then went about their work. Every time they tried something new, they explained what they were doing, showed us the monitoring tools they used yet didn’t expect us to grasp the intricacies.

3. Don’t ignore the customer’s expertise. This precept balances the previous one. I’m sure most everyone has had the computer company phone support calls experience, where they completely ignore your technical level of expertise, make you go through painful diagnosis steps even when you are pretty sure you know what the problem is. “Are sure, really sure, really really sure you have paper in that printer? I’ll wait while you check.” Doctors and hospitals can be like this too, for sure. Well, at least with technology, if you have skills, you often want to participate, both to get to the solution faster and to advance your own knowledge. The Comcast folks wanted to hear what we had tried on our own, note our subjective impressions on the issues, take it all seriously and incorporate it into their own diagnostics. This is the other side of the previous point, and we appreciated both.

4. Be prepared to support what you offer. We used our neighborhood association email list to see who else might be having problems. We overlaid this “grass roots” information over incident research Comcast did. It turned out some that cabling further away from where we live needed replacement. I’m imagining that as more people took the promotions to upgrade, demand grew and aging switching equipment faced greater stresses. (Kind of ATT’s mobile broadband woes writ small.) Suddenly cables and switches around the neighborhood had to be checked and upgraded. You wish it had been happening before all the past year’s upgrade promotion offers and not after more folks started upgrading, yet once Comcast saw the problems, they escalated the field response to “plant” to deal with it. Manholes opened up and new cables put in.

5. If the customer has made a mistake, discuss it matter of factly without recrimination. As the field response escalated, a senior “plant” level engineer came on site. While not saying we did anything wrong technically, the engineer was not pleased that when we continued to have problems, we didn’t call him back directly. He had also given us a direct line cell phone number. I had misplaced it, and figured since we already had a “friend” in the Central Office, I should just stick with her. That turned out to be not the best, since it led to different field people coming out, the “plant” team losing sight of our situation. It muddied their diagnosis. I could tell the guy was irked both because he had lost time and information on fixing the problem, and also just maybe because the Central Office had expressed impatience. Yet he never blamed us or said we had made things worse. I appreciated that. We listened and learned and after that, made calls to both, and the response closed in on solutions faster.

6. Especially if they are not all “yours,” be sure of your entire chain of service delivery. Comcast is a unionized workforce, with senior service engineers with impressive experience. They also use contractors. The initial crew who came out to do the upgrade were contractors. We were impressed with their initiative in making improvements to our wiring and so on. Yet much later on, Comcast field staff took a closer look at the cable modem and some of the new wiring. The cable modem was both late model and refurbished. Nothing necessarily wrong with that since it’s theirs and they are supporting it. But it took a long time after we had started having problems before anyone thought of just swapping it out. Ditto for the VOIP phone wire they put in. I have no idea whether the contractor work orders ever went from their home office back to Comcast, and it was a missing piece of information for quite a while.

7. Stick with the customer. At one point, we gave Latoya the option to just give us up, cut their losses, and move on. I bet we have all at one point or another been in a project that, hmm, hadn’t gone as smoothly as everyone hoped. What we both most appreciated was Comcast’s commitment to making us whole. Latoya said plain and simple Comcast doesn’t walk away from their customers. We in the nonprofit sector may expect that kind of ethic as well, and it’s much harder for a small consulting practice than for giant Comcast. Yet it’s not the kind of commitment that one necessarily expects to see from the big impersonal guys out there. Given that it will probably take five years or more of billings to us before Comcast balances out the cost of all the service calls, I’m especially impressed. For what its worth, here is the "Comcast Credo."

Now should we measure our sense of Toyota’s responses to its current crisis against these kinds of criteria? I personally don’t know enough about Toyota to comment. Commentators are wondering what they knew and when they knew it and say it will take a long time for Toyota to fully recover its previous reputation.

And the experience made me reflect back on an experience we had a year or so ago. We were consulting with a client on what to do about commercial software they had previously licensed from a national nonprofit vendor. They felt they were not getting the service they deserved given their annual costs. The organizational staff dealing with the software publisher definitely had above average internal technical ability. Yet open tickets lingered for weeks and months. We asked the client to give the vendor another chance and let us look into things. When we called and said among other things we were evaluating whether the relationship was a good one, all of a sudden, things started to fall into place. We had calls directly from a senior corporate officer. We got technical information we could translate into action and relay to the client. Service has improved and the organization is still using the software. But the whole process left me with an uncomfortable taste and came back to me as I wrote this post.

Despite our problems with Comcast, I come away prepared to recommend them again because of these elements of their response, and in fact just have to a co-worker making the same switch. I wrote this without researching what’s out there for customer service guidelines, , and I’m sure they exist and maybe readers will post them. And I haven't checked whether my experience was typical and so on. Its just based on what I observed here. I liked what I saw.




Labels: ,

Monday, February 15, 2010

Supported Open Source

by Johanna Bates

I’m at an interesting intersection in my career path. I just concluded eight years at a small, statewide health care reform nonprofit in Massachusetts called Community Partners. I was Technology & Strategy Director there. Like so many orgs around us, we went under a month ago due to the bad economy. Though I am sad to lose my wonderful co-workers, it was coming for a long time, so I was somewhat prepared. A long time ago, other organizations and foundations started asking me lots of technology questions. This has naturally parlayed into consulting.

At this juncture where I have a sense of what it's like to work in a small org and am also looking at and helping larger orgs and foundations to make decisions about tech and use it in smart ways, I’m thinking a lot about something I call "supported open source."

"How do I choose a CMS?" is one of the most frequent questions I get. "Should I go with a closed but well-supported system or should I venture out into the Badlands of Open Source?" There is another way! That is supported open source.

The perception is often that if you choose open source—even if you hire additional expertise to initially build your site—you have to have skills in-house to keep it going after launch. I think the perception that you're on your own with open source is one of the barriers to its adoption for many businesses and nonprofits. But there are companies and consultants that will stick around, long after your site is launched, to give you the help and support you need. And there are different ways of doing this based on your org's budget.

At Community Partners, we ran things on a shoestring. I build web sites, but I don't write custom PHP code. When we wanted to use a profile module to collect contact information from users on our Drupal site and sync it with our Access mailing list database (yes, I know... Old Skool...), I found the module. It didn't work right. This functionality was a priority for us, though. Luckily, we maintained a contractual relationship with a Drupal consultant who would help us out with our site when our budget allowed. We only paid him to help us when something was broken, or when we wanted a new feature we couldn't implement ourselves and we had the funds to do it.

Having someone you can pay to give you support only when you need it is clearly cheapest way to go. If you're rolling in money, however, having a company on-call 24-7 to support you with anything you need is the other end of the spectrum. And everything in between exists. I want to disclose here that at present, I have a paid relationship with a consulting firm called OpenIssue LLC, which offers a spectrum of services for open source CMS platforms. I am working with them because I am becoming increasingly convinced that supported open source is has some serious advantages for our sector.

I am dogmatic about not being dogmatic, and the needs and mission of an org should always determine what technology they choose, not the other way around. You're never married to a piece of software and you should change platforms if and whenever it serves you. But particularly during this time of economic uncertainty, there is something comforting to me about software that's being developed by a worldwide brain trust. Open source software can't be yanked out from under you if funds (temporarily) disappear, or if a contract expires, because we all own it.

Though this community code base can be messy, open source development specialists know how to clean it up for you. So you get that worldwide scope of innovation, plus the focused attention on your org's particular needs. For orgs that want to stay innovative but don't always have cash flow, this can be a great solution. Ongoing support can be stopped and re-started as needed when there are budget troubles.

I know of a few companies out there that explicitly offer ongoing support for open source platforms. My fave among these is PICnet. Non-Profit Soapbox is designed to be an affordable, fully hosted, software-as-a-service (SaaS) way for nonprofits to build sites quickly and easily in the Joomla! CMS. PICnet has been around for a long time, and honestly I don't know why more companies aren't offering open source SaaS for nonprofits. Seems like a great idea to me. Here are a couple more companies that offer ongoing support:

I predict more of these companies will emerge in the coming year, and I think it will be a great leap forward for our sector. Do you know of a company or a consultant that offers ongoing support for open source software platforms? If so, I'd love to know about them. Please add them in the comments.

Labels: , , , , , , , , ,

Tuesday, November 17, 2009

Microsoft's Secret Giveaway

by Peter Campbell

Screen shot 2009-11-16 at 11.13.06 AM.png

Sometimes it feels like the bane of my existence is my office phone. It's so bad that I rarely answer it, preferring to forward it to Google Voice where I can peruse the barely readable transcripts just well enough to filter out the 90% cold sales calls I receive. So what a pleasure it was to answer my desk phone on Thursday and have an illuminating conversation with my Microsoft Licensing representative. He called to tell me that I own some awesome benefits that come with my Software Assurance program. I'm betting that I'm not the only one who was clueless about these benefits.

Microsoft Licensing, as you know, is the little-known tenth circle of hell. It's a conceptual labyrinth of terms and conditions that was likely conceived by a team of the writers of the original "Prisoner" series with the advice of contract attorneys that graduated from law school 30 years ago and have never since seen the light of day.

Software Assurance is the tax we pay on our MicroSoft purchases that allows us to upgrade to the newest versions without paying upgrade fees (as long as we've paid our software assurance fees, of course). I assume that this is of interest to Idealware readers because most of us pick up a lot of our MS software from Techsoup Stock, and the Techsoup Stock donations come with Software Assurance, not without.

But Microsoft isn't evil; they're just bureaucratic, and every now and then a few smart people step up out of the morass and do things that I appreciate. These Software Assurance benefits include:

The Microsoft Home Use Program provides staff with ridiculously steep discounts on MS Office. Register this benefit, and the allowed number of users (which I'm unclear as to how they calculate) at your company can purchase MS Office 2007 Ultimate Edition (or Office 2008 for Mac) for $9.95. That's not a trial edition, and it's the opposite of crippled -- Ultimate is the "everything but the kitchen sink" edition and it comes with a license key.

Microsoft ELearning is a series of online classes in standard MS products like Word and Excel, and Server products like MS SQL Server or Windows 2003. I did note that the list of available classes that my rep sent me looked a little behind the times; no 2008 or 2010 products covered, but many of us aren't on the bleeding edge anyway.

Microsoft Technet gives you access to forums and experts, as well as evaluation copies of new technologies. For example, as I write this, I just learned that I can pick up Office 2010 and Sharepoint 2010 betas via my MSDN or Technet subscriptions to try.

And the Office Multi-Language Packs let you deploy office in additional languages.


This isn't fluff. We've been paying full price for Office at home (more than we do at work) and I've purchased E-Training on MS products and an MSDN subscription (fairly equivalent to Technet) because I had no idea that I already owned them. It makes me feel much better about what seemed like a pre-emptive insurance program that makes me commit to the next version of MS products before I'm ready to make that commitment, at times.

Of course, this is smart business for Microsoft. With Google announcing that their Google Apps offering will be on a feature par with Office within a year, and OpenOffice under active development as a pretty comparable alternative, you don't want your business customers to get too comfortable with those free alternatives at home. It's just surprising to me that, for years, this was buried in the small print section of eOpen, and not broadcast widely. So I'm doing MS a favor and blowing the horn on this one.

To access these benefits, log onto eOpen (which I hope you're using to manage MS licenses!) and once you've signed in and clicked "unhide licenses", find your last Techsoup order (or a similar large purchase) and open it up. The very first link in the license detail should be "Start and Manage your Software Assurance Benefits". Clicking on that will pop you to a paragraph that includes a link to the "Software Assurance Benefits Management Tool". Click on that to get the benefits. The more MS software you've bought, the more tedious this will be: there are benefits associated with each Software Assurance purchase, so you'll need to register this way for every relevant order. But it sure beats paying for these things at Best Buy!


Labels: , , , ,

Wednesday, July 29, 2009

Compensating for Chaos

by Peter Campbell

In 2000, after spending 15 years at corporate law firms, I made a personal choice to start working for organizations that promote social good by reducing poverty and protecting our planet. I understood that this career move would put some serious brakes on what was a fairly spiraling rise in compensation - my salary tripled from 1993 to 2000. And that was fine, because, as I see it, the privilege of being compensated for doing meaningful work is compensation in it's own right.

We all know that we make less in this industry than we might in the commercial world, and we're all pretty okay with that. But how much, or how little, the discrepancy between "real world" and nonprofit salaries should be is a metric with little established thought behind it. We don't base our pay scales on any rationale other than what we determine others are paying and what we can afford. My concern is that, by not taking a strategic, reasoned approach to compensation, nonprofits are incurring far more unnecessary expense than they might, particularly when it comes to technology support, although these thoughts apply across the org chart.

The problem is that, when it comes to determining the market value of a nonprofit employee, we often go to nonprofit salary surveys, such as the one put out by NTEN and the Nonprofit times. But job seekers don't read those surveys. In San Francisco or New York, a good System Administrator can make $70-80k a year at a for-profit. Even if they come in to your org understanding that they aren't going to be offered the market pay ($75k), they have an expectation that they'll either be on the low end of it ($70k), or within 10% of it ($67.5k). The recent NTEN Staffing Survey puts the average nonprofit Sysadmin salary at $52k, which is about 75% of that market. So, given this scenario, here are my questions:

  • How many excellent candidates are eliminated from consideration because they can't afford to take a 25% pay cut?


  • Of the ones who can afford that pay, how many can afford it because they aren't qualified for the work required?


  • How many can afford it because they have other primary income sources, and therefore can take a low paying job and not feel very committed to it?


  • If a good Sysadmin takes a job at that rate, how long will it be before they decide that they need more money and leave?


  • What is the impact of having a heavy rotation among the staff that maintain and upgrade your technology?


  • What is the impact of having of having often empty critical IT positions?


But, let's get really into this. Unless the IT people that are hired at the 75% rate are extremely mature, then they might have some of the common failings of immature Sysadmins:

  • Many are often controlling and secretive. I've been in multiple situations where I've come into an organization and learned that the prior IT staff left with the key system passwords. I've also seen numerous situations where the IT staff left en masse.


  • Most Sysadmins are lousy about writing things down. What is the ramp-up time for your new staff when they have to research and guess how everything works on arrival?


  • The general instinct of a new IT person is to rip everything out and install their favorite things. Got Windows? They like Linux. Got Word? They like Google Docs. They don't necessarily understand that one platform is much like another, but imposing massive change on an organization can be dangerously disruptive.


Technology candidates need to be assessed not only for their technical skills, but also for their attitude and maturity. A very sharp tech, who can answer all of your Outlook questions, might have little patience for documenting his or her work or sharing knowledge with other technical staff. And those skills are the ones that will allow you to transition more smoothly when the tech leaves.

Mission is a motivator, and it has value that can be factored in to overall compensation, but not to the point where it's so unattractive that it knocks the pool of candidates down to a pool of uncommitted or desperate ones. The impact of paying poorly isn't isolated to the salary bucket on the balance sheet. In many cases, particularly with technology, it's tied directly to the ability to operate.

Labels: , , ,

Monday, April 20, 2009

How to Send an All Staff Technical Email

by Peter Campbell

I had big plans for another insightful, deep, break-down-the-walls-of-the-corporate-culture-that-diminishes-use-of-technology post today, but I think I'm gonna save it for a rainy day and write something a bit more useful, instead. I have a big nonprofit technology conference coming up this weekend, as you might, as well, and I think we should all be resting up for it.

The most important skill for any IT staff person to have is the ability to communicate. All of the technical expertise in the world has little value without it, because, if you can't tell people what you're doing, what you're doing won't be well-received. And there is an art, particularly with tech, to telling people what you're doing, whether it's taking the system down for maintenance of upgrading staff from Notepad to Office 2007.

Here are my five rules for crafting an technical email that even my most computer-phobic constituents will read:


  1. Let no acronym go unexplained.

    The simplest, worst mistake that techies regularly make is to tell people that

    "The internet will be down while we reconfigure the DHCP server" or

    "The database will be unavailable while we replace the SCSI backplane".

    Best practice is to avoid the technical details in the announcement, if possible. But if it's relevant, speak english: "In order to accommodate the growth of our staff, we need to reconfigure the server that assigns network resources to each system to allow for more connections."


  2. Be clear, concise and consistent in your subjects

    Technical messages should have easily recognizable subjects, so that staff can quickly determine relevance. If your message is titled "Technical Information", it might as well be titled "You are getting sleepy..." But, if it's titled "Network Availability" or "Database Maintenance Scheduled", your staff will quickly figure out that these are warnings that are relevant to them. Don't worry about the Orwellian aspect of announcing system downtime with a message about availability. The point here is that using the consistent phrasing will grab staff's attention far more effectively than bolding, underlining and adding red exclamation points to the email (see rule 4).


  3. Keep it short and simple

    It's about what the staff needs to know, not what you'd like to tell them. So, the network maintenance email should not read:

    "The systems will be down from 4:30 to 9:00 tonight while we replace drives in the domain controllers and run a full defrag on the main document server"

    It should read:

    "The network will be unavailable from 4:30 pm until 9:00 pm while we perform critical maintenance".

    If it's only a portion of the network, but something useful will be up - as when the file servers are being repaired, but email is still available, make a note of that: "While the main servers will not be available, you will still be able to send and receive email".


  4. No ALL CAPS, no exclamation points!!! and go sparingly on the bold

    System downtime might be urgent to you, but it's never urgent to the staff. It's a fact of life. A reply from the Director of Online Giving that the downtime will jettison a planned online campaign is urgent; not your routine announcement.


  5. Tell the whole story

    ...even if this sounds like it conflicts with rule 3. Because there are two types of people on your staff:

    • The majority, who want simple, non-techie messages as described above


    • The rest, who want the gory details, either so they can rest easy that you aren't making anything up, or because they're actually interested in what you're up to.



    My approach is to do the simple message and, below it type, "Technical Details (optional reading)". In this section I might explain that we're replacing the server that processes their network logins (I won't use "DHCP" or "Domain Controller" if I can help it) or that we're upgrading to the new version of Outlook.



The key concepts here are consistency, simplicity, and a focus on what impacts them regarding what you're doing. Stick to it and, miraculously, people might start reading your all staff emails.

Labels: ,

Monday, April 13, 2009

The ROI on Flexibility

by Peter Campbell

Non Profit social media maven Beth Kanter blogged recently about starting up a residency at a large foundation, and finding herself in a stark transition from a consultant's home office to a corporate network. This sounds like a great opportunity for corporate culture shock. When your job is to download many of the latest tools and try new things on the web that might inform your strategy or make a good topic for your blog, encountering locked-down desktops and web filtering can be, well, annoying is probably way to soft a word. Beth reports that the IT Team was ready for her, guessing that they'd be installing at least 72 things for her during her nine month stay. My question to Beth was, "That's great - but are they just as accommodating to their full-time staff, or is flexibility reserved for visiting nptech dignitaries?"

The typical corporate desktop computer is restricted by group policies and filtering software. Management, along with the techs, justify these restrictions in all sorts of ways:


  • Standardized systems are easier, more cost-effective to manage.

  • Restricted systems are more secure.

  • Web filtering maximizes available bandwidth.



This is all correct. In fact, without standardization, automation, group policies that control what can and can't be done on a PC, and some protection from malicious web sites, any company with 15 to 20 desktops or more is really unmanageable. The question is, why do so many companies take this ability to manage by controlling functionality to extremes?

Because, in many/most cases, the restrictions put in place are far broader than is necessary to keep things manageable. Web filtering not only blocks pornography and spyware, but continues on to sports, entertainment, politics, and social networking. Group policies restrict users from changing their desktop colors or setting the system time. And the end result of using the standardization tools to intensively control computer usage results, most often, in IT working just as hard or harder to manage the exceptions to the rules (like Beth's 72, above) than they would dealing with the tasks that the automation simplifies in the first place.

Restricting computer/internet use is driven by a management and/or IT assumption that the diverse, dynamic nature of computing is either a distraction or a problem. The opportunity to try something new is an opportunity to waste time or resources. By locking down the web; eliminating a user's ability to install applications or even access settings, PC's can be engineered back down to the limited functionality of the office equipment that they replaced, such as typewriters, calculators and mimeograph machines.

In this environment, technology is much more of a controlled, predictable tool. But what's the cost of this predictability?


  • Technology is not fully appreciated, and computer literacy is limited in an environment where users can't experiment.

  • Strategic opportunities that arise on the web are not noticed and factored into planning.

  • IT is placed in the role of organizational nanny, responsible for curtailing computer use, as opposed to enabling it.


Cash and resource-strapped, mission-focused organizations only need look around to see the strategic opportunities inherent in the web. There are an astounding number of free, innovative tools for activism and research. Opportunities to monitor discussion of your organization and issues, and meaningfully engage your constituents are huge. And all of this is fairly useless if your staff are locked out of the web and discouraged from exploring it. Pioneers like Beth Kanter understand this. They seek out the new things and ask, how can this tool, this web site, this online community serve our sector's goals to ease suffering and promote justice? More specifically, can you end hunger in a community with a widget? Or bring water to a parched village via Twitter? If our computing environment is geared to stifle innovation at the cost of security, are we truly supporting technology?

As the lead technologist at my organization, I want to be an enabler. I want to see our attorneys use the power of the web to balance the scales when we go to court against far better resourced corporate and government counsel. In this era of internet Davids taking down Goliaths from the RIAA the the mainstream media, I don't want my co-workers to miss out on any opportunities to be effective. So I need the flexibility and perspective to understand that security is not something that you maintain with a really big mallet, lest you stamp out innovation and strategy along with the latest malware. And, frankly, cleaning a case of the conflickr worm off of the desktop of an attorney that just took down a set of high-paid corporate attorneys with data grabbed from some innovative mapping application that our web-filtering software would have mistakenly identified as a gaming site is well worth the effort.

Flexibility has it's own Return on Investment (ROI), particularly at nonprofits, where we generally have a lot more innovative thinking and opportunistic attitude than available budget. IT has to be an enabler, and every nonprofit CIO or IT Director has to understand that security comes at a cost, and that cost could be the mission-effectiveness of our organizations.

Labels: , , ,

Thursday, February 05, 2009

The Sky is Calling

by Peter Campbell

My big post contrasting full blown Microsoft Exchange Server with cloud-based Gmail drew a couple of comments from friends in Seattle. Jon Stahl of One/Northwest pointed out, helpfully, that MS sells it's Small Business Server product to companies with a maximum of 50 employees, and that greatly simplifies and reduces cost for Exchange. After that, Patrick Shaw of NPower Seattle took it a step further, pointing out that MS Small Business Server, with a support arrangement from a great company like NPower (the "great" is my addition - I'm a big fan), can cost as little as $4000 a year and provide Windows Server, Email, Backup and other functions, simplifying a small office's technology and outsourcing the support. This goes a long way towards making the chaos I described affordable and attainable for cash and resource strapped orgs.

What I assume Npower knows, though, and hope that other nonprofit technical support providers are aware of, is that this is the outdated approach. Nonprofits should be looking to simplify technology maintenance and reduce cost, and the cloud is a more effective platform for that. As ReadWriteWeb points out, most small businesses -- and this can safely be assumed to include nonprofits -- are completely unaware of the benefits of cloud computing and virtualization. If your support arrangement is for dedicated, outsourced management of technology that is housed at your offices, then you still have to purchase that hardware and pay someone to set it up. The benefits of virtualization and fast, ubiquitous Internet access offer a new model that is far more flexible and affordable.

One example of a company that gets this is MyGenii. They offer virtualized desktops to nonprofits and other small businesses. As I came close to explaining in my Lean, Green, Virtualized Machine post, virtualization is technology that allows you to, basically, run many computers on one computer. The environmental and financial benefits of doing what you used to do on multiple systems all on one system are obvious, but there are also huge gains in manageability. When a PC is a file that can be copied and modified, building new and customized PCs becomes a trivial function. Take that one step further - that this virtual PC is stored on someone else's property, and you, as a user, can load it up and run it from your home PC, laptop, or (possibly) your smartphone, and you now have flexible, accessible computing without the servers to support.

For the tech support service, they either run large servers with virtualization software (there are many powerful commercial and open source systems available), or they use an outsourced storage platform like Amazon's EC2 service. In addition to your servers, they also house your desktop operating systems. Running multiple servers and desktops on single servers is far more economical; it better utilizes the available server power, reducing electricity costs and helping the environment; and backups and maintenance are simplified. The cost savings of this approach should benefit both the provider and the client.

In your office, you still need networked PCs with internet access. But all you need on those computers is a basic operating system that can boot up and connect to the hosted, virtualized desktop. Once connected, that desktop will recognize your printers and USB devices. If you make changes, such as changing your desktop wallpaper or adding an Outlook plugin, those changes will be retained. The user experience is pretty standard. But here's a key benefit -- if you want to work from home, or a hotel, or a cafe, then you connect to the exact same desktop as the one at work. It's like carrying your computer everywhere you go, only without the carrying part required.

So, it's great that there are mission focused providers out there who will affordably support our servers. But they could be even more affordable, and more effective, as cloud providers, freeing us from having to own and manage any servers in the first place.

Labels: , , , , , ,

Tuesday, January 13, 2009

Help for the Helpers

by Peter Campbell

If you're in a job that involves supporting technology in any fashion, from web designer to CIO, then the odds are that you do help desk. Formally or not, people come to you with the questions, the "how do I attach a file to my email?", the "what can I do? My screen is frozen", the "I saved my document but I don't know where". Rank doesn't spare you; openly admitting that you can do anything well with computers is equivalent to lifetime membership in the tech support club.

A full time tech support job is, for the most part, an extended roller coaster ride with more down slopes than up. People who are drawn to this work are generally sharp, eager to assist, and take pride in their ability to debug. The down side is that, day after day, it's grueling. There's always a percentage of people who would just as soon smash the machine and go back to their trusty Selectrics. They aren't always happy or polite with the friendly tech who comes to help them.

But the most debilitating aspect of the work is that support techs don't manage their workload. It's randomly and recklessly assigned by the varying needs of their co-workers and the stability of their systems. They never know when they're going to walk in the office to find the donor database is crashed, or the internet line is down. The emails come in, the phone rings, and, to the people calling, everything is a crisis. Or it certainly seems that way. The end result is that career support techs often develop a sense of powerlessness in their work, and the longer it goes on, the less able they are to take proactive action and control of their jobs.

So here are two complimentary actions that can be taken to brighten the life and lighten the load of the support tech.

1. Deploy a trouble ticket system. And make sure that it meets these specifications:


  • Incredibly easy for staff to use. Web-based, linked from their desktop, with, ideally, three fields: Name, priority and problem. The software has to be able to grab additional information automatically, such as the time that the ticket was submitted, and, optimally, the user's department, location and title, but the key point is that people won't use the system if the system is too annoying to use.

  • Every update is automatically emailed to the user and the tech. This is critical. What an automated trouble ticket does best is to inform the customer that their issues are being addressed. Without this communication in place, what stands out in user's minds are the tickets that haven't been resolved. Confirmations of the fixes, sent as they occur, validate the high rate of responsiveness that most help desks maintain.

  • Be clear that the scope of the problem will influence the response time. Fixes that require spending or input from multiple parties are not slam dunks. This communication might warrant additional checkboxes on the submission form for "requires budget" or "requires additional approvals", but formalizing this information helps the customer know that their issue hasn't just been dropped by the tech.

  • Have a default technical staff view that puts open tickets on top. In environments where the telephone is the primary support funnel, things get forgotten, no matter how good and organized the tech is.



There's more to it - good ticket systems feed into, and include links to additional support resources. And they don't replace the telephone - IT has to be readily available. But there should be an understanding that users follow up phone calls with tickets. These are the key strategies that help the seemingly unmanageable stream of support calls fall in line.

2. Allow the support staff to breathe. There has to be an understanding, primarily understood by the support tech, but reinforced by his or her manager, teammates and staff, that only emergencies demand emergency response times. In fact, treating every call as an equally important, must be fixed immediately situation is a strategy for failure. Support Techs need to do effective triage, and put aside time to analyze and act proactively to solve user problems. If they deal with the same questions over and over, they have to write and publish the solutions. If the calls indicate a common problem that can be solved with a better application or an upgrade, they need to be able to step back and assess that. Smart managers will enforce this measured approach. At first, it will go against the grain of service-oriented staff, but it's a must, because the measured response begets the more comprehensive solution to any problem.

Labels: ,

The Idealware Blog

Thoughts and resources to help nonprofits choose software, from:

Subscribe to This Blog


Recent Posts


Archives