Context

Paul runs College Money Method, delivering financial aid workshops to high schools across the US.

Each academic cycle includes:

• 100+ schools
• thousands of Zoom registrations
• proposals and contracts for each school
• workshop scheduling
• counselor communication
• resource distribution to families

By early 2024, Paul was coordinating all of it himself.

“I've been doing it all manually… I'll go into Zoom, download the reports, format them, send them out. It takes a lot of time.” — Paul Martin

A Zapier workflow existed, but with 5,000+ registrations expected during peak months, it was becoming expensive and fragile.

Facing renewal, Paul chose to build a system instead of extending patches.

This is a common moment for growing teams — when tools start fighting the way you work instead of supporting it.
(We wrote about this in Build vs Rent: when off-the-shelf software doesn’t fit how you work.)

The challenge

The operational load had grown beyond what manual coordination could handle.

Each workshop created multiple follow-up tasks:

• attendance reports downloaded from Zoom
• recordings shared with schools
• counselor communications sent manually

At the start of every academic cycle:

• 120+ proposals were drafted individually
• each required matching enrolment tier pricing
• workshop dates were manually inserted

Scheduling was equally manual.

Schools would email preferred dates. Paul would check availability, reply with alternatives, then confirm.

There was no self-service portal for counselors.
Every request flowed through Paul.

The system worked — but only because he was holding it together personally.

The Blueprint

Before building anything, we mapped the operational system.

“I didn't want to build something out intuitively and later realise things needed to be disaggregated.” — Paul Martin

This step is similar to user story mapping, where workflows are mapped before tools are chosen.
(See User Story Mapping for No-Coders.)

The Blueprint defined:

• the core data model
• the operational workflows
• where automation should run

Key entities included:

• Schools
• Workshops
• Registrations
• Contracts
• Contacts
• Resources

Once the structure was clear, automation became straightforward.

Build sprints

The system was implemented in weekly build sprints.

Each sprint introduced a specific operational capability.

Registration automation

Zoom registrations and attendance now sync automatically into Airtable.

After each workshop:

• attendance reports compile automatically
• recording links attach to the session
• schools receive follow-up communication automatically

This eliminates the manual CSV downloads that previously happened after every event.

Reliable automation matters here — fragile workflows break under scale.
(We cover this problem in Build automation systems that don't break at 2 AM.)

Proposal generation

At the start of each sales cycle Paul used to create 120+ proposals manually.

Now:

1. Paul selects a school in Airtable
2. the correct pricing tier populates automatically
3. workshop dates pull from the scheduling table
4. a proposal document is generated
5. a PDF saves to Google Drive

Proposal creation now takes seconds instead of hours.

Contract automation

Contracts follow the same pipeline.

School details, pricing tiers, and workshop dates populate automatically from Airtable.

Paul can review, edit if needed, and export.

Self-service scheduling

Instead of coordinating dates by email, schools now use a live booking interface.

The calendar connects to Paul's Google Calendar and automatically excludes:

• weekends
• blocked dates
• public holidays

Schools select available workshop dates directly.

Counselor portal

Each school receives a private portal with:

• their workshop schedule
• recordings
• attendance data
• resources
• communications

No manual distribution required.

Academic cycle rollover

Schools renew each year.

The system duplicates records for the next academic cycle automatically while preserving historical data.

The outcome

The operational load shifted from manual coordination to system automation.

Estimated annual impact:

520 hours recovered

across:

• attendance reporting
• proposal generation
• contract creation
• workshop scheduling

Equivalent labour value:

~$40,000 per year

Peak load example:

September 2024 processed 5,000+ registrations with no manual intervention.

“We went from manually drafting proposals to generating them in seconds.” — Paul Martin

If you're evaluating similar projects, we explain how to measure automation impact in
How to Calculate the Real ROI of No-Code Projects.

Ongoing work

The system continues to evolve.

Current sprint: rebuilding the family resource library using Bubble with:

• full-text search
• structured asset taxonomy
• tiered access permissions

This will consolidate resources previously scattered across WordPress and Softr.

Start with a Blueprint

Most operations problems aren't tool problems.

They're system structure problems.

Or as we wrote elsewhere:

→ You don't need more tools. You need better systems.

The Blueprint maps the system before anything is built.

Blueprint starts at $299.
You keep the architecture even if we never work together again.