Don't forget, in addition to all of these brilliant blog posts, you can find a bevy of free articles on my website. I've recently added two new articles to the list.

I typically add one new article per month. You can sign up to receive notices as new articles are posted by clicking here.

The Wall Street Journal had an interesting article (subscription required) a few days ago talking about the trend in "management by data." In a nutshell, large corporations have figured out that if you analyze the behavior of your customers you can leverage that information into better performance.

The dark side, according to the article, is that if you focus exclusively on managing by data, you are managing for now, but not for the future. One example they provide is Dell, which, as the WSJ put it, "…captured an increasing share of sales and profits in the PC industry by mastering supply-chain logistics. But Dell couldn't diversify its business, making it vulnerable once Hewlett-Packard matched its expertise."

The lesson for associations (and all businesses): You need to do both. You need to use your data to get the most out of your current customers, but you need to pay attention to the future an how things are changing, and be able to adapt to that.

On his Membership Marketing Blog, Tony Rossell has a post about membership dashboards. He provides a link to a chart that shows all kinds of membership information. I noted in the comments section:

"…I must take exception to the use of "dashboard" with the example you provide. A dashboard, at a glance, provides instant information to the reader. For example, when I glance (not study) my car's dashboard, I can instantly tell if I'm going 60mph vs. 20mph by the direction of the speedometer dial.

The charts you provide are just that: charts. Dashboards give you an instant reading; charts require studying."

This isn't the first time this has come up for me. Several weeks ago I had a lengthy discussion with an esteemed membership colleague of mine, who was arguing the same point as Tony. I contended then, and I contend now, a dashboard gives you instant information, at a glance. If you have to study it, it's not a dashboard. And incidentally, dashboard information should be up-to-the-minute. Imagine if your car's dashboard provided you information about how much gas you had yesterday, instead of how much gas you have this minute.

This is not to belittle the need for the charts that Tony describes. Those data sets are important. But let's not call 'em dashboards; let's call them charts or reports.

In this tip, I discuss how considering "worst-case" scenarios can help you decide whether or not to do something. There has been an interesting thread on one of the ASAE listservers about the "risk" of putting the membership directory online (and ceasing publication of a print directory).

Anecdotally, about five associations said they had moved to an online-only directory with little to no comment or complaint from their membership. Just one association had the opposite experience: They moved their directory online, stopped publishing the print directory, and got lots of complaints from their members. They ultimately decided to go back to a printed directory.

In all cases, including the one that failed, the association took a prudent risk and waited for the results. Whether they considered it or not, their worst-case scenario was one where the membership complained and they would have to move back to a printed directory; no harm, no foul.

These are great illustrations of how small risks can pay big rewards; and even when the experiment fails, the "damage" done is minimal and life goes on.

What risks is your association taking?

I had the opportunity to view a demo of the Computility AMS recently. For very small associations, I think the system is worth consideration. Here are the highlights:

• CRM tool. The system includes a neat area for tracking contacts and follow ups with companies and individuals, and even allows for assigning follow up to other staff members.
• "Process" tab. Computility will work with the association to identify any "repeatable" tasks (e.g., membership sales and follow up) and set these up under the Process tab for easier tracking. It's a sort of workflow tool that I've not seen in many other AMS products.
• Pricing. Computility has very aggressive pricing for implementation and sell their product as an SaaS tool. This means a monthly fee per named user, which Computility has set very low, at least for now.

Weaknesses:

