Do we need a fractional CTO to do this?

No. An operations lead or a capable program manager can build the first version with a named owner and about a month of part-time effort. The inventory, the interviews, the drafts, and the review pass are all work your own staff can do. What retained technology leadership adds is upkeep and custody: keeping the systems map current, holding credentials in the organization's name, and making sure the monthly refresh is not the first thing dropped in a busy quarter. Build it yourself first.

Which AI tool should we use?

We are not naming one, because the choice matters less than two properties any candidate needs. Ownership: the documents, recordings, and transcripts are yours, stored under an account in the organization's name. Export: you can get everything out in a standard format, without assistance, at any time. Also insist that answers cite the source document. Beyond that, the discipline of capture, review, and monthly refresh determines the outcome more than the product.

Is this safe for supporter data?

Yes, if you keep supporter data out of it, which is straightforward because the system does not need any. You are documenting how the work is done: the steps in the reconciliation, what the CRM fields mean, who administers which platform, when the contract renews. Write procedures against example records and describe fields rather than pasting their contents. The same rule covers credentials: the documentation names the vault and who has access, never the credentials themselves.

Can we do this without recording people?

Yes, though it costs more time. A twenty-minute narrated walkthrough produces a better first draft than an hour of someone writing their own process from memory, but a colleague taking notes during a live walkthrough works, and so does a rough bullet-point pass turned into a structured runbook. Framing matters more than method. People cooperate when this is clearly about relieving them of being a single point of failure, and resist when it reads as building their replacement.

How long until it pays off?

At the next departure, which in this sector is usually within the year. Smaller payoffs arrive sooner. The first-week inventory routinely surfaces subscriptions nobody uses, accounts registered to people who left, and a contract about to auto-renew that nobody had diaried. Credential custody ends the situation where one person's absence blocks a task. And the first time a staff member covers for a colleague on leave using a runbook rather than a phone call, the value is obvious to everyone who watched.

What is the difference between this and a shared drive?

A shared drive is storage. This is structured, so every recurring task has a runbook, every system a page, and every role a plan, and you can tell what is missing. It is answerable, so a new hire asks how do we do this in their own words and gets your organization's answer with the source shown. And it is maintained, so the monthly refresh flags what has gone stale. Most organizations already have the shared drive. It is where documentation goes to be written once and never read.

The First AI Project a Nonprofit Should Build: Continuity When Staff Leave

Most nonprofits considering a first AI project start at the wrong end. The ideas that come up first are the visible ones: a chatbot on the website, grant applications drafted faster, donor messages personalized at scale. Each of those touches someone outside the organization on day one, which is what makes them a hard place to begin.

There is a better first project, and it is unglamorous. Build the thing that keeps the organization running when a staff member leaves: a record of how the work is done, and a way for the next person to ask questions of it. It uses only material you already own, the people judging it work for you, and someone on your staff will leave this year.

01Why turnover is the technology problem

Your technology problem is usually described as a systems problem. The CRM is a mess, the forms go nowhere, three platforms disagree about the same supporter. Underneath most of those is a staffing fact nobody has written down. The person who knew why the system was set up that way does not work here anymore.

67%
of nonprofit employees surveyed said they were looking for a new job or expected to leave within a year. Whatever any one of them knows about how your systems work is on a shorter clock than the systems themselves, and the person who could write it down is the busiest person in the building.
Candid, 2024 nonprofit employee survey
64%
of nonprofit leaders reported difficulty filling staff vacancies in the past year, nearly two thirds of them. The seat does not refill quickly. The gap between the departure and the replacement is when undocumented work stops happening, and the longer the search runs, the more of it is gone by the time someone arrives.
Center for Effective Philanthropy, State of Nonprofits 2025

What actually leaves with a person

Five things walk out with a person. Only the first is ever on an offboarding form.

