The other day my two-year old daughter and I walked to our mailbox to mail a letter. The mailbox is about 50 yards from my house, and about halfway to the mailbox, my daughter took off running to the mailbox with the letter in her hand. I stopped and watched as she went to the mailbox, reached up on her tiptoes to open the mailbox, put the letter in, pushed the mailbox door closed, and went up on her tiptoes again to push the flag up. She turned to me, smiled, and ran back to where I was standing.

I was stunned. I had never seen that before and I began to wonder how she knew what to do. And then it struck me. Whenever we had mail to send, either my wife or I would walk down to the mailbox with her, and do exactly what she did. We had modeled the behavior for her, and now she was doing it on her own.

This is exactly what we need to be doing with our employees, whether it's for data management, or membership recruitment, or customer service. Far too often we believe that we can simply stick our employees in a training class and, voila, out comes a well-trained staffer who can do whatever it was we were training them to do. But can you imagine for one minute that my two-year old daughter could have done what she did if I had "trained" her to do it, rather than modeling the behavior.

Look around your organization. Are you simply training your employees, or are you modeling the behavior you expect from them?

No, I'm not talking about data back up this time. I'm talking about having a back up plan for how you will handle incoming calls when your system is "down."

I called my doctor today to make an appointment. I was immediately told "Our system is down, can you call back in an hour?"

Really? A customer is calling you, to spend money on you, and your response is "call back later"? How about "Let me take your name and number, and once our system is operational again, I'll call you to make the appointment."

How about your association? Do you have a plan in place to manage those inevitable times when your system is inaccessible? If your database wasn't working, would you know what to do when users call to register for a meeting, join or renew membership, or otherwise do business with you? Or, like my doctor's office, do you simply say "I'm sorry, I can't help you right now. Please call back later."?

Recently while driving along the GW Parkway (just outside DC) I came upon an electronic road sign (you know, the kind that tells you about upcoming events or road construction).  The sign read (and I quote): "On or about August 19th, roadwork begins."

That's it.

Ntohing about what kinds of roadwork. Nothing about how it would affect the drive. Nothing about whether or not I should plan to take alternative routes. Just "roadwork begins."

It struck me that this is often how we communicate during projects. For example, we tell staff "We'll be replacing our old database with a new one" and that's the extent of the information we provide. No information on how. Nothing on how this will affect my job, or whether or not I should change how I do things.

