Automating confusion

Everyone wants the automated report.

Click once.
Board-ready PDF.
Done.

But here's the uncomfortable truth:

You can't automate what you haven't defined.

If "new member" means three different things depending on who's in the room, your CRM can't save you.
It will happily calculate the wrong thing forever.

Automation doesn't create clarity.
It amplifies whatever clarity -- or confusion -- already exists.

Imagine printing out that report and reviewing it line-by-line.

How would you know if each contact (or contribution, or membership) really belongs?

Once you can explain that cleanly to a human being, then you earn the automation in the CRM.

Otherwise you're just speeding up the chaos.

- A.

When it all feels urgent

I've been managing CRM systems in and for nonprofits for over 20 years.

Which means I've seen this pattern more times than I can count:

At some point, the pressure spikes.

The board wants numbers.
A funder wants a report.
Membership renewals are lagging.
Someone just discovered that "the system" isn't doing what they assumed it was doing.

And suddenly it all feels urgent.

Here's the uncomfortable truth:

When everything feels urgent, you don't have a performance problem.
You have a capacity problem.

Demands have exceeded the container.

And once that happens, no amount of personal heroics will fix it.

So what do you do?

First, admit reality: not all of this is getting done right now.

That's not failure. That's math.

Second, choose one thing.

Not the loudest thing.
Not the thing that flatters your competence.
The thing that actually reduces risk or restores stability.

Then focus on it fully.

The fastest way to stay stuck is to half-do six things at once.

Finally, decide what doesn't require you.

Some tasks need your judgment.
Some need outside help.
Some just need to be "good enough" so the organization can breathe again.

Perfection is a luxury good. Stability is not.

Here's the thing:

Chaos spreads when no one chooses.
It shrinks the moment someone does.

All the best,
A.

Will this age well?

"How to group your contacts" can sound like a tooling question.

Should you use Groups?
or Tags?
Or maybe Relationships?

But there's a more important concern:

How well will these markers age?

I mean, a year from now:

• Will your "Major Donors" group have the same definition of "major"?

• Will everyone know what that "Partner" relationship type means?

• Will that tag you created today have been kept up to date?

If not, your short-term solution can create long-term confusion.

Because meanings change over time, and meaningless data erodes trust.

Here's the thing:

Next time you create a new marker for your contacts (group, tag, relationship type, whatever), ask yourself:

Can you define it clearly enough that every staff member will apply it the same way for all contacts over the next few years?

If not, just throw some contacts into a temporary group and be done with it.

Short-term needs deserve short-term solutions.
Long-term sanity demands forethought.

All the best,
A.

Clarity beats cleverness

Most CRM problems aren’t caused by bad tools.

They’re caused by unclear expectations.

When people don’t know what a system is for, every report looks wrong and every change feels risky.

Clarity first.
Then configuration.

- A.

Simple constraints

A client of mine is setting up their CRM for outbound text messaging.

Not because it's trendy.
They just realized email and paper mail don't work for a lot of people with disabilities -- their core audience.

Once that was clear, the rest was easy.
The tool choice.
The configuration.
Even the learning curve.

Here's the thing:

Good strategy often looks like a clever solution.
But it usually starts as a simple constraint:

"This has to work for the people we serve."

Everything else is secondary.

- A.

P.S. Thanks to list reader Kim for the discussion that led to today’s email!

A little validation

Years ago:

I was the CRM director for a nonprofit that produced a lot of large events, often on short notice.

At our evening event meetings, each department head would report on their areas, including important details like how many hotel rooms we had used, how many airport pickups we expected tomorrow, no-show counts, banquet seating, and more.

At one of my first meetings, the event director turned to me after all the reports and said, "Okay Allen. Validation?"

I said, "Well, I really think you're doing a great job, Frank."

That got a laugh.

But what Frank wanted was just a sanity check -- do the numbers line up with what we have in our systems? Is anything wildly out of kilter?

