VRM: CRM's flip side

Every non-profit now talks about needing to improve their CRM. But thanks to a post by Jay Deragon, I've been doing some reading this week about the emerging concept of VRM, or Vendor Relationship Management -- If CRM refers to software-based tools for organizations to manage their relationships with customers, constituents, and supporters, VRM is the complimentary set of tools, helping those individuals to manage their relationships with companies, organizations, and communities. The idea is appealing - but its actual application still seems quite hazy. The center of the VRM hub-bub seems to be Project VRM at Harvards' Berkman Center for Internet and Society. Their wiki states that CRM systems until now have borne the full burden of relating with customers. VRM will provide customers with the means to bear some of that weight, and to help make markets work for both vendors and customers — in ways that don't require the former to "lock in" the latter. The goal of VRM is to improve the relationship between Demand and Supply by providing new and better ways for the former to relate to the latter. In a larger sense, VRM immodestly intends to improve markets and their mechanisms by equipping customers to be independent leaders and not just captive followers in their relationships with vendors and other parties on the supply side of the marketplace. Any system that will allow particpation of both vendors and customers (or donors and fundraisers, or politicians and supporters...) starts to point toward the more collaborative environments that are being termed "social media" these days. And indeed, we find VRM being discussed on sites like "The Social Customer" blog by Christopher Carfi, which is trying to evolve models of customer service and marketing that assume a more empowered and participatory customer base. We are all both customers and vendors. But what does a VRM/CRM collaboration look like? This still seems an open question. I'm not yet seeing anything much more concrete than Carfi's call for "a robust way for customers to manage their own online identities without getting trapped in any vendor's silo. " CRM systems today are offering concrete Return on Investment to their users. The VRM conversation needs to focus on how to provide concrete measurable benefits for customers if this paradigm is gain traction.

Systematizing User Support

When I started this "Help-Desk" series I wrote: "A great step forward for your informal user support desk is to provide them with a few procedures and tools that can help them be effective and efficient in this function." But so far all I've talked about is the toolkit: putting a ticketing system in place. What about those improved procedures? Actually, for our little company developing a ticketing system proved to be the key to process improvement: the system made it easier for us to describe, refine, and enforce our approach to support. Turns out it's easier to think calmly and rationally about tickets than about this crisis or that. The key was the Status field in each the ticket. I know this sounds obvious, but it took us a while to realize it: giving each ticket a well-defined status makes the status if each ticket clear. So as we have made improvements in our process, we've added, removed, or renamed statuses, and made changes to the rules governing status change. In the early days of our company, we had a customer support process that Jochen Heyland, our CTO, jokingly describes like this. "When a ticket comes in, determine if it is urgent or not. If it is urgent, panic. Drop everything else and address it immediately. If it is not urgent, just forget about it." I still see this panic-driven approach in play at numerous small non-profits. It arises when no other process is defined and you need to think about how to handle each request as it comes over the transom. How do you improve this? We've moved to a system where any defect reported by a user -- if all goes well -- will pass through 9 statuses. These are Submitted, In review, Approved for action, In progress, Ready to test, In testing, Ready to install, Client testing, Completed. We will also decide if it has Urgent or Normal priority. You might come up with a different process path. That's fine. But having clear terminology for each step helps make the entire process repeatable and controllable. For example, we used to mark an item Completed once we'd tested it and made it available to the user. But we realized that at that point we were still waiting for the user's final words that a problem had indeed been corrected. So we added the Client Testing status. When items languish in this status for too long, we can take action - like calling to see if the problem has indeed been corrected. You also need to define the steps on various side paths. For example a defect report might end up with the status Cannot Replicate. Or a request for consultation or training might need to go through Needs Estimate, Estimate Ready, Estimate Pending Client Approval before it gets to Approved. With this in place, a great deal of your internal administrative work can be accomplished just by calling up a list of items with a particular status. You can sit down as a team and do this. Check what is in progress and see how they are coming along. See what has been approved but not tackled yet -- and find out why. Look for items witht he priority urgent and make sure they jump to the top of the queue. Voila: Order out of chaos.

Turning Help Desk Tickets into Business Intelligence

I was claiming that getting your informal help desk operation organized with a ticketing system does more than streamline that operation - it provides information that can increase your organization's effectiveness. It can have a real impact on mission. So what information do you want to track in your help desk ticketing system? Of course you need to know who reported it, how they described it, when it came in, who worked on it, and how it was resolved. But the key is to know what type of requests you are getting, and how much time you spend on each. The values you allow for request type, and whether you allow for a single type or multiple tags, depend on the knowledge you hope to gain. You are trying to partition your universe here, so that you can learn how many and what kinds of problems each area spawns. You might begin for example with a very simple set of issues. Networking and Hardware Issues. Office Suite Issues. CRM and Database Issues Website Issues Then break out areas you have specific questions about. For instance, if you are trying to verify that you spend far to much time on new user setups, you might want to break that out on its own. Or if you feel you are inadequately protected against vius and malware attack, add malware protection and recovery to the list. Maybe you want to distinguish between problems that had to be resolved by a vendor (like software bugs) and which you could resolve in house. Which types of problems you worked on gains more meaning if you log the amount of time you spent in each ticket. Then you know things like: in the first quarter I spent 10 hours helping people search for documents they misfiled, for a cost to the organization of $400.00 of my time and an estimated additional equal amount in lost productivity. So finding a tool that helps with this problem could be worth up to $3,200 a year to us. Of course you won't know today what questions you want to ask of your data six months from now. So you really ought to allow for multiple topic tags. For example, if a user reports a problem with scanning credit cards, you may want to tag the request with numerous related terms - Point of Sale, Credit Card, Payment Processing, and Accounting. And you probably want to allow for a full text search of the description, in case you are looking for a term you had not thought to use at the time. Now you are really set to answer questions about the support your IT infrastructure has required. Next we'll look at how the ticketing system can help you deliver that support most effectively.

The Non-Profit Help Desk.

Every organization -- no matter how small - needs to have an IT Help Desk of some sort. Actually, every organization already has one, because everyone on staff has figured out "Who ya gonna call?" when hardware or software refuses to behave. A great step forward for your informal user support desk is to provide them with a few procedures and tools that can help them be effective and efficient in this function. I'm not saying your help desk needs more technical skill. Not at all. As the Wizard of Oz might say, "The non-profit sector is full of help desks that have no more technical skill than yours has. But what they do have that you do not is a Ticketing System. It's remarkable what even the simplest ticketing system for tracking user requests will do for your informal help desk operation. The users benefit because their requests are less likely to slip through the cracks. Having a formal queue of requests reduces the panic element in support, and this immediately makes the system more efficient. for the entire organization. But it's the knowledge you gain over time from the ticketing system that is the real benefit. A ticketing system lets your organization track what kinds of support requests are coming in and who submits them. It allows them to know how much time is spent in the aggregate, and on specific types of support. This information provides real business intelligence pointing towards I.T. improvements that you know in advance will save staff time and thus have a positive impact on mission. What should a Ticket include? More coming up.