01
The passwords. Not the ones in the shared document, which are mostly stale, but the ones in a personal browser profile, the account registered to a personal email address, the two-factor codes on a phone that is about to be handed back.
02
The vendor relationships. The name of the person at the database company who returns calls, the fact that your rate was negotiated and is not the list rate, which contract renews automatically in March.
03
The reason a system is configured the way it is. Every stack has a setting that looks wrong and is load-bearing. When the reason is gone, the next person either preserves it superstitiously or breaks something fixing it.
04
The undocumented monthly routine. The reconciliation, the export, the report that goes to a funder, the list that gets deduplicated before the appeal. Work that only happened because one person remembered it was due.
05
The workaround everyone relies on. The step that is in no process document because it routes around a limitation nobody wants to talk about. It is invisible right up to the week it stops.

None of that is written down, and all of it belongs to the organization rather than the individual.

02Why the plans you already have do not cover it

Many organizations already have two documents that sound like they should cover this. Neither does, and the reassurance they offer is the reason nobody builds the thing that would.

01
The succession plan
What it covers
The executive director, sometimes the finance lead, and the board's own turnover. Who acts in an interim, how the search runs, what the board does in the first ninety days.
What it misses
Everybody else. The program coordinator who built and ran the CRM, the office manager who held the domain registrar login, the development associate who wrote the queries behind every board report. The plan is about authority. The knowledge that runs the place sits several levels below where it looks.
02
The disaster recovery plan
What it covers
Sometimes filed as a business continuity plan. Floods, fires, outages, ransomware, a building you cannot enter. Backups, insurance, an alternate site, the phone tree.
What it misses
A resignation letter. These plans are written for events that are sudden, external, and obviously an emergency. A staff departure is scheduled, internal, and handled as a human resources matter, so it never reaches the document about keeping operations running, even though it removes capability just as completely and far more often.

Turnover is the baseline condition in this sector, and it is the one threat neither plan is written for. Something has to be built for it on purpose.

03What a continuity system actually does

A continuity system has two halves that only work together: capture the work, and train the next person. Capture without training produces an archive nobody reads. Training without capture is the same shoulder-tapping you do now, minus the shoulder.

Half one: capture the work

01
Runbooks for the recurring work
Every task that repeats, written as steps someone competent but new could follow: the monthly reconciliation, the quarterly funder export, the deduplication before an appeal, the year-end close. Each names the system it happens in, the cadence, and what it looks like when it went right.
02
A systems and vendor map
Every platform, subscription, and account. What it is for, who uses it, what data it holds, what it connects to, who administers it, which vendor sells it, when the contract renews. Maintained as things change rather than produced once and framed.
03
Credential custody the organization holds
Accounts in the organization's name, registered to addresses the organization controls, with credentials in a password vault the organization owns and can hand to someone else. A spreadsheet does not count, and neither does a shared login everybody uses because resetting it is a nuisance.
04
A decision log
The shortest and most neglected piece. When a choice gets made, such as this field means that or this integration runs one way on purpose, write a paragraph saying what was decided and why. Six months of these is the difference between a successor who can change something safely and one who is afraid to touch anything.

Half two: train the next person

01
An onboarding path built from what you captured
The new person does not get the whole archive on day one. They get a sequence: what you are responsible for, the four systems you will be in every week, the first routine you will run and who will watch you run it. The sequence comes from the runbooks and the systems map rather than being written separately, which is the only way it stays current.
02
A place to ask how we do things
Somewhere a new hire can type how do we add a recurring donor, or what happens when a grant report is due, and get your organization's answer rather than a general one, with the source document shown alongside so they can read the original and see when it was last touched. The citation is what makes the answer checkable.

Both halves are made of the same material. The capture becomes the training, and the training is trustworthy because it is made only of things people here wrote.

04Why this is the right first AI project

Set this beside the projects usually proposed as a first step.

01
The scope has edges
A finite amount of work about a finite number of systems and roles. You can name what is in it on one page, and you can tell when it is done, which is not true of most things described as an AI initiative.
02
It runs on your own material
Interviews with your staff, your existing documents, your systems. Nothing about your organization is generated from outside knowledge, so there is a real source behind every claim and the failure mode is a stale answer rather than an invented one.
03
The payoff is scheduled
Most technology purchases ask you to believe in a benefit that arrives on no particular date. This one arrives at the next departure, and given the sector's turnover you can plan on that inside a year.
04
The audience is internal
Nothing here is shown to a donor, a client, or a program participant. An imperfect first attempt gets corrected by a colleague in a review pass instead of discovered by a supporter.
05
It makes the later projects possible
Every ambitious thing you might do later depends on institutional knowledge being in a form software can read. Right now most of yours is in people's heads and in documents nobody has opened in two years. Skipping this means every later project starts by doing it badly and in a hurry.