When launching a new project that will affect staff (whether it's a new database, a new HR policy, or a new event), we need to provide as much information as possible, and we need to help staff understand how the change will affect them (if at all). This means not only a "kickoff" meeting but also "check in" meetings throughout the life of the project.

So ask yourself: Are you telling your staff "roadwork begins" without giving them any details?

One of the more common mistakes I see is organizations assuming that they can add new technology without considering what changes in workload the new technology will require.

For example, one of my clients was considering developing a lockbox process for their AMS. Through this process, their bank would accept all of their incoming payments and develop an electronic file that could be uploaded into the AMS, thus minimizing the need for manual data entry on the part of staff. This is a great idea, and many associations have executed it successfully. But what my client hadn't considered was how the lockbox process would change how they do things.

From my client's point of view, this new process would save staff time. But what they hadn't discussed was who would manage the new process, what skills that would require, and what additional work that would add to some staff person's plate.

As I note here, data management is a process, not an event. And even when we add new technology to make our lives easier, we have to consider the "unintended consequences" that any new technology brings. There will be changes in process. There may be changes in workload. And new technology may require new skill sets that we don't have on staff. All of this needs to be considered and discussed when new technologies are introduced.

Many years ago while working as an association staffer, I was trying to kill some time on a Friday afternoon. I was planning on leaving at 2pm to head to the beach for the weekend, and with only an hour left in the day, rather than starting a new project, I decided to dig around in my AMS.

I came across a menu item that I had not seen before, and based on what it said, I thought it would be cool to try it. (I can't remember what it actually did, but at the time, I was sure I needed to try it right now!) So I ran the process.

Ten minutes later, my IT director came into my office and asked "Have you been playing in the database? Because I just discovered that several tables have just been corrupted."

Yes, what I had done had destroyed several tables of data. Luckily, my IT director had back-ups, and within about four hours was able to re-build the lost tables. He did all this while I happily headed to the beach to start my weekend early.

The moral of the story? Never test in a live environment. Of course, this assumes you have a test environment to play in.

I'm astounded to learn that many associations still don't have test instances of their database available for testing, training, and documentation. I think this is almost as criminal as not having a well-tested back-up system in place, as the story above illustrates.

So, does your association have a test environment of its AMS? And if it doesn't, why not?

"So when we get our new database we'll be done, right?"

I can't tell you how many times I've heard this from my clients. And I always tell them, "No, we'll just be getting started."

Whether you're buying a new data management system, or have had your current AMS for years, the reality is that you're never "done." Managing a database is a process, not an event.

This message is especially important for senior management and board-level directors to hear. Too often they believe that once the AMS selection process is complete, all of our problems will go away. Well, frequently, the real problem is not just the technology, but how we're managing the data from day to day.

This is why I tell my clients that they should run a database PR campaign. They should constantly reinforce to all users that the database is a "living document," ever-changing and requiring constant attention. This is active management.

Because data management is a process, not an event.

When I talk with my clients about how they process orders at their organization (whether it be membership joins and renewals, product sales, event registrations, or something else), I always emphasize that it is most important to make it easy for the customer to buy from you. As I like to put it, the ideal transaction is one where the customer simply has to think "I want to buy from you," and the transaction is completed!

We're not quite there yet, but associations continue to make things harder than they need to be. A great example is an online membership join process. Too often I see my clients putting up membership join forms that ask all kinds of demographic questions about the individual and/or his or her company. Unless you need that information at the very moment of joining (i.e., the demographic data actually affects the membership dues rate), you shouldn't ask for it yet. Ask for as little information as possible that will allow you to complete the sale, and then go back to collect the other data.

While that may sound like extra work…well, it is. But the idea is to make the sale first and then collect the data later. Every question you ask during the sales process increases the likelihood of the person abandoning the purchase.

David Gammel at High Context Consulting has a great blog post with a real-life example of shopping cart that makes it incredibly easy to buy. While this example may not translate directly to association sales, it is a great illustration of making it easy, and, as David puts it, "getting out of the way."

Members Only Software has been running a quarterly giveaway of their association management software to "needy" organizations. According to the press release I received, United Cerebral Palsy of Michigan received their free software last Winter and has been live since April 2007.

As I wrote here, "free" software can be a risky proposition for associations, but if you understand the risks going in, there's nothing inherently wrong with free software.

For more information on the program, contact Doria Howe at doria (at) membersonlysoftware.com or 202-332-9662.

Kudos to Members Only Software for "giving back" to the community.

Vinay Kumar of GRC Direct had a great post on one of the ASAE listservers a few weeks back about a service from Melissa Data called mCOA.

In a nutshell, mCOA is designed to augment the US Post Offices's NCOA (National Change of Address) service. As Vinay pointed out on his post, this is a nice addition to the NCOA service to help you clean up your mailing lists.

Cleaning your data should be something you do with relative frequency. If you snail-mail a high volume of mail, combining NCOA with mCOA might make a lot of sense. Talk to your mailhouse about this service.

ARC Solutions is one of the many AMS vendors that I track (full disclosure: one of my clients uses them for their AMS). So I was intrigued and pleasantly surprised to hear that ARC has secured $2 million in venture capital funding to support the roll-out of their new product Polaris. I've seen an early demo of the product and it looks promising. ARC is selling it in a SaaS model (see salesforce.com as an example) so the pricing could be very association-friendly.

I'll be keeping an eye on the product and the company and will report back when I've learned more.