Came across this article in PC Magazine discussing "wilfing," a term coined by the British marketing research firm YouGov, short for "What Was I Looking For?". The concept is that as we go to the web to search for something, we're easily distracted by other things and then wind up far off from where we started. The result is decreased productivity.

I've noticed a similar phenomenon with databases, especially during training and testing, but even during day-to-day use. What typically happens is that we're working in the database and come across functionality that is new, works differently than we expected, or doesn't work at all. Then we go down the rabbit-hole of trying to figure out why. And in very short order, we've completely forgotten what our primary focus was.

What's important is that we maintain our focus on the primary reason we were in the database (e.g., testing, training) but also note the issues that arise, so that we can investigate them later. This is where a good issues-tracking database comes in handy. Frequently my clients will use something like Adminitrack to track issues that arise over time. A good issues tracking database goes a long way toward keeping you focused on the task at hand without losing track of issues that arise.

UPDATE: Broken link to Adminitrack fixed.

Full disclosure: EDM is an independent third-party consulting firm. This means we have no financial relationship with any of the vendors mentioned in this blog. We provide unbiased opinions on what we see.

A recent survey by Accenture found that the level of customer service that companies think they are providing their customers does not match what their customers believe. (See here for more info.) For example, in the survey, 75% of executives felt their customer service was moderately or extremely good, but 57% of consumers described themselves as upset or marginally to extremely dissatisfied with their experiences. Wow! That's a serious disparity.

The question for you, of course, is how does your perception match with your customers' perception? Most of us probably think we provide pretty good customer service. But do we? Are we asking? Do we have any idea what our customers and members think of our customer service? And frankly, do we really care?

The key distinction between associations and the technology companies surveyed here is that the technology customer can go to another company, but frequently our members cannot. Many associations have golden handcuffs on members (be it through certification or other products that can't be found elsewhere). This doesn't excuse poor customer service, but we're not going to see members vote with their feet. Although they may vote with their pocketbook by buying only the products they need from us (and that they can't get anywhere else).

So while our associations may not overtly suffer from poor customer service, they certainly won't grow as rapidly or successfully as they could with good customer service. But do you even know what they think about you?

I received a call from them today regarding this post. They assured me that all of their emails are quality-checked for good links. As noted, mine had a bad linke, but at any rate, kudos to them for following up with me.

As an aside, I received another marketing email from them following the one I posted about, and the link in that one was working.

I received an email from Aptify inviting me to attend an upcoming demonstration. I clicked on the link provided and was taken to a page that read "The resource cannot be found." Needless to say, this does not inspire confidence in their product.

It's critically important to check all your links prior to sending a broadcast email. It's doubly-important when you're selling software that's designed to help you do this (i.e., promote your products via your website).

What kind of quality control does your organization have?

I was meeting with a potential client recently, discussing their need for a new association management system. During the conversation we talked about the services I would provide and the responsibilities they would have. One thing I emphasized to them was the importance of having an internal project manager.

Frequently associations (especially smaller ones) want to "outsource" the management of an AMS implementation to a consultant, or worse yet, to the AMS vendor. In this case, I think outsourcing is actually an abdication of responsibilities. Sure, there are project management services I can provide, but my most successful clients have always had someone inside who was responsible for managing the project from the staff perspective, in addition to my services. The simple fact is that there are some things an insider can get done that an outsider can't.

And keep in mind that project management, especially for implementation of a new AMS, is not something you add to someone's already full plate. If you want them to be the project manager, then you need to remove other responsibilities for the duration of the project. And you should expect that a minimum of 50% (yes, HALF) of their time will be spent on managing the AMS implementation. For larger implementations that could run to 80-100% of their time.

I can't overstate it: Those associations that have a dedicated project manager on staff are far more likely to succeed with their implementation than those who add it to someone's already full plate or expect the AMS vendor to do it for them.

Consulting guru Alan Weiss frequently admonishes: "Move a few things a mile rather than a hundred things an inch." Simply put, it's better to have great success with a couple of things than being mediocre at many.

The same is true when it comes to managing our databases. It's very easy to become inundated with all of the many things we'd like to fix or add or change. After a speech I gave recently, I met a woman who said their association was overwhelmed with all of the things they needed to do to fix their current system. She had no idea where to start. I suggested she identify the items on their list that are most important to the success of their database, and ultimately, the success of their organization.

You can't do everything at once. So move a few things a mile rather than a hundred things an inch. Once you start seeing your successes with these first few items, the others will become less intimidating and you'll start to see the light at the end of the tunnel.

While attending a users group meeting yesterday, I asked how many people in the room were using the baseline reports provided by the vendor. (Mind you, this is a system with literally hundreds of baseline reports.) Out of 40 attendees, three raised their hands. Fewer than 10% of the vendor's customers were using the baseline reports. Why? I have three theories:

1. The reports are never complete. That is, the baseline reports tend to show very simple information, and staff tends to want more information than what is being displayed. So the baseline reports are a good start, but they're not useful standalone.
2. The reports don't look like our reports. The baseline reports are, by definition, generic. And even though we can easily add our association's logo to the reports, they still don't look like the reports we've been using for years. And so, even if the report has essentially the same information as my old report, I want it to look like my old report.
3. I don't trust the vendor's reports. If I have the reports built for me, or if I build them myself, I know what data the report is pulling. But I'm never really sure what the report is pulling in a baseline report.

Are any of these theories fairor reasonable? Probably not. But they are reality. And the message you can take is that regardless of how many baseline reports a vendor provides, your staff is probably going to ask for a lot more "custom" reports than you've budgeted for.