A donor migrated into Sapling from a spreadsheet can arrive with hundreds of updates attached. Gifts across a decade, notes from three different officers, a pledge someone forgot to close. Before a meeting, a gift officer needs four things from that pile: what this person has given, when, what was discussed last, and what to ask for next.
Doing that by hand, before every meeting, across a portfolio of a few hundred people, doesn't happen. So the meetings run on memory.
Orchid started as a chatbot in the corner of the app that could tell you where to click. Useful, and nowhere near the job.
This is how it became an assistant that digs into a nonprofit's own data, answers in the language of fundraising, and does it without handing donor identities to a third-party model.
What I owned
I owned Orchid's product strategy, the design of every surface and every response, and the front end. I partnered with our backend engineer, who built the backend layer it runs on. Where a decision was shared, I say so.
The name comes from the brand. Sapling is about nonprofits growing from a sapling into a forest, and Orchid is the flower in that ecosystem.
The boundary came first
The feature everyone wanted was the obvious one: tag a donor and ask about them. How much has @donor given over three years, and when did they last respond to an appeal?
It's also why this category moves carefully. Donor records are the most sensitive data a nonprofit holds, and sending names to a third-party model was off the table.
So before I drew anything, I took one question to our backend engineer: how does someone ask about a specific person without that person's identity leaving our system?
The rule we landed on is drawn by field. Names, addresses, phone numbers and emails never reach the model. Gift amounts and zip codes can, because the model needs them to reason. A donor's identity is swapped for an internal reference on our side before a request goes out, and restored on our side when the answer comes back. Co-decided The boundary and the experience are mine. The mechanism is the backend's.
Debating a feature stalls a room. Debating a field gives an engineer a rule they can build that afternoon.
The model can still find patterns in a giving history. What it can't do is attach them to a person. Sapling holds the name, the model holds an anonymous pattern, and neither side holds both.
My design job was making that boundary invisible. A fundraiser types a name and sees a name in the answer. The swap happens in between, and nobody has to think about it.
Grounded in someone who has done the job
Our founder spent his career as a fundraiser and has raised more than $70 million. He knows what a good next step looks like, how a portfolio should be worked, when to ask and when to wait. A general-purpose model doesn't.
So Orchid doesn't answer from whatever a model happens to know about nonprofits. We wrote his playbook into the context it works from: how fundraisers prioritize, what a next step should be, how to read a giving pattern. My part was turning that knowledge into answers people could act on, and designing responses that show their reasoning along with their conclusion. Co-decided
One of Orchid's insights on the Recent Giving report reads Thank the newest donors first, because gifts from the last two weeks are the warmest calls a team can make. That's a fundraiser's instinct, delivered as a card at the moment the data supports it.
A recommendation people can't question is one they won't act on. So every insight carries its why.
Where Orchid lives
Orchid sits in the top bar on every page, and it knows which page you're on. Ask who should I call? from a donor's profile and from the dashboard, and you get two different answers, both correct for where you are.
- The conversation follows you. Start on the dashboard, open a contact, keep talking.
- A central chat page holds full history for longer work.
- @ tagging works anywhere a conversation can start.
- Inline insights sit on the dashboard and the Trend Analysis report.
Those insights generate when someone asks, never on page load. Generating on load would burn a model call every time a tab opens, mostly for people who came for something else. And a number shouldn't change while someone is reading it aloud on a call. Drove
Answers are interfaces
A wall of text asks a fundraiser to do the last step of the analysis themselves. So Orchid answers in components: donor cards, charts, lists with an action on every row, and navigation buttons that take you straight to the page you asked about. I designed every one of them. Drove
That moved the design job. I design the small set of shapes an answer can take, and the model chooses among them. Sometimes it chooses wrong, and the shape still has to hold up.
Ask for donors in one city who gave above a threshold last year and haven't heard from you since spring, and you get the list, ready to work, without touching a filter.
I shortlisted four jobs and designed Orchid around them:
- One donor, before a meeting. Giving history, last contact, what to ask.
- A period, read back to you. What happened this month or this year.
- Critical insights with a plan. What the trend means and what to do about it.
- Where do I do this? Answered with the page itself, one click away.
Calibrating the guardrails
Orchid has been wrong in two opposite directions, and both mattered.
Too loose. Early Orchid invented features. Asked about payments, or a report Sapling didn't have, it described them confidently. A fundraiser who believes that goes looking for something that doesn't exist, and stops trusting the assistant when they can't find it. The fix was documentation, a lot of it: a written map of what exists in the product and what doesn't, plus standards and constraints for what Orchid may claim and what it must refuse.
Too strict. Then it started going quiet. With clients and investors, Orchid sometimes refused questions it should have answered. When we went through the transcripts, it was doing exactly what we'd told it to. The rules that stopped people from probing the platform or pulling out what they shouldn't were also catching fair questions. We'd added a rule for every edge case until the safest answer was no answer.
So we loosened it on purpose. The hard boundaries stayed. The rules that blocked ordinary work came out.
A refusal has a cost too. An assistant that says no to a fair question teaches people to stop asking.
What I killed
Orchid was going to build custom reports on request. Ask for a report, get one.
We cut it. Generated interfaces were unreliable. The model would assemble a plausible layout without understanding the interface it was producing, and every report came out slightly different and slightly wrong. A report people rely on every week has to be the same report every week. Those questions went into nine fixed report templates and a builder instead, which is its own case study. Drove
What it does today
Orchid is robust. It isn't fully agentic yet, and I'd rather say that plainly than blur it.
Evidence, and its limits
Users told us Orchid helped them analyze more than 10,000 donors, and that it's now part of how they decide where to spend their fundraising time. Investors responded to it as the clearest proof that Sapling is AI-native, a CRM built around an assistant instead of one with a chatbot added later.
We don't have usage instrumentation on Orchid yet, so I won't dress this up with numbers. What I'd measure first: the share of conversations that end in an action, the refusal rate on fair questions, and how often a question about a tagged donor gets answered without the user leaving the page.
What's still open
It isn't fully agentic. Orchid answers, analyzes and suggests. Acting is next, and it's the hardest part, because analysis fails softly and actions fail loudly.
Every new path has to inherit the boundary. As Orchid gets more capable, each new route to the model is another place the privacy rule has to hold. I'd want that verified path by path, not assumed.
No instrumentation yet. Until there is, every claim about impact is something users told us.
What I'd do differently
Keep privacy and the backend in the same room from day one. We drew the boundary early and it held. Next time I'd make that partnership continuous from the first sketch, so every new capability starts inside the boundary instead of being checked against it later.
Start with five nonprofits and three jobs. Our users skew older, and comfort with AI varies a lot. I'd find the five nonprofits with the strongest use for an assistant, list the five to seven places they'd use it, pick the three most tedious, and make Orchid the best in the world at those before adding anything else. The boring jobs are where an assistant earns trust.