What the AI is actually doing here

The word AI is doing a lot of vague work in this sector right now, so here is what it does in this project. Four jobs, all of them boring, all of them why this is a month of effort rather than a year.

It drafts runbooks from a recorded walkthrough or an interview transcript. Somebody talks through the monthly reconciliation for twenty minutes while doing it, and what comes back is a numbered procedure to correct rather than a blank page to fill.
It turns a folder of stale documents into one current version with the differences flagged. Most organizations have four overlapping versions of the same procedure written in different years. Reconciling them by hand is a week nobody has. A merged draft with the contradictions marked is an afternoon of decisions.
It answers questions using only your documents, and shows which document it used. An answer you cannot trace is a rumor with better formatting.
It flags documentation that has gone quiet. When a system changes and the page describing it has not been touched since, something should say so. Documentation rarely fails by being wrong on the day it is written. It fails by staying still while everything else moves.

Nothing in that list writes to a system, speaks to a supporter, or decides anything. The AI drafts and retrieves. People correct and approve. That division is why this is a safe first project, and a good habit to carry into whatever you build next.

05How to set it up in about a month

This is roughly a month of part-time effort for an organization with a normal stack, and it works best as four weeks with a named owner. The order matters. Every week produces the input for the next one.

01
Inventory
Week one
List every system, account, and subscription, and next to each put who administers it, who uses it, what it costs, and whose email address it is registered to. Pull it from the finance records as well as from memory. The subscriptions nobody remembers are on the card statement. Expect to find at least one account in a former employee's name.
02
Capture
Week two
Sit with the people who do the work and record it, in two formats: an interview about what they are responsible for and what would break without them, and a screen recording of them performing a recurring task while narrating. Half an hour each, scheduled, with their consent, and with a clear statement that the purpose is to relieve them of being a single point of failure. Gather the existing documents in the same week, however scattered.
03
Drafting
Week three
Turn the recordings and the old documents into drafts: one runbook per recurring task, one page per system, a first pass at the decision log from whatever came up in the interviews. This is where AI does most of the work, and the output is a draft. Publish nothing from this week.
04
Review and correction
Week four
The person who does the work reads what was written about their work and fixes it. This cannot be delegated to whoever is running the project, so budget real hours for it. A draft they have corrected is one they will keep current. A draft written about them without their hand on it will be wrong within a month.
05
Custody and access
Then, once
Move the credentials into a vault the organization owns, change registration on any account in a personal name, set permissions so the documentation is readable by everyone who needs it and editable by the people who own each piece, and confirm that at least two people can get into anything critical.
06
The refresh habit
Every month after
Thirty minutes on a standing agenda. What changed, what is now wrong, which page has not been touched since the system it describes was reconfigured, whose responsibilities moved. This is the whole maintenance cost, and skipping it is the only way the project fails. Documentation goes from useful to misleading, and misleading is worse than nothing.

06The nonprofit knowledge transfer plan

The artifact at the center of this fits on a page per role. Fill one out for every position that touches a system, not only the technical ones. The person with the most undocumented routines is rarely the person with the most technical title.