Frank understood that in a fast-moving operation we couldn't expect 100% accurate numbers at every moment. But we needed to have a general impression that we were reasonably on target.

Today:

A client of mine said to me, essentially,

I probably can't identify everyone who's interested in our upcoming program.
But I think there's good reason to believe that this group over here clicked through to read our announcement about it.
How can I easily identify most of those people so I can highlight it again to them in an upcoming mailing?

She had already done some data validation of her own -- knowing that 100% certainty was neither possible nor required.

Now she was looking to leverage that information into increased attention on the program.

Perfect.

Imperfectly, uncertainly, perfect.

Because a little validation goes a long way.

All the best,
A.

The “right way”

Imagine you hated Windows (as I do)
and weren't really a fan of Apple (as I'm not)
and were something of Linux zealot (as I am)

and you needed to buy your kid a cheap but reliable laptop for school (as I did).

What's the "right thing" to do?

• Fight the good fight, and send her off with a laptop that fulfills your platonic ideals of purity?

• Or get her one that "just works" for everything she actually needs?

Yeah, get her Windows (as I did).

Here's the thing:

The "right way" can mean a lot of things.

The one that matters most is:
"The way that gets the job done. The way your people can understand."

Lose sight of that, and you don't have a solution.
You have a hobby.

- A.

Security is boring

Talking about website security is boring.

Getting hacked is exciting!
Just not especially enjoyable.

There is a simple way to shut down some of the most common tricks scammers and spammers are using:

Turn on two-factor authentication for staff users.

If you’re on WordPress, the WordFence plugin makes this easy -- and it’s free.

Once it’s installed, the only real work is asking your staff to start using it.

But let's make that easy too:

Here’s a 5-minute video I recorded for a client last week, showing just how simple it really is (for them and for you).

Please give it a thought, and if you’re still not sure, shoot me a reply about what’s holding you back.

All the best,
A.

Sanity needs predictability

On a coaching call today, a client and I explored changing how CiviCRM auto-creates contribution soft-credits based on contact relationships.

It made sense -- to her and to me. But we paused, and she asked a very smart question:

"Should we just do this now, or should I check with my team lead first?"

That's gold, right there. And here's why:

This isn't a change to one or two records. It's a change to configuration -- one that could generate hundreds of new soft-credits in a short time, when nobody's looking.

Meanwhile, other staff are already relying on soft-credit data to make important decisions.

So we agreed on a quick sanity check: run it by one or two teammates first.

Here's the thing:

Even if you've got the best idea in the world, having it show up as a surprise for others is almost guaranteed to cause stress and confusion.

Staff sanity depends on predictable systems.

Changes that affect large swaths of system behavior -- or appear to -- need warning, context, and consent.

All the best,
A.

The grind, and the win.

Some days you get a lot done
and still feel strangely unmoved.

Emails sent.
Meetings held.
Reports delivered.

That’s maintenance.
It’s a grind, but it has to happen.

Real satisfaction comes from other things, which often take time to show up:

Fewer surprises,
clearer expectations,
or people knowing what to do next without asking.

That's progress.
It has to happen too, eventually, and it’s feels like winning.

Both matter. But they’re not the same thing.

If today felt busy but unsatisfying, you were probably doing maintenance, not progress.

That’s okay. Maintenance keeps things from falling apart.

Just don’t confuse it with progress.

All the best,
A.

Crisis? Calm.

Calm is not the absence of crisis.

It's the ability to stay oriented while things are going wrong.
It's the nervous system saying, "I see the fire -- and I know where the exits are."
It's not silence. It's acknowledgement without panic.

Getting there is a matter of practice -- not perfection.

If you're facing your challenges with agency,
saying, "Okay, I'll figure this out,"
picking apart the crisis to find what's actionable,

then you're already on your way.

All the best,
A.

Familiar problems

A funny thing happened after I sent this email a few days ago.

A longtime client wrote back, laughing, half-convinced I'd written it about them.

I hadn't.

