How We Help You Put AI to Work

Most organizations we talk to are not short on ideas. Somebody has a list of thirty things AI could do, a board member has forwarded three articles, and two staff members are already quietly using it. What is missing is a way to tell which ideas deserve real time and money.

We start with the work itself: recurring tasks, bottlenecks, the report nobody reads, the intake process that takes three people. Then we take each candidate through the same set of questions. What goes in, and how sensitive is it? What comes out, who relies on it, and what happens when it is wrong? What is the risk to clients, staff and reputation? What would it cost to build and keep running? What is the return, on investment and on mission?

The part that usually gets skipped is the alternatives. Sometimes the honest answer is that the process is broken and AI would just automate the waste. Sometimes a redesigned form or a policy change solves the problem for free. We say so, and it tends to be the most useful thing in the report.

A pilot answers a narrow question: does this actually work here, with our people, our data and our constraints? It is not a soft launch, and it is not a demo.

We scope the pilot with you: a specific task, a small group of staff who volunteered rather than were assigned, a clear picture of what good looks like, and a date when we decide. During the pilot we sit with the people doing the work, watch where the tool helps and where it gets in the way, and keep track of time saved, quality, and what people actually think of it.

The decision at the end is a real one. Go, adjust and stop are all acceptable outcomes, and we have recommended all three. A pilot that ends in stop and saves you a year of licensing is a good pilot.

We have seen the version of this that goes wrong. An organization buys licenses for everyone, sends an announcement email, and six months later a handful of people use the tool constantly, most have never logged in, and a few have quietly pasted client information into the wrong place. Two steps forward, one step back.

A rollout that works is phased and paced to the organization. We usually begin with a small group that mixes early adopters and skeptics, get the settings and guardrails right with them, then widen the circle team by team. Each group gets training built around its own work rather than a generic demo, and a clear answer to which accounts to use, what is allowed, and where to take a question.

Along the way we build the things that keep adoption going after the launch energy fades: internal champions, office hours, a shared library of prompts and projects, and a simple way to tell whether the tool is actually being used and actually helping.

A policy on paper and a policy in practice are often two different documents. The policy says no client data in AI tools; the platform's default settings allow it and nobody has turned that off. The policy says a person reviews anything before it goes out; there is no step in the workflow where that happens.

We read your policy, acceptable-use guidelines, data agreements and grant requirements, then walk through your actual tools and workflows looking for the gaps. Where a setting can enforce the policy, we turn it on. Where it can't, we build the check into the process, whether that is a review step, a template, or a green, yellow and red list that staff can actually remember.

We also flag the places where the policy itself needs updating, because tools change faster than governance documents do.

Most organizations are paying for far more than they use. The team plan has projects, shared workspaces, custom assistants, connectors to Drive or SharePoint, browsing, voice, memory, and admin controls that decide who can do what. Almost all of it ships turned off, hidden, or left at defaults that don't fit a nonprofit handling sensitive information.

This is the hands-on configuration work that our Selecting, Setting Up, and Launching AI Tools workshop points toward. We go through the platform with your administrator, decide feature by feature what should be on, off or restricted, and set it up. Then we build the first round of shared assets: an organizational project or workspace, custom GPTs, Gems, Skills or agents for your common tasks, and templates staff can copy.

Which features matter depends on who is using them. A grant writer and a case manager need different things turned on, and some things should stay off for everyone. We'll tell you which.

AI is only as useful as what it can see. A chatbot that can't reach your case notes, your donor records or your program data ends up being a very smart tool for writing emails.

Integration work connects your AI platform to the tools you already use: Google Workspace or Microsoft 365, Salesforce or another CRM, Slack or Teams, Airtable, Asana, Notion, Bloomerang, Apricot, and the rest. Sometimes that is a built-in connector that needs to be configured and permissioned correctly. Sometimes it is a lightweight bridge between two systems. Occasionally it is a small custom build.

The technical part is usually the easy part. The harder questions are about permissions and data. Whose records should the AI be able to see, and on whose behalf? What must never leave the system of record? What happens when a connector breaks? We work through those first, with your data agreements and policy in hand, before anything is connected.

Some work is the same every time: the weekly grant-deadline scan, the intake form that gets copied into three systems, the monthly board packet assembled from a dozen sources, the thank-you letters that go out after every gift. That is where automations and agents earn their keep.

We design and build these with the people who currently do the work, in tools like Zapier, Make, Power Automate or n8n, or with the agent features inside your AI platform. Every build has a trigger, a set of steps, and a place where a person reviews before anything consequential happens. Not every step needs a human, but every process needs one somewhere.

Part of the job is deciding what should not be automated. Anything involving a client in crisis, a judgment about eligibility, or a message that carries your organization's relationship with someone gets a very careful look, and often the answer is that a person should keep doing it.

A sliding-scale fee calculator. A volunteer shift matcher. An eligibility screener that asks four questions and points people to the right program. A dashboard that pulls from the spreadsheet everyone already updates. These have always been possible; they just never made it to the top of anyone's list, because building them meant a developer and a budget line.

With AI-assisted development, sometimes called vibecoding, we can build working tools like these in days or weeks rather than months, working directly from how your staff describe the problem. We build in the open with you, test against real cases, and revise until it does what you need.

We are also honest about the limits. A tool built this way is great for internal use, pilots, and anything low-stakes. Something that handles sensitive client data, takes payments, or that many people will depend on needs a security review and sometimes a professional developer. We'll tell you which side of that line you are on before we start.

The difference between a generic AI answer and a useful one is usually context. An assistant that has read your program manuals, your style guide, your past grant reports and your board minutes gives very different answers from one that has read the internet.

We help you decide what belongs in a knowledge base, gather it and clean it up, and set it up in the platform you use: Projects in Claude or ChatGPT, Gems and NotebookLM in Google, agents and SharePoint in Copilot, or a retrieval setup that reaches across a whole document library. Then we write the instructions, set the permissions, and establish the upkeep routine that keeps it accurate, because a knowledge base that is a year out of date is worse than none.

The hard part is often deciding what to leave out, and who is allowed to see what. Personnel files and client records do not belong in the same place as the style guide, and we set things up so they can't end up there by accident.

Not every project is a build. Sometimes a board wants a two-page briefing on what AI means for the organization before it approves a budget line. A funder wants to know how its grantees are using AI and where support would help most. A leadership team wants an eighteen-month roadmap it can actually follow, or a second opinion on a vendor proposal that sounds too good.

These engagements draw on our background in mission-driven organizations and management consulting, and on the pattern we see across the sector. Aging services, arts organizations, philanthropy and local government are all working through the same questions with different vocabulary. We bring what we have seen elsewhere without pretending your situation is the same.

If you have a question about AI and your organization that you can't quite place, this is where to bring it.