A knowledge transfer plan template: one row per field, what to record in it, and a worked example
Field	What to record	A filled-in example
Role	The position, not the person. Written this way it survives the departure and gets inherited rather than re-created.	Development associate. Reports to the director of development. Covers gift processing and the appeal calendar.
Systems touched	Every platform this role opens, the level of access in each, and whether the role administers it or only uses it.	CRM (administrator), email platform (administrator), donation form (editor), accounting system (read only), shared drive.
Recurring tasks and cadence	Each repeating task, how often, roughly when in the period it falls, and a link to its runbook.	Gift reconciliation, monthly, first week. Deduplication before each appeal. Year-end acknowledgement letters, December.
Credentials held	Which accounts this role holds keys to, where those credentials live, and who else can reach them. Never the credentials themselves.	Four administrator accounts, all in the organization vault, shared with the operations lead. Two-factor on the CRM is on a shared device, not a personal phone.
Vendor contacts and renewals	Named contacts at each vendor, the terms that were negotiated rather than listed, and the date each agreement renews or auto-renews.	CRM account manager, named, renews in March on a nonprofit rate that is not the published one. Email platform renews automatically each January.
Decisions made and why	The configuration choices that look arbitrary and are not, with a sentence of reasoning each. The shortest column and the one successors thank you for.	Custom field holds board-designated gifts because the standard one is not reportable. Sync runs one way on purpose after the duplicates of 2024.
Where the documentation lives	One location, named, that the organization owns and can export from. If the answer is more than one place, that is the finding.	Operations space in the shared drive, folder per system, one runbook per recurring task, all exportable.
Who inherits it	The named person or role that picks this up the day the seat empties, for the interim as well as the eventual hire.	Operations lead holds it in the interim. Director of development owns the decision about what the replacement role covers.

Two checklists turn the template into something that happens on a date. Neither needs a tool.

The last two weeks before someone leaves

Record the walkthroughs now, while they are still doing the work. A person mid-notice is often more willing to explain things than they have been all year.
Read the runbooks for their tasks together and correct them line by line.
Transfer credential custody in a working session, not by email. Confirm each account opens for somebody else while the departing person is still in the room.
Change registration on any account in their personal name or email, and confirm two-factor is no longer routed to a device that is leaving.
Introduce the successor or the interim holder to every vendor contact by name, in writing.
Capture the open questions: what they were in the middle of, what they were worried about, what they would fix if they had another quarter. This is the paragraph that gets lost.
Name who holds each responsibility from their last day, including the ones nobody wants. Unassigned tasks do not wait patiently. They stop.

The first two weeks for the next person

Day one is access, not orientation. Every account they need, in their own name, working before they need it.
Hand them the role page from the plan. It tells them what they own, what they run, and when things are due, which is the question every new hire is too polite to ask three times.
Walk one recurring routine together from the runbook, with the interim holder watching. Fix the runbook where it turns out to be wrong. That correction is their first contribution.
Show them where to ask how we do things, and show them the citation, so they learn to read the source rather than trust the summary.
Give them the decision log for their systems and permission to ask why about any entry. A newcomer's week-two questions are the best audit the documentation will get.
Book their first monthly refresh before the end of week two, so the habit starts with them.

07What to keep out of it

Four things will undo this, and three of them are easy to do without noticing.

01
Credentials pasted into a chat tool
Never, in any tool, however convenient the moment. A password in a conversation history is a password in a place you do not control and cannot reliably clear. The documentation says which vault holds them and who has access, and nothing more.
02
Supporter or client personal data in prompts
The documentation describes how the work is done. It does not need a real donor record, a real case file, or an export of the mailing list. Write procedures against example records. If a runbook cannot be written without real personal data, it is describing the data instead of the process.
03
Anything you do not own or cannot export
If the knowledge ends up somewhere the organization cannot get it out of, such as an account in one person's name or a platform with no export, you have moved the dependency rather than removed it. Ownership and export are the two questions to ask before anything goes in.
04
A tool only one person knows how to run
The sharpest version of the failure, because it looks like success. If the continuity system itself has a single administrator, you have built a new single point of failure and put all the institutional knowledge inside it. At least two people configure it, and its own documentation lives with everything else.

08What it looks like when it holds

The abstract version does not land until you have lived both. Three scenes.

01
The departure
Someone resigns. The work needs covering and a search needs running, and that is all. Nobody spends the following fortnight guessing which of four spreadsheets is the live one, emailing a former colleague for a password, or discovering in week three that a funder report was due and only one person knew.
02
The first week
The new hire has their own accounts on day one, a page that says what they own, and a runbook for the first routine they will run. By Friday they have run it once with someone watching and corrected two steps that were out of date.
03
The board question
A board member asks which systems hold supporter data, who has access, and what happens if the database administrator leaves. The answer goes back the same day with the systems map attached.

Keeping it true is the part organizations find hardest, because the month of building is a project and the upkeep is a habit. That is the job the Mission Technology Partner retainer does. The systems map is maintained as a living document, credentials and vendor relationships stay in the organization's custody, the monthly refresh sits on the calendar of somebody who is not already at capacity, and the exit package is named in the contract, so our own departure is covered by the same discipline as anyone else's.

