How Salesforce automation replaced a manual, spreadsheet-driven process and gave a growing nonprofit the infrastructure to scale.
The nonprofit runs a growing scholarship program, but its disbursement process looked like that of many small organizations: manual. Students sent receipts directly to staff, and all the information lived in Google Sheets. If a program director needed an update on a student's contract, someone had to track it down.
Receipts were slipping through the cracks, and staff were spending valuable time chasing down paperwork and reconciling spreadsheets instead of focusing on students and donor engagement. The Foundation also recognized that as the program scaled, these inefficiencies would only grow.
I was brought in specifically to rebuild the disbursement process from the ground up inside Salesforce. That meant I owned the full technical build: system design, automation logic, data architecture, and testing. I also worked directly with program staff to understand exactly where the breakdowns were happening, so what I built actually solved the right problems instead of just the ones that were easy to see.
The Foundation wasn't looking for someone to hand them a requirements document and walk away. They needed someone who could figure out what they needed, build it, and make sure the people using it could actually use it.
The first thing I did was sit with the team and map the existing process end to end. Not the way they thought it worked, but the way it actually worked, which is always different. That meant tracing a disbursement from the moment a scholarship was approved all the way through final payment, and identifying every manual handoff along the way.
What I found was predictable but fixable. The biggest problems weren't complexity, they were gaps. There was no structured intake, so submissions came in whatever format the student used. There was no routing logic, so the right person finding out about a pending approval depended on someone remembering to tell them. And there was no feedback loop for students, so they had no idea where their submission stood unless they emailed to ask.
I designed the automation to close all three of those gaps. I mapped out the logic before touching Salesforce, specifically to pressure-test edge cases with the team: what happens if a student submits the wrong document, what happens if an approver is out, where does something go if it doesn't match what we expect. That kind of upfront work tends to save a lot of rework later. The automation flow looked like this:
The following components were configured, tested, and deployed as part of this engagement:
End-to-end disbursement workflow triggered at scholarship approval, replacing the manual, email-based process with a structured automated sequence.
Automatic generation of a unique scholarship number at approval, paired with a personalized outbound email to the student containing their contract form, with no staff action required.
Backend logic to match each incoming student submission to the correct record and contract in Salesforce, replacing unstructured email intake with reliable, consistent routing.
Automated routing of matched submissions to the appropriate reviewer, with a structured approval workflow replacing the previous dependency on manual handoffs and personal memory.
Triggered email notifications to students at each status change (Pending Approval, Approved, Rejected), closing the feedback loop that previously required students to follow up manually.
Record-level visibility in Salesforce showing what was approved, what was pending, and where anything was sitting, replacing the Google Sheets tracker with current, accurate data that required no manual updates.
Administrative time on disbursement processing dropped by roughly 90%. The Google Sheets tracker was retired. The team wasn't chasing down emails or manually updating spreadsheets anymore.
The result that matters most isn't the time savings, it's the infrastructure. The Foundation is growing. When they add more students, expand the program, or bring on additional staff, the process scales with them. Nothing about what was built requires manual intervention to grow.
Most process problems in nonprofits aren't caused by bad people or bad intentions. They're caused by systems that were built for a smaller version of the organization and never updated. The fix is usually less complicated than it looks, but you have to understand the actual process before you can design around it.
Whether you're scaling a CRM, rescuing a troubled implementation, or looking for a Salesforce consultant to join your team, I'd love to connect.