CookSmart operations and CRM

A sales and operations system replacing a cooking-camp company's spreadsheets. I gathered the requirements, designed the data model and delivered in milestones.

The problem

CookSmart runs cooking camps and school programs. The work came in two parts: an operations system to replace the spreadsheets for scheduling, staff hours, payroll and shopping lists, and a CRM for selling programs to schools. The hard requirement running through both was that a booked program exists once. It has the same date, place, students and staff everywhere it appears.

What it does

Operations. One program calendar. Shopping lists built from the scheduled recipes and scaled by headcount, with one-click Instacart links. Staff hours, time off and payroll variance (scheduled against actual hours). Staff assignment rules that the database enforces.
Schools CRM. Accounts for boards and schools, opportunities, versioned proposals, follow-up tasks and outreach. Nothing sends by itself: a person approves each email, and a reply pauses the sequence.
Families. Households, children, bookings and memberships. Squarespace and Acuity orders sync in live. Possible duplicates go to a review queue instead of being merged automatically.
Permissions. Admin, senior staff and staff roles, with separate access flags for the CRM and for children’s data. Routes that change data check permission on the server, not just in the interface.

What I did

I gathered the requirements from the owner and staff, designed the data model and permissions, and delivered in milestones the client signed off one at a time. I tested every release against real data with the owner, then moved the system onto the client’s own hosting accounts and wrote the handoff runbook. I built the software AI-assisted: almost none of the code was typed by hand. What was mine was the requirements, the architecture and the decisions below, the testing, and the acceptance of each milestone.

How a sale becomes a scheduled program

- School lead
- Opportunity
- Proposal
One transaction
- Closed won
- Program calendar
- Staff assignment

QuickBooks. The invoice draft is a separate, repeat-safe call after Closed Won. If QuickBooks is down, the sale still closes and the draft is retried.

Every link in this chain has to hold, so a script runs it end to end against live data and checks each step (12 of 12 checks passed at sign-off).

Key decisions

Derived fields set in application codevsDerived fields computed by the database

Chose Derived fields computed by the database because before this rule moved into the database, an account could show as ready to email with no email address on it, because one code path skipped the helper. A database rule can't be skipped by a code path.

QuickBooks call inside the salevsQuickBooks call after it

Chose QuickBooks call after it because an outside service going down should never stop a sale from closing. The draft is keyed so a retry can't create a duplicate.

A separate workshop calendarvsOne program calendar

Chose One program calendar because two calendars can disagree about who is working on a given day. Sold workshops appear on the same calendar as every other program.

Pipeline stage and proposal status in one fieldvsTwo separate fields

Chose Two separate fields because they answer different questions. A deal can be in negotiation while its proposal is still a draft.

What went wrong

A funnel full of proposals that didn’t exist. Stage and proposal status shared one field, so the funnel counted 51 deals that had never had a proposal. Splitting them fixed it.
A double-taxed invoice. The CRM was calculating tax itself. QuickBooks now owns tax, and the CRM only creates drafts.
Tests writing to live data. Early automated tests left records in the production activity log. Tests now run only against a separate test database, and skip if one isn’t configured.

Result

Milestones: All signed off
Acceptance criteria: All met
End-to-end checks: 12 of 12
Hosting: Client's own accounts

The system is live in production for the client. The handoff runbook I wrote covers the database, hosting, the integrations and the places a future change could go wrong.