Two related decisions have their own guides: whether a standing technology seat is the right purchase at all, in the guide to fractional CTOs for nonprofits, and the platform question in the guide to choosing a nonprofit CRM. If a website redesign is in front of you, do the inventory in this guide first. The systems map and the form-by-form record are the same evidence that project needs, and you only want to gather it once.

09Questions we get asked

Do we need a fractional CTO to do this?: No. An operations lead or a capable program manager can build the first version with a named owner and about a month of part-time effort. The inventory, the interviews, the drafts, and the review pass are all work your own staff can do. What retained technology leadership adds is upkeep and custody: keeping the systems map current, holding credentials in the organization's name, and making sure the monthly refresh is not the first thing dropped in a busy quarter. Build it yourself first.
Which AI tool should we use?: We are not naming one, because the choice matters less than two properties any candidate needs. Ownership: the documents, recordings, and transcripts are yours, stored under an account in the organization's name. Export: you can get everything out in a standard format, without assistance, at any time. Also insist that answers cite the source document. Beyond that, the discipline of capture, review, and monthly refresh determines the outcome more than the product.
Is this safe for supporter data?: Yes, if you keep supporter data out of it, which is straightforward because the system does not need any. You are documenting how the work is done: the steps in the reconciliation, what the CRM fields mean, who administers which platform, when the contract renews. Write procedures against example records and describe fields rather than pasting their contents. The same rule covers credentials: the documentation names the vault and who has access, never the credentials themselves.
Can we do this without recording people?: Yes, though it costs more time. A twenty-minute narrated walkthrough produces a better first draft than an hour of someone writing their own process from memory, but a colleague taking notes during a live walkthrough works, and so does a rough bullet-point pass turned into a structured runbook. Framing matters more than method. People cooperate when this is clearly about relieving them of being a single point of failure, and resist when it reads as building their replacement.
How long until it pays off?: At the next departure, which in this sector is usually within the year. Smaller payoffs arrive sooner. The first-week inventory routinely surfaces subscriptions nobody uses, accounts registered to people who left, and a contract about to auto-renew that nobody had diaried. Credential custody ends the situation where one person's absence blocks a task. And the first time a staff member covers for a colleague on leave using a runbook rather than a phone call, the value is obvious to everyone who watched.
What is the difference between this and a shared drive?: A shared drive is storage. This is structured, so every recurring task has a runbook, every system a page, and every role a plan, and you can tell what is missing. It is answerable, so a new hire asks how do we do this in their own words and gets your organization's answer with the source shown. And it is maintained, so the monthly refresh flags what has gone stale. Most organizations already have the shared drive. It is where documentation goes to be written once and never read.

Find out what would leave with the next person

A scoped conversation covers what you run now, who administers each piece, which roles hold knowledge nobody else has, and how much of the month above your team could do themselves. If the answer is that you should build it yourselves from this guide, we will say so, and you will leave with a clearer picture of your exposure either way.

Ask for a scoped conversation Fractional CTO for nonprofits

The First AI Project a Nonprofit Should Build: Continuity When Staff Leave

01Why turnover is the technology problem

What actually leaves with a person

02Why the plans you already have do not cover it

The succession plan

The disaster recovery plan

03What a continuity system actually does

Half one: capture the work

Runbooks for the recurring work

A systems and vendor map

Credential custody the organization holds

A decision log

Half two: train the next person

An onboarding path built from what you captured

A place to ask how we do things

04Why this is the right first AI project

The scope has edges

It runs on your own material

The payoff is scheduled

The audience is internal

It makes the later projects possible

What the AI is actually doing here

05How to set it up in about a month

Inventory

Capture

Drafting

Review and correction

Custody and access

The refresh habit

06The nonprofit knowledge transfer plan

The last two weeks before someone leaves

The first two weeks for the next person

07What to keep out of it

Credentials pasted into a chat tool

Supporter or client personal data in prompts

Anything you do not own or cannot export

A tool only one person knows how to run

08What it looks like when it holds

The departure

The first week

The board question

09Questions we get asked

Find out what would leave with the next person