There's an old saying: "There are those that back up, and those that will." And as I mention here, it's critically important to back up your data. I learned the lesson the hard way, many years ago, when I deleted all the data from a database I had been working on for two days. Ever since then, I've always backed up my database, typically once a week, sometimes more frequently. I also back up everything on my computer's hard drive on a regular basis.

But even old-hands learn the hard way sometimes. The other day I posted an item on this blog. An inappropriate comment made it to the comments section of the post. I went to delete the comment, and wound up accidentally deleting the entire post. And…you guessed it…I have no back up for my blog.

Well, I didn't then. I do now.

So ask yourself: What data at my organization isn't being backed up? Do staff have information on their PCs that isn't part of the back up process? Do we have online tools (e.g., blogs, job boards, web sites) that aren't being backed up? Do you know for sure?

There was a thread on the ASAE technology listserver a few weeks back about whether an association should choose an AMS based on .net or PHP or something else. There was some interesting responses, but one of the best was from Bob Nedbal, Director of IT and Web Services, at the American Educational Research Association.

Bob wrote, in part: "If you want to provide a great deal of self-service, commerce and personalized information to users of the website, write descriptive examples of what you would like members and partners to be able to do and prioritize them. Use this as part of your vendor evaluation, identifying what they do "out of the box" vs. what needs to be built."

This is great advice. Too often when associations evaluate AMS systems, they don't give enough consideration to what the member or customer experience will be like. And even if they are thinking about it, they haven't articluated it clearly enough to be able to communicate their needs to the AMS vendor. As Bob suggests, writing up scenarios and walking through them with the vendor will go a long way to communicating what is needed, and might help you avoid choosing a solution that isn't a good fit.

And as for .net vs PHP and the rest. Well, in a sense, it doesn't matter. Does the tool deliver what you and your customers need? Is it easy to use? Is it scalable and upgradeable? These are the important questions. Obviously technology does matter. But too often we get caught up in the technology and forget that it's simply a tool.

It was 20 years ago this June that I took a summer job at my college alumni association. I had no idea I would some day be in the association management business, but there I was, doing "data entry" for an association. And what did data entry entail, exactly? Well, it was three other guys and me sitting in a room, with books the size of an average desk. Within each book was a computer printout of thousands of names and addresses of alumni. Our job was to take the returned mail from a recent mailing, find the name in one of the massive books, scratch it out with a red pen, and then write in the correct information next to the address block. Mind you, this all had to occur within a space of approximately 1 inch by 1 inch.

How is this data entry, you ask? Well, once we were done, the books were forwarded to a central data entry area, where real data entry clerks looked up the names and made the address changes on the central database, presumably being able to decipher my chicken-scratch corrections. Meanwhile, at each desk within the association sat computer terminals that were never turned on. My fellow worker commented one day to me: "Those have got to be the most expensive paperweights in history."

Fast forward 20 years, and what do I see happening in associations every day? We've moved on from the desk-size book of addresses. But we haven't really improved our efficiency in data processing. We've traded the big books in for email. Now when someone receives an address change, they type it up in an email and email it to the data entry clerk. Then, some day, when he or she can get to it, it's entered into the central database. Sound familiar?

At the alumni association, we weren't allowed to touch the computers, because we didn't know how to use them. And heaven forfend we get trained. Better to just make changes on paper and forward it to the person who knows what they're doing in the database. The same thing is happening in thousands of associations around the country. This is a trust issue, as I write here.

It's time for associations to acknowledge that more staff can work in the database if we're willing to make the effort to train staff on how to use the database. We also have to acknowledge that with more staff will come more errors, but the increase in efficiency (if done right) will far outweigh any errors that occur.

How about your organization? Are you still scratching out addresses with red pen and forwarding it to central data entry? If you really want to be successful, your data entry should be decentralized, as I write here.

Update: Many thanks to Lisa Junker at ASAE for sending me her copy of this post.

Update: Many thanks to Lisa Junker at ASAE for sending me her copy of this post. 

I published a post yesterday about doing data entry at my alumni association. I've accidentally deleted that post and there is no back-up for it. (Don't ask, I'll explain in a later post.)

If you happen to have the data entry post in your RSS reader and can email the contents of the post, I would be ever so grateful. Please email me at wes at effectivedatabase dot com.

I've ranted in the past about getting your mass emails right.

Well it seems that even the big guys have problems when it comes to this stuff. I received an email from Gartner today offering a free report. I clicked through and got to the web page that was offering a pdf download of the report. I clicked on the link and…voila! HTTP 500 Internal Server Error!

Four links on that page, four errors. And hours later it's still not fixed.

So it turns out it's not just us little guys that have problems with our links.

On Wednesday of this week I spoke at ASAE's Marketing & Membership Conference. Another sold-out show for the MMC, which has become a premier event for membership and marketing folks.

