# Designing donor reporting for a nonprofit CRM, from zero to a weekly habit
By Vandan Gohil · Role: Founding Design Engineer, 2026 · Scope: Product Design, Design Systems · Industry: Nonprofit, AI-native CRM
October 3, 2026 · Leading Ambiguity
Shipped nine role-based reports and a custom builder in two weeks, now opened weekly by 60% of clients.
[Case study](https://vandangohil.com/reports)## At a glance
- Product: Reports, the donor reporting in Sapling CRM, an AI-native CRM for nonprofit fundraising teams.
- Role: Founding Design Engineer. Owned research, product design, the design system and the front end.
- Shipped in two weeks: six reports in the first two weeks, the last three soon after, plus a custom report builder.
- Built for three readers: leadership (KPIs), team managers (growth), gift officers (depth).
- Adoption: rolled out to all 10 paying clients; 60% of clients open their reports every week.
- Investors and early customers called it one of the strongest features in the product.
## Context
Every donor CRM has reports. Raiser's Edge, Bloomerang, DonorPerfect. They're table stakes: nobody picks you for them, and everyone walks without them.
But fundraisers export them to a spreadsheet and go contact by contact to find who is slipping. The report answers what happened.
So the bar was the reports every CRM has, deep enough for every corner of a nonprofit, and built so the next step is obvious from the page.
The test I ran every screen against: A gift officer shouldn't have to open forty donor records to find the three about to lapse. The report should hand them the three.
It became one of Sapling's largest features. Six nonprofits run it every week. This is how it got there.
## What the category already ships
I started by finding the standard. What does a reports feature look like across every serious competitor, and what do their users complain about.
Where AI was used:
I recorded the call with the founder in Granola and mined the transcript for intent: what was asked, and what was meant underneath it. Then I added my own read on which of those mattered.
With that framing set, I ran three Claude agents in parallel, one per research question. They mapped the landscape; I judged it. The complaints were what counted. A feature list shows what a competitor built. A complaint shows where it breaks.
The pattern was consistent. The same handful of report categories everywhere. Tables of counts. Sector acronyms like LYBUNT and SYBUNT. Most of it built for the person who exports to Excel and does the real work somewhere else.
Research told me what exists. It couldn't tell me who opens it, or why. For that I had to talk to people.
## Three types of users open the same report
I asked users how they get reports today and which ones they actually look at. The answers split cleanly into three types, by role.
[Reader cards, one per user type]
- Leadership. Cares about KPIs: They want the number, and then they want to leave.
- Team Managers. Cares about growth: Is everyone performing, and is giving growing week over week.
- Gift Officers. Cares about depth: They raise the money. Every gift, every lapse, every move.
Three types of users, three depths, often the same page. So the page had to be built in the order they read it.
[Video: Report page anatomy — 3 layers, 3 readers] A Recent Giving & Trend Analysis report, highlighted one layer at a time: KPIs for leadership, charts and Orchid's insights for team managers, the gift table for gift officers, then the page fanned out into its stacked layers.
[Video](https://vandangohil.com/studies/reports/three-depths.mp4)Managers judge gift officers on the same trends officers work from, so they got their own report: Portfolio Performance and Activities, covering caseload coverage, officer activity and team balance.
[Interactive figure] Three reports, one per user type, taking turns to open: Monthly Revenue for leadership, Team Performance for managers, Portfolio Coverage for gift officers.
- Monthly Revenue (Leadership view): Six months of revenue as bars; hovering a month reads off its total and the change on the month before.
- Team Performance (Manager view): Weekly line chart of officer activity and top officers by revenue; hovering a week reads off both values.
- Portfolio Coverage (Gift Officer view): Donut of the portfolio by last contact: under 30 days, 30 to 90 days, over 90 days, and never contacted; hovering a segment shows its count and share.
## Design decisions
Where AI was used:
Claude built the front end from Figma and design.md, our design system written for agents. I spent my time on hierarchy, drill-downs and what to cut.
That's how the founder reviewed working reports on real data in week one, instead of a deck.
## Plain words over acronyms
By the end of week one, three reports were running on real data. The founder's main note: drop LYBUNT and SYBUNT.
They're standard in the sector, but a new CRM shouldn't sound like an old one. If a label needs a glossary, it's the wrong label.
## Movement over counts
Where AI was used: none here. This change came from talking to gift officers. No agent would have found it.
The first versions counted donors per status. Gift officers asked who moved, and where. So the lifecycle report became a Sankey of donor movement, clickable down to the donors.
[Video: Donor lifecycle — the interactive Sankey of movement] Lifecycle count cards give way to the question gift officers kept asking, "Who moved?", then to the interactive Sankey of donor movement, with the flow from Active to Pre-lapsed highlighted at 70 donors.
[Video](https://vandangohil.com/studies/reports/the-split.mp4)## Granularity of reports
Research and brainstorming came down to nine report types. Together they cover 90% of what people open reports for, and each answers the question its readers came with.
Report | Built for | The question it answers
Orchid Insights and Next Calls to Make | Gift officers | Who should I call today, and why?
Recent Giving and Trend Analysis | Managers, gift officers | Is giving speeding up or slowing down?
Retention, Reactivation, and Donor Lifecycle | Gift officers, managers | Who moved, and in which direction?
Geographic Analysis | Leadership, gift officers | Where does our support come from?
Campaign, Fund, and Segment Analysis | Leadership, managers | Which appeals, funds and channels are working?
Pledges and Asks Reporting | Gift officers, managers | What's promised, what's overdue, what can we expect?
Portfolio Performance and Activities | Managers | Is every caseload covered and moving?
Engagement Tracking and Conversion | Managers, gift officers | Is interest turning into gifts?
Revenue Forecasting and Monthly Giving | Leadership | What will we raise, and how healthy is recurring giving?
[Image] Recent Giving & Trend Analysis: total raised, gift count, unique donors and average gift up top, giving by band beside the giving trend, and Orchid AI insights below.
[Image](https://vandangohil.com/studies/reports/suite-giving-trends.webp)[Image] Retention, Reactivation & Donor Lifecycle: retention trend against the sector average, and retention by frequency, tier and channel.
[Image](https://vandangohil.com/studies/reports/suite-retention.webp)[Image] Pledges & Asks Forecast: outstanding and overdue pledges, expected income over the next 90 days, the pledge book, and a cash-flow runway.
[Image](https://vandangohil.com/studies/reports/suite-pledges.webp)## Where it started: a custom report builder
Reports started as a blank builder. Leadership used it well; gift officers and managers stalled at the blank page. So the builder's filters became the engine, and the nine templates became the front door, each with its question already asked.
Leadership still builds every month: reports around the KPIs they care about, exported or scheduled for the team.
## How it got built
Two weeks to ship. Working reports reached the founder in week one and five nonprofits soon after, so feedback arrived while changes were still cheap.
Where AI was used:
This is the part worth stealing. Build is usually the long pole, so real-user testing lands at the end, when change is expensive.
So I built a custom design.md, our design system written for agents to execute. With agents building against it, build stopped being the bottleneck, and the time it freed moved testing up to week one.
[Video: Reports build, before and after agents] How we shipped Reports, stage by stage: brief, research with three agents running in parallel, design, build against the design system, test, a Slack auto-brief at handoff, and ship. The whole pipeline took two weeks.
[Video](https://vandangohil.com/studies/reports/pipeline.mp4)Stage | What I did | What AI did
Brief | Found the intent behind the founder's ask | Broke down the Granola transcript of the call
Research | Competitor and complaint research, then the user conversations that found the three readers | Parallel agents on competitor reporting, G2 and Reddit complaints, benchmark gaps
Design | Page anatomy, hierarchy, what to cut | First drafts against design.md
Build | Reviewed, refined, made the interactions feel right | Front end generated against the system, on seeded data
Backend handoff | Defined what each report needed from the API | Slack automation briefs backend engineers on blockers the moment a front end is done
Validate | Week one with the founder on real data, then five nonprofits on their own data | None. This part was people
Release | Feature newsletter, then rollout to all 10 paying clients | None
## Outcome
The product is new and so is the feature, so today's picture is strong qualitative signal and thin quantitative data.
- Shipped: 9 reports covering every role's core question, plus a builder for the rest.
- Habit: 60% of clients open their reports every week to track their progress.
- Signal: "One of the strongest features in the product." What investors and early customers said about Reports.
## What I'd take into the next one
## Flexibility only helps people who already know what they want
A blank builder hands the hardest part of reporting, knowing which question to ask, to the person least equipped to answer it. Templates that ask the question for you serve far more people than a builder that can answer anything.
## Shipping fast makes scope grow
Nine reports shipped quickly and covered 90% of what users needed. That's when the asks started: three to five more features on top, each one making the product more complex.
## Set the scope before the build starts
Now I agree on what the feature includes before anyone builds it. New asks go to the next release, never into a sprint that's already running.
## How this page is designed
- Layout: a 628px reading column with figures bleeding to 788px, a sticky scroll-spy table of contents, and a section rhythm taken from a Figma spec (40px above each heading, 12px to its first paragraph, 16/24 body text).
- Type and colour: Inter throughout, with an optional Charter serif theme; light and dark themes from shared CSS variables; one accent blue sampled from the illustrations.
- AI layer: a 'See what AI influenced' switch reveals the passages about where AI was used in the process. They write themselves in word by word in an iridescent pink-violet-cyan gradient, marked by a gradient diamond in the margin. The story reads complete without them.
- Reader cards: each reader has a custom isometric line figure, drawn with the Hairline engine (lucasmarkes/hairline) and its figure skill, that plays through its items on its own and answers the pointer. On hover the card tilts in 3D toward the cursor, floods blue and swaps the figure for that reader's need.
- Report pills: three report previews open in turn as an accordion, each with a live chart (bars, lines, donut) that a ghost cursor demonstrates and that responds to real hover.
- Outcome: a bento of three cards with Hairline figures (a conveyor for what shipped, report stacks for the weekly habit, a dish for the signal) over quiet animated backdrops.
- Media: walkthrough videos are lazy-loaded, muted and looped, with a smaller encode on phones, play/pause and an expanded view; screenshots open in a lightbox; downloads are disabled.
- Accessibility and performance: reduced motion is respected throughout; decorative figures are hidden from assistive tech while their meaning is in text; media is cached and re-encoded with no visible loss; figure frames reserve their size so nothing shifts on load.
## Pages
## Contact
## Archive