• e-commerce tools are still under development. For example, there is no utility currently for a member directory driven from the database (this is coming in the Fall, I'm told).
• Membership is tracked by a checkbox. I'm not a fan of systems that track membership this way. Membership should be tracked based on invoices so that no one "accidentally" adds or deletes members with a simple check of a box.
• Reporting. The query tool was good, but the reports tend to be simple queries, rather than full-fledged printable reports.

Overall the system holds promise. Even though the database itself is five years old, I think it still needs development in key areas (particularly e-commerce). Time will tell.

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. 

I often tell my clients to avoid managing (or programming) to the exception. What I mean is too often when one or two members or customers complain about how we do something, we assume that we should accomodate their complaints and change our processes (or worse yet, reprogram the database to manage it). It's quite possible the one or two complainers are outliers and we should ignore them.

I ran into an example of this recently when filling out a form online. The form was for submitting a proposal for a presentation at a conference The form said, and I quote: "Describe the session content and format. Be specific! You are limited to 100 words."

Be specific? 100 words for a session description? Be specific, but be brief!

I have no knowledge of how this form was designed, but I'm willing to bet it went something like this: "You know, last year, ONE person wrote a whole book for their session description, so let's limit everyone to 100 words."

Seriously, what logical reason could there be for limiting a session description to 100 words? Why not 1000 words? Are you telling me that the vast majority of applicants will write hundreds and hundreds of words for their description? And even if they do, who cares? Does limiting the number of words help the applicant, or the staff? 

Look around your organization, especially at the rules you have in place. Are they in place to benefit the customer, or to benefit the staff?

I was trading emails with my colleague (and fellow AMS consultant) George Breeden recently, and he raised an issue that I've long felt was missing from essentially every AMS vendor out there. George put it this way:

The vendors should be taking proactive steps to maintain and build the relationships, not just in a reactive manner when they think the client is leaving - it's too late then. I would suggest that part of the package would be a yearly gap assessment and recalibration (training, BI, usage, etc) to help make sure the organization was getting the most of out the AMS system. If they were smart, they wouldn't charge for it either.

I think this is a brilliant idea, and I would add the following, which I've suggested to some of the AMS vendors. Every AMS vendor should have a client ombudsman. The ombudsman's job is to reach out to every single client on a regular basis, to get a sense of what the client is doing, how happy or unhappy they are with the AMS product, and what kinds of issues the vendor should be focusing on.

The reality is that the vast majority of associations that I talk to feel like they're out there on their own when it comes to their AMS. They feel like the only time their vendor listens is whent they're spending money. I'm always harping about how associations need to view this as a long-term relationship (see here, for example). Perhaps I need to start harping on the vendors, too.

For associations: What do you think? Is your AMS vendor paying attention?

For vendors: What do you think? Why can't you implement these ideas?

Recently I began receiving emails from a political advocacy organization that has views that are, shall we say, completely counter to mine. I suspect one of my "funny" friends may have signed me up.

That's all well and good, except that the emails don't provide any opt-out information. There is a link to their "privacy policy" on their web site which helpfully provides a link for signing up for their emails. But even this web page has no opt-out provision. I'm sorry, but I don't want your emails, and you need to provide me with a way to stop them from coming.

Are you doing this to your members and customers? I recently spoke at ASAE's Marketing & Membership Conference on managing opt-outs, and one of the points we made is that there are some communications that your members should not be able to opt out of. But the reality is, there are some communications that they should be able to opt out of. Are you giving them that option? Or are you just increasing their annoyance with you?

In this post I talked about IT salaries in the general population. At the time I wasn't aware that ASAE had updated their Association Compensation book, but now that I have a copy of it, I can report how the association salaries compare to the at-large IT population.

It's difficult to make an absolute apples-to-apples comparison, but based on the Global Knowledge IT survey and the ASAE study, when comparing the database adminstrator position, the numbers looked like this: $74,263 in the IT survey, $62,092 in the ASAE survey.

That's a $12K disparity, or a nearly 20% premium for the for-profit sector. As I said in the first post, if you're underpaying your technical staff, you're getting what you pay for.

Many associations struggle with the relationship they have with their software vendor. There are many reasons for this, but a primary one is expectations. Too often, associations expect immediate response from their vendors, and perhaps more importantly, they expect immediate resolution to their problems.

Rob Gates of SHRM recently posted the following note to the TMA Resources users group forum, and with his permission, I'm re-posting his thoughts. (Thank you, Rob.)

Rob was responding to a question about how quickly TMAR responds to customer issues. I think Rob has hit it right on the head with his thoughts about how to work with your AMS vendor. (Note: I've edited his post for clarity.)

While the initial response and the resources devoted by TMAR to fix our issues has almost always been at a reasonable level, the actual resolution times have at times been much longer than one would hope.  We have a high level of complexity in our setups and operation which has made resolving issues a lot more complicated than for many customers.  So while TMAR has responded quickly, that doesn't mean issues have been resolved quickly. 

What has been very helpful for us has been maintaining very strong lines of communication with our account rep - adjusting priorities, working together to resolve things, negotiating workarounds, etc.  Also, being thorough in your issue reporting speeds things up - providing specific examples of the issue, details of screen names or tables affected, patterns you've identified, processes involved, details on any environmental changes, etc.  The more information provided up front, the less time will be spent going back and forth to gather than information. We've also often had faster responses on workarounds than on actual solutions - and if your organization can be comfortable with workarounds (scheduled data correction scripts, etc) and more patient for root cause fixes, that will make life smoother for your customer service experience.  Finally, being fair and balanced in your rating of issues helps.  Labeling every issue you report as critical or catastrophic when they may not really be such in the bigger picture makes it hard for them to know when an issue really *is* critical or catastrophic.

Rob highlights some important points, including:

1. Communicating clearly to the vendor what the issue is, including providing specific examples, screenshots, patterns, etc.
2. Being flexible enough to accept workarounds when necessary.
3. Being far about what is critical vs. what is merely nice to have.

Long-term success with your AMS is in very high degree dependent upon a positive relationship with your AMS vendor. Rob's tips are worth serious consideration.