But it felt that way to them, because it sounded exactly like a conversation we'd had before.

That's the part worth noticing.

Most of the time, our challenges don't feel generic. They feel personal. Unique. A little embarrassing. Like maybe everyone else has this figured out except us.

But step back far enough, and you start to see the pattern:

Different organizations.
Different people.
Same underlying struggles.

Unclear definitions.
Reports that feel off.
Metrics that don't quite match reality.

When someone recognizes themselves in a story that wasn't written about them, that's usually a sign of something important:

The problem isn't you.
It's just the stage of the progress you're in.

Progress doesn't come from solving a one-off mystery. It comes from realizing that other people have been here before, that there’s a pattern worth noticing -- and that there is a next step forward.

That's why these emails resonate, when they do. Not because they're clever, but because they're familiar.

And familiar problems are solvable ones.

-A.

Rubber fish (and what email metrics forgot)

For a long time, many of us have treated mass emailing like net fishing.

Cast the net. Pull it back in. Count what you caught.
Open rate. Click-through rate. Bigger haul = better job.

Those numbers were never perfect, but they were comforting.
They made the work feel concrete. You could see something happen.

That illusion is mostly gone now.

Not because your tools broke. Not because you did something wrong.
But because inbox providers decided -- deliberately -- that they didn’t want to reveal so much about the recpient’s actions anymore.

So the nets came back empty.
Or worse, full of rubber fish.

What’s interesting is what this reveals.

The fishing analogy was never right for email in the first place.
It just looked that way because our tools encouraged us to think in terms of volume, extraction, and immediate yield.

Truth is, email has always been closer to gardening.

You don’t send one message and get a result.
You prepare the soil.
You plant consistently.
You notice who keeps coming back.
You watch what grows over time.

Gardening feels slower. Less decisive. Harder to dashboard. That’s why many of us preferred the fishing story. It let us believe the job was “send more emails” -- when actually it was, and is, “cultivate belonging.”

The death of open and click rates doesn’t take something essential away from you. It removes a distraction.

Email’s real job was never to generate percentages. It was to maintain connection at scale. To remind people they belong here. To invite them into something ongoing.

So if you're mourning the loss of your click-through report's usefulness, I encourage you to try this practical reframe:

Stop asking, after every send, “How did this email perform?”
Start asking, once a week, “Who showed up again?”

Who replied.
Who registered.
Who donated twice.
Who came back after going quiet.
Who forwarded it to a colleague and said, “You should see this.”

Those are gardening signals. They’re quieter. But they’re real.

Fishing is seductive because it promises fast feedback.
Gardening is steadier because it works with how humans actually behave.

Email is still doing its job.
With the loss of useful open-rates and CTR, we’re just finally being nudged to notice what the job always was.

All the best,
A.

"What’s wrong with this report?"

Here’s a familiar moment.

A meeting is coming up. Someone asks for an “accurate” membership report.
The numbers matter. The confidence matters more.

You pull the report -- and hesitate.
Something feels off. Or at least, you’re not sure you fully trust what you’re seeing.

What's going on?

I mean, it sounds like a reporting problem.

But what if it's really ... a communication problem?

Here's what I mean:

Even the best CRM doesn't really "know what you want." It just stores exactly what was entered, and then answers exactly the questions you ask -- not the one you mean.

When a report feels wrong, that's usually a sign to slow down and ask two important questions:

