Let’s face it, sometimes there is a mismatch between a person’s abilities or attitude, and the needs of the job. And when that mismatch occurs and can’t be remediated, it’s time to help that person find a new job.

But too often, for fear of looking like the bad guy, or just doing something that makes us uncomfortable, we hold on to staff that we know ultimately are causing more trouble than good. I was talking with David Gammel about this concept recently, and he pointed out that keeping bad staff is a lot like wearing your clothes when swimming: While it may feel better to jump into the water fully clothed, in very short order the wet clothes will start to wear you down and the experience will quickly become exhausting.

I’ve had the distinct displeasure of having to fire more than a few people in my time as a manager. But I can say that as painful as it was to do it, it was far better than the alternative of hanging on to someone who didn’t belong in the job. And in at least one case, someone I helped leave an organization actually told me it was the best thing that happened to him. He was just too afraid to make the move himself and I was able to help him make that move.

So ask yourself: Are you swimming with your clothes on?

I’ve posted a new article on my website, entitled “Establishing a Contact Tracking Policy.”

Of course, if you’re already on my announcements list, you would have received notice of this new article right in your email box.

Not signed up yet? Sign up here.

Yes, you read that right. When selling anything online, whether it’s membership joins, renewals, event registration, or product sales, you should collect as LITTLE information as possible. What I mean by this is that your sales process should be as simple as possible and present as few hurdles as possible to making the sale.

Too many organizations believe that while they’re asking for the sale, they should just go ahead and ask for some additional information. For example, I’ve worked with associations which, as part of the membership application process, ask for dozens of demographics data points (e.g., size of organization, focus of work, etc.) that are not relevant to whether or not the buyer can become a member. In other words, the association would accept the organization as a member regardless of what the answers to these questions were. But the association figures they might as well collect that information now, while they’ve got the potential member online.

I think that’s a mistake.

The first rule of a sale is to get the money. Everything else can come later. As I always tell my clients, the ideal sale is when a customer says “I want that,” and you say “Here you go,” and they pay. If you really need to gather that other information, gather it later, once the organization or individual is already a member.

The same goes for event registration. Why can’t we take the event registration now, and then follow up with questions about dietary needs, physical limitations, and free events? Other than things they need to pay for (e.g., primary registration and ticketed events), why do we need all that information right now? Can’t we get the registration and then follow up later? How many sales are we losing because we’re making the process too cumbersome?

This is the last of four case studies on how associations are using business intelligence, about which I presented at a recent ASAE conference. There are a lot of details to these case studies, but since this is a blog, I’m going to keep this at a high level.

The mission of the National Defense Industrial Association is to bring together representatives from the government and the defense industry. NDIA accomplishes this by coordinating over 80 conferences per year. All of these events, as well as NDIA membership, are managed in a single association management system.

NDIA did some “inward looking” and determined that a significant portion of their key buyers audience (government and military personnel) were attending conferences but were not joining as members. NDIA identified over 20,000 individuals within their database with .mil or .gov email addresses that were not members, and developed a process for offering membership to these individuals during the conference registration process.

Ultimately what NDIA did was to develop an online conference registration process that used the registrant’s email address to identify them as a military or government employee. If the email address was .mil or .gov, during the registration process, the system would offer a free membership to the individual, simply by checking a box.

NDIA also developed “one-click” emails that they used in outbound marketing campaigns to sign up these individuals. The result is that in just over a year, NDIA has brought in 7,000 new individual members in this member class, representing a 100% increase.

I’m often asked by my clients, when pulling data, if they should use a report or a query. The answer, of course, is it depends on the final use of the information that is output.

A simple rule of thumb is that if you need to present the data externally (e.g., a membership listing, an event registrants list, badges, or name-tents), you should use a report. Also, if it is data that you pull consistently and frequently over time (e.g., monthly membership data), reports are better than queries.

If the data is only going to be used internally, you can probably use a query.

However, having said that, I strongly encourage my clients to use reports, rather than queries, whenever possible. There are two primary reasons for this:

1. Reports force you to correct the data at the source. Because reports present data that is “static” in the sense that the output cannot be modified (think pdf), if there is an error on the report (e.g., a name is misspelled), then the data must be changed in the database, rather than directly on the report. The result is that the data is correct for the next person that needs it.
2. Different users using the same report should get the same result. Reports typically don’t allow you to change the query source, other than perhaps allowing for certain criteria to be changed at runtime (e.g., entering a date range on a dues renewal report). Because the report is using the same criteria each time it is run, the results will be consistent. Contrast this with a query tool that allows you to change any and all criteria, and you can see where queries can create a lot of consternation among staff if even one query line is different.

So look at the data you’re pulling. Are you using queries more than you should?

This is the third of four case studies on how associations are using business intelligence, about which I presented at a recent ASAE conference. There are a lot of details to these case studies, but since this is a blog, I’m going to keep this at a high level.

The Professional Golfers Association includes a national association as well as 41 sections (think of them as chapters). PGA’s sections are the primary hosts of most of the golf events that occur in the US each year. Amazingly, both the PGA national headquarters and the 41 sections share a single membership database. (That story alone is worthy of an article or two.)

Because all of this information resides in one system, PGA had an opportunity to develop a simple yet very effective business intelligence system that would allow them to display key performance indicators (KPIs) to the 41 sections and headquarters. As Larry Green of PGA explained to me, “The sections always wanted to know how they were doing compared to the other sections. Now they can see for themselves.”

PGA worked with their sections to identify 12 KPIs that would measure the effectiveness of each of the sections (things like course participation). For each KPI, the sections are ranked 1 through 41, and then the 12 KPIs are totaled to provide an overall ranking. All of this information is pulled from the primary membership database, but stored in a separate online business intelligence database that each of the 41 sections can access. The data is updated on a daily basis, and since all the sections share the same membership database, the data is complete and essentially real-time.

Now the sections can instantly view this information and see how they are doing relative to the other sections. And they can learn where they are doing well and where they need to improve, and adjust their programs and activities accordingly.