Tuition Assistance Automation: How I'd Fix the Mosad's Worst Admin

Every September, the same scene plays out in mosad offices across the country: a stack of manila folders, a spreadsheet no one fully trusts, and a secretary fielding calls from families who submitted their forms three weeks ago and still haven't heard back.

Tuition assistance processing is one of the most mission-critical tasks a Jewish school or mosad runs, and it is almost always handled with the least infrastructure. That gap costs real money and real goodwill. And it quietly corrupts your donor CRM every single cycle, as families get double-entered, giving histories get detached from the right record, and someone's generous multi-year relationship with the school gets lost in a deduplication mess.

Why Tuition Assistance Is a CRM Problem in Disguise

Here's the thing most mosdos don't see until I point it out: the family applying for assistance is often the same record as the donor you're stewarding. Or a close relative of one. When the intake process is a PDF emailed to an admin, that data never makes it back into the CRM cleanly.

You end up with duplicate records, missing contact fields, and a giving history that's been orphaned because someone spelled the family name two different ways across two intake seasons. By the time you run your annual campaign, the list is dirty and your donor CRM cleanup automation has to work twice as hard to untangle what poor intake created.

The fix isn't just a tidier form. It's closing the loop between intake and your CRM so every family record stays clean and connected from the moment an application lands.

The Shabbos Layer Comes First, Not Last

Before I spec a single workflow node, I wire in the Shabbos and Yom Tov calendar check. Every outbound communication in this build, whether it's a confirmation email to a family, an approval notification to the menahel, or a follow-up SMS asking for a missing document, runs that check before it fires.

If the send would land during a blocked window, it holds. It goes out motzei Shabbos or at the next configured send time. This is not an add-on. For a mosad build, it's the first thing I set up, because pinging a family on Shabbos afternoon with a financial question is exactly the kind of thing that damages trust and reflects poorly on the school.

The nonprofit automation work I describe on the industries page goes into more detail on how this sits in the broader stack.

How I'd Actually Build the Intake-to-Decision Pipeline

The intake side is a structured form, not a PDF. Typeform or a custom-built portal, depending on what the mosad already has. Families fill it out once, upload their documents directly, and get an immediate confirmation that the school received everything.

From there, an n8n or Make workflow takes over. It checks the submission for completeness against a defined document checklist. If something's missing, it queues a follow-up message to the family, held for a Shabbos-safe send window. The admin sees a clean queue of complete applications, not a pile of partials mixed in with the finished ones.

• Intake form connected to Google Drive or SharePoint: documents land in a structured folder, named automatically, never in someone's inbox
• Completeness check fires on submission: missing items trigger a held follow-up, not a manual chase
• Approval routing pushes to the right reviewer tier based on aid amount, automatically
• Decision notification to family is queued and Shabbos-checked before it sends
• Approved or denied record writes back into the CRM with the correct family record, merging duplicates if the dedup logic catches a match

That last step is where the donor CRM cleanup automation work actually happens in real time, not as a separate annual project. Every clean intake record is a CRM record that doesn't need fixing later.

The Dedup and CRM Write-Back Are the Unsexy Parts That Matter Most

Most mosdos run their donor relationships in something like Bloomerang, Little Green Light, or a Salesforce Nonprofit instance. A few are still on spreadsheets, which makes this even more important. The intake pipeline I build includes a matching step before any new record is created.

It checks the incoming family name, address, and email against existing CRM records using fuzzy matching. If it finds a probable match above a confidence threshold, it flags it for a human to confirm rather than silently creating a duplicate. Below a threshold, it creates a new record. This is not AI hallucinating a match. It's deterministic logic with a human in the loop for edge cases.

Once a family's assistance decision is recorded, the CRM record gets a tag, a note, and the relevant cycle year. That means next year's campaign segmentation actually reflects who received aid, who didn't apply, and who's a major donor whose kid also happens to be on scholarship. That's the kind of data clarity that changes how a development director runs a year-end appeal.

What the Admin Team Keeps Doing, and What They Stop Doing

The admin still reviews complete applications. The menahel or committee still makes the aid decision. A human still sends the final letter with the school's warmth and signature. None of that moves to a machine.

What stops: chasing families for missing documents by hand, manually filing uploads into folders, re-entering family data into the CRM after a decision, and fielding status calls because no one sent a confirmation. Those tasks were never the job. They were just what happened when there was no system.

The pillar post on AI automation for nonprofits and donor CRM on this blog covers the broader case for why owner-operators of mosdos should think about this the same way a product company thinks about its ops stack.

Fixed Price, You Own It, No Retainer

I build this as a fixed-price engagement. One scope, one price, one handoff with full documentation. The mosad owns the workflows, the credentials, and the docs. The pricing page has the structure, and the automations page has more on what's in a typical build.

I don't run a retainer model where you're paying me every month to keep the system running. If the mosad wants changes as the process evolves, that's a new fixed-price build scoped to the change. Clean, predictable, no surprises.

The audit call on the book page is where I look at what the mosad actually has today, what the intake process looks like, what CRM they're running, and what the realistic scope is. That call is free, and it's the only way I scope work accurately.

Tuition assistance season doesn't have to mean a month of manual chaos and a CRM that comes out the other side dirtier than it went in. The intake-to-decision pipeline is a solvable problem, the Shabbos layer makes it right for the community it serves, and the donor CRM cleanup automation that happens as a byproduct is worth the build on its own.