1. What does the CRM believe is true? (Bob's missing from the report? OK, does the CRM think Bob is a member?)

2. What is the report actually doing? (Bob's missing from the report? Well, is the report really designed to show members like Bob?)

So when I say "communication problem," I mean: entering accurate data into the system; and carefully defining your question (the report) so the CRM answers the question you intend to ask.

BTW, this isn't just a CRM thing.

Even two humans talking it through in person will often need several passes to get aligned. "Show me a list of members from last year" can have many subtly different meanings.

The cool thing is: While those two people can get bogged down over why it seems so hard to communicate, your CRM will happily give you the answers you want -- as long you give it accurate data and understand exactly what you're asking it in reports.

That "slow down and clarify" work is where sanity starts to appear again.

- A.

The meaningless metric

Say I have a goal to lose 10 pounds.

So I promise myself to walk a mile every day.
And I keep a journal, recording whether I kept that promise.

So far, so good: a goal, and a metric.

Then I notice it’s hard to hit the metric every day.
So I add an incentive: if I walk the mile, I reward myself with a box of donuts.

Months later, I look back.

I hit the metric.
I didn’t hit the goal.

What went wrong?

I stopped pursuing the outcome and started optimizing the proxy.

This is Goodhart’s Law:
“When a measure becomes a target, it ceases to be a good measure.”

The same thing happens in mission-driven work.

We track dollars raised, emails sent, events held, members counted.
Those numbers are useful.
But they are not the mission.

Metrics are tools for steering.
Outcomes are the point.

Don’t confuse the two.

All the best,
A.

They stopped fundraising -- and it worked

This story might not describe your organization.

But the mistake it reveals probably does.

I spoke with a tiny, volunteer-run group last week. No staff. Very little funding. And they'd noticed something uncomfortable: fundraising was costing them more than it was giving them.

Not in fees. In work. In attention. Energy. Goodwill.

So they made a choice. Instead of trying to "fundraise harder," the small group running things each decided to give a little more money themselves -- and eliminated most of the process.

At first glance, that may sound irresponsible. Or unfair. Or "not scalable."

But that reaction assumes the problem is "not enough money".

For them, the problem was simpler: their effort wasn't paying for itself, so they paid another way.

Here's the thing:

This isn't a lesson about volunteers paying for everything. It's about realizing that donations are just one resource.

And it's usually a mistake to expect just one resource to solve all the problems.

Sometimes the right question isn't, "How do we raise more money?"

It's: "What is this process really costing us -- and what would it look like to buy our time back?"

All the best,
A.

ROI without spreadsheets

ROI doesn't require a dashboard.

Most of the time it's just a quiet question in the back of your mind:

Is this worth what it's costing us?

Not just money.
Time. Attention. Goodwill. Momentum.

If a tool, process, or project makes the mission harder to move --
the ROI is negative, even if the line items look fine.

No formulas required.

Just honesty and awareness.

All the best,
A.

Only one of these matters

APIs help software talk to software -- for developers.

KPIs track progress toward a goal -- for managers.

ROI is just asking: Is this worth what it’s costing me?
Time. Money. Energy.

If you’re not writing code, you don’t need to obsess over APIs.
If you’re not running a tightly scoped project, you don’t need to live in KPIs.

But if you care about impact?

You’re already in ROI country -- whether you call it that or not.

All the best,
A.

Major CMS upgrades (Drupal 7, Joomla 3, etc)

It’s an uncomfortable truth that many websites out there are still running on content management system (CMS) packages that have been end-of-life for many months or more.

if that’s you, you should be aware of some things:

• The primary downside of keeping that old CMS is that it’s no longer receiving security updates — so even if there are publicly known security vulnerabilities, the package providers aren’t publishing fixes for them.

• The primary downside of moving away from that old CMS is that often (e.g. Drupal 7, Joomla 3, and others), doing so is not a simple matter of “upgrading” — it requires building an entirely new site, and then moving your old content, data, and configurations into that new site. It’s not a small task to take on.

A few people have asked me recently about how such projects usually work, so I imagine there are others who might like to know. I’m copying here a response (lightly edited for privacy and generalization) I sent this morning to this question.

E. (whose site is on Drupal 7) wrote me to ask, essentially:

Understanding that the Drupal update is not quite the kind of thing that can be done quietly in the background - can you offer any insight as to the possibility of jumping to Drupal 11 versus baby-stepping our way through it so that we can limit the chance of breakage along the way?

Also, I’ve heard that CiviCRM can run well under WordPress. is that a viable option for us compared to Drupal 11?

To this I responded:

The website rebuild (or whatever we might call the work of moving beyond Drupal 7) would amount to the creation of an entirely new site, from scratch, and then moving your content, users, configurations, and CRM data into that site. This is the kind of thing that actually must be done in one go (albeit over a manageable timeline), rather than in incremental steps. In other words, one day your live site is on Drupal 7, and the next day it's on Drupal 11 or WordPress or whatever you decide to go with.

To make it all manageable and predictable, and to minimize the chance for unpleasant surprises under the new system, I would expect such project to proceed as follows (which is how I handle such projects for my clients):

NOTE: The live site ("legacy site") continues to run under Drupal 7 until a final agreed-upon launch date, mentioned below. During this time, you and your users/members continue to use the site normally -- add/modify content, CRM data, etc. without any special concern with regard to this project.

1. Developer builds the new site from scratch, including the creation of the visual theme (deisgn / look-and-feel), major menu structures, etc., as a base to receive the data from the legacy site.

2. Developer clones a snapshot of the live site into a development environment and creates an automated process to migrate all data (content, users, configurations, and CRM data, etc.) into the new site. Because this is an automated process, it can be modified and repeated as needed without the increased turnaround time and human error that a manual process would incur.

3. Developer stages the resulting "new site" online at a temporary URL (e.g. new.yourdomain.org) for your review. You take as much time as you need to review that new site, comparing it to the still-live legacy site if you wish.

4. If you find any errors or concerns, you communicate them to the developer, who modifies the automated process to accommodate those concerns.

5. Steps 3 and 4 repeat as needed until you are confident that the automated process is resulting in a site that meets your satisfaction.

6. You and the developer discuss and agree upon a launch date, when the live site will be replaced by the new site. The launch itself may require a few hours of downtime on the site, in order to ensure all live data is transferred properly.

7. On the agreed-upon launch date, developer places the live site into "under construction mode", clones the live site into the development environment, triggers the automated process, and places the resulting site at the live URL (e.g. yourdomain.org). The "new site" is now live.

8. At this point you should once again take time to give the site a full walk-through for your own assurance that all went well. If anything is amiss (which is unlikely because the new site was built with the same automated process which you've already reviewed and approved), developer can make case-by-case fixes on the live site to address your concerns.

Because that's an iterative process with active review on your part and automation of the major components, this approach has a track record of providing solid and reliable results.

As for WordPress: yes, I think it's a good candidate for your consideration. From many of my clients, WordPress can actually be a better fit than Drupal 11, which has (unlike Drupal 7) become much more focused on being a great platform for large commercial operations with significant in-house development talent or large budgets for agency-provided tech support. WordPress, on the other hand, still aims to be a good fit for smaller organizations with simpler needs. The difference lies in the underlying technology, which is (by design) much more specialized on the Drupal side and much more straightforward on the WordPress side.

Because of that difference, it's true that over the past few years, I’ve noticed that most of my clients are running CiviCRM under WordPress rather than under Drupal.

I hope this is all helpful. Please let me know if you have more questions about it!

Here’s the thing:

Obviously this is no small undertaking.

But considering the security downsides of remaining with an end-of-life CMS package, it’s worth taking seriously.

And it’s quite do-able, and is being done successfully by orgs very much like yours.

The keys to preserving sanity and reliability in such an effort are care, good planning, and experienced technical help.

All the best,
A.

Documenting user permissions

Active documentation and careful thinking are an important part of removing chaos from your work.

A great example is in keeping track of who can do what in your CRM and other tools.

Keeping an active User Permissions policy document can save you and your users a lot of headache by removing uncertainty and preventing mistakes.

Since several people have asked me for an example recently, I'm now sharing one here on my Resources page. This one is derived from a real-world organization who recently went through this process with me. It’s also annotated with instructions for re-use, so you can get started quickly.

Take a look when you get a chance.

It may just help you to save a lot of the trouble that comes with playing it by ear.

All the best,
A.