The AI Worked. We Were Not Ready For It.

I run operations at Habitat for Humanity of Michigan, a state office supporting 43 local Habitat affiliates, and I am building an AI practice for nonprofits alongside it. Over the past year I have built a number of things with AI, and the ones that did not work share a pattern that took me a while to see.

In all of them the tool worked as intended. What I had got wrong was building it ahead of the thing it depended on.

The report with nothing to report

In May I built a daily summary of my own business numbers, covering revenue, active clients, new conversations, newsletter subscribers, and followers. It was waiting for me at six every morning.

Journey to Impact, the AI practice I run alongside the day job, has one client on a fixed monthly retainer. The revenue line is therefore the same number every month. New conversations were often zero, which was the accurate figure at the time. The report was correct, and there was almost nothing in it that could change.

I turned it off in July along with the collector behind it, and I will turn it back on when there is a CRM underneath it and enough happening to be worth reading. The build was about a day of work, which makes it a cheap lesson. The version of this that worries me is the nonprofit signing a three-year contract for a reporting product before it has anything to report.

The easiest item on our list, which was not easy

Last spring I ran an AI audit across five departments at Habitat Michigan and came out of it with 21 opportunities, each scored twice, once for how much it would help and once for how hard it would be to build. The item rated highest impact and lowest difficulty was a searchable place to keep our written procedures, so people stop asking the same three colleagues the same questions. I stand by that score, because the tooling really is straightforward.

What the score does not capture is that a searchable library of procedures assumes you have written procedures, current enough to be worth searching.

I found this out while building something adjacent to it. I wanted a set of plain documents describing the organization, so that any of our staff could hand them to an AI tool and get answers that fit us rather than a generic nonprofit. The staff section had been written during those audit interviews in the spring. By the time I picked it up in August, four of the people named in it had left and one who had joined was not in it at all. The program structure I had written down was tidy on paper and did not match how the work is divided between people.

Building the search tool would have taken an afternoon. Getting to the point where it has something accurate to read is still going. That second thing is a documentation project, and it has never been anybody’s priority because it has never been the most urgent thing in a given week.

The rollout that assumed we could roll out

I designed our staff training plan as a phased introduction. One department first, learn from that group, then widen it out. That is the cautious approach you are supposed to take, and I built the whole sequence around it.

Then I checked the plan we actually pay for. The setting is organization-wide, on or off for everybody, and the per-department version belongs to a more expensive tier. There was no way to give it to one department and hold it back from the rest.

The fix works and it is what we are doing, which is to control who gets trained rather than who gets access. But I had written a sequence that rested on a capability I had never confirmed we had, and I found that out at the point where I was ready to start.

The list that outran us

The fourth one is the audit itself.

Twenty-one opportunities came out of it, and twelve of them were rated high impact. Over the following months, working from the low-difficulty end, we finished about four. The other seventeen are still on the list.

I do not regret running the audit and I would run it again. What I would change is what I did with the output. A list of 21 items handed to a lean team with no technical staff functions as a backlog, and a backlog has a cost of its own. Everyone can see the seventeen things that are not being done. I had built a plan sized for an organization with more capacity than the one I actually work in.

The four, side by side

Each of these depended on something else already being in place, and in each case that thing was missing.

• A daily business metrics report. It assumed enough activity for the numbers to move. What was there was one client on a fixed retainer, and months where new conversations were genuinely zero.
• A searchable library of our written procedures. It assumed written procedures current enough to search. What was there was a staff section four departures out of date, and a program structure that did not match how the work is divided.
• A phased department-by-department rollout. It assumed a plan that supports per-department access. What was there was an organization-wide setting, with per-department available on a higher tier.
• A 21-item opportunity roadmap. It assumed capacity to work through 21 items. What was there was a lean team with no technical staff, which finished about four.

The question I did not ask

Every one of these would have been caught by writing down what the thing reads from, and then checking whether that exists and is current.

It sounds too simple to be worth writing down as a step.

Why nonprofits run into this more than most

Starting with AI is cheap and quick. Building the foundations underneath it is slow, and that work is rarely funded. I have never seen a grant that pays for writing down how your programs work, and I have never been asked to present a documentation project at a board meeting.

There is also real pressure pointing the other way. A funder asks what you are doing with AI, a board member forwards an article, and the easiest thing to show either of them is a tool. Explaining that you spent two months getting your program records accurate is a harder conversation, even though it is the work that makes the tool function at all.

Lean teams also do not have anyone whose job includes keeping written things current. Staff change, program names and reporting requirements shift with grant cycles, and a good deal of how the organization runs lives in the heads of two or three long-tenured people and has never been written down anywhere. So the gap between what your documents say and what is true tends to open without anyone noticing, and it takes a while to close.

Four things I do differently now

1. Write down what it reads from, then confirm that thing exists and is current. This would have caught three of the four above.
2. If the answer contains “our procedures” or “our records,” that is the project. The AI tool is the small piece at the end of it.
3. Confirm what your plan supports at the start, before you design around it.
4. Build the smallest version that runs on what you have today, instead of the version that would be right if the foundations were in place.

What I would keep

The question to ask at the start is what does this depend on, and do we have it. Documentation at a nonprofit never reaches a finished state, so this is a question to ask while you build.

In almost every case where AI disappointed me, the AI worked and the foundation underneath it was not there yet. That is a much more fixable problem, and fixing it requires no technical skill at all.

If you want the structured version of how to begin, my AI Implementation Playbook for nonprofits is free: https://wendyclow.gumroad.com/l/xpgoti