My presentation, along with Mary Pat Paris of IRP, was on managing the email opt-out process. One of the points that struck me as particularly salient was the struggle associations have with managing multiple data management systems. Every association has (or should have) a primary association management system that at a minimum contains membership contact information. But it is becoming increasingly common for associations to have multiple databases in place to manage different functionality. Examples include external registration systems, PAC management systems, and broadcast email tools.

Whether you have two or two hundred disparate systems, what is most critical is having a process for managing the synchronization of these disparate systems. Ultimately what that requires is three things:

1. Identifying which data elements should be shared between the systems.
2. Identifying which direction the data should be shared (one-way or two-way).
3. Establishing a process for managing the sharing of this data.

My suspicion, based on direct observation as well as discussions at these types of meetings, is that few associations are considering any of these three points when adding new data management systems to the mix. Unfortunately what happens too often is that new systems are added (e.g., outside registration company) without consideration for what or how the data should be shared. It's only after the new system is in place that people start asking "Hey, how do we get that data back into our main system?"

Does your organization have this process under control? If not, start by identifying all the disparate systems you have. Then walk through the three steps above and establish a data-sharing process. You'll be happy you did.

On Nick Senzee's blog, he writes about his experience with ASAE's Annual Meeting registration process. Nick raises some good points about the registration process that all associations should be aware of.

Nick's primary complaint is that ASAE asks a lot of intrusive questions during the registration process. Ben Martin adds that ASAE should be able to save that information from year-to-year, so they don't have to ask again. They both have good points. I'll address Nick's first:

I've always said that the ideal sale (be it membership, events, products, certification, or anything else) would go like this:

Customer: "I want that."

Association: "Done."

In other words, all the customer has to say is "I want that," and the association can sell it to them, because they have all the data they need (e.g., credit card info, contact info, etc.). Obviously that's a little utopian, but we can get much closer to that than most of us do right now. For example, with ASAE, why do those questions need to be asked during the registration process? Why can't they take the meeting registration, then follow up with those questions after-the-fact? Sure, they may get less compliance this way (less data) but I'd bet they get more registrations. In other words, asking for more information during the sale depresses the total number of sales.

Lesson to us all: Don't set up unnecessary hurdles when making the sale. This goes for membership joins, too. Need information about the company (staff size, budget, market served, etc.)? Ask after you make the sale, not during the sale.

On to Ben: Ben suggests ASAE keep this data on file. I think he's right, but with a caveat. ASAE still needs to ask Ben, after the sale, if the data they have on file is correct. A lot can change in a year. For example, one of the questions ASAE asks is about your role in the buying decision. That could change from year-to-year. Same for salary. So the data needs to be updated. But I agree with Ben, why ask me to fill it all out again, if most (if not all) of the answers are the same.

What practices do you have in place during the sales process that are actually hurting sales? And what can you do to fix them?

You may recall an episode of Seinfeld where Jerry is having his kitchen re-done. Whenever Jerry asks his carpenter what he should do, the carpenter offers all kinds of options and then says "I can do whatever you want me to." Jerry gets so exasparated that he tells the carpenter to do whatever he wants. In the end, Jerry winds up with the exact same kitchen he had.

I see this happen too often with technology consultants. I was working with a financial software consultant, in conjunction with a client engagement, and whenever the client would ask the consultant a question, his response was "I can do whatever you want me to do."

That kind of response is useless to the client. The client wants to know what she should do, not that the consultant can do whatever she wants. If she just needs someone to implement her ideas, she can hire a mechanic, not a consultant. A consultant's job is to provide you with answers, not just "Tell me what to do and I'll do it."

Are your consultants providing you with guidance and answers? Is your AMS provider?

I'll be speaking at ASAE's Marketing & Membership Conference in Baltimore next Wednesday, June 20. General information on the conference here. Program details here.

If you're at the conference, please stop by and say hello to me after my session at 10.15am.

As I mention in this post, having an issue tracker is a key tool for managing all the different issues that arise during the implementation and live usage of an association management system. But for some reason, until just recently, most of the AMS providers did not provide any kind of online system for submitting bugs, issues, requests, etc. I would guess that it's just in the past year or so that the bigger players, like TMAR, Protech, ACGI, and Avectra, have instituted and successfully used online issue tracking systems. I haven't seen any of the "smaller" players, with the exception of perhaps MatrixGroup, implement any kind of online system. As far as I can tell, most are still using the old "Excel spreadsheet back and forth via email" routine.

At this point, with technology as cheap as it is, there's really no excuse not to have an online issue tracking system. They are relatively easy to use, can be made accessible to all, and can serve as a central depository for all kinds of issues. They are especially useful for tracking "wishlist" items that come up, are not critical now, but should be addressed in the future. These kinds of issues typically fall into a black hole if there isn't one place to put them.

These companies all (rightfully) push "centralized data management" as a key benefit to their own systems, yet they're not practicing this in the area of issue management. Ironic, doncha think?