You're looking to the signed waiver PDF to tell you what a family enrolled in — but that's not the job that PDF does. It only proves they read and signed the agreement and waivers — and gets back to you all that you need to be legally compliant and to CYA (cover your ass).
It was never meant to list their weeks and days. But it COULD do that . . . read on . . .
That information already comes to you — in a different email, about five minutes before you get the forms email. Think of it as an order side and a forms side:
When a family signs up, they pick their actual weeks and days right on the website. Your site then sends you a "you've made a sale" email with their full itemized order. Everything they bought, on every sale/checkout.
Collects the signatures and sends you the signed waiver PDF.
So for any family, you already have both: the "you've made a sale" email tells you what they bought (it usually arrives about five minutes before the waiver PDF), and the waiver PDF proves they signed. The only "extra step" is that it's two emails instead of one.
So if this were broken, I'd just fix it, no money conversation. But it's not broken — it's the same as before, or better:
That works today.
The blank check-boxes on that financial agreement aren't part of what they're agreeing to. The real terms — closures, refunds, tuition rates — are the same for every family, and the signature locks those in. Those blanks are just a leftover from the paper version. The agreement is fully valid and binding without a single one filled in. Having the order details on the same page would be helpful — but its absence isn't "broken," it's just not part of the form process.
We can pull the order details right into the waiver PDF so it's all in one document. But doing that means building the "order side" engine — and then connecting it to the forms side engine. That's the next-phase project we've talked about that would/could add the additional features, such as a roster emailed to you every night for the next day's classes, kids, locations, etc. — and other things, like the form knowing exactly where a parent bailed out, if they bailed out, so they can be nudged to come back and finish. And others we haven't even gotten into.
There are about a half dozen features that would be part of a v1.5 — the diabolical version, if you will — that would move you even closer to full, or almost full, operational automation. That's the end goal here: to take as much of the operational work you do by hand and automate it. It would be the single biggest cost-saving thing you could do for your business — because your TIME is the most valuable asset you have. Automating this is how you give yourself a raise without charging your parents a dollar more. You just spend less time administering the business.
The good news: that same engine is what makes all of that possible. Build the base once, and each feature after it gets cheaper.
So — if I am understanding what you are referring to, and if I am understanding what you are (and are not) seeing and where you are seeing it, then this isn't a fix — it's the first piece of that next phase.
If you want to do this now, because why not? Here's what's involved. Maybe you are not sitting financially in a good place to do this now — this does NOT have to be done now. This could be done anytime.
Here is a breakdown to give you an idea of the steps involved on my end and the time frame each step would take.
The form side and order side currently don't talk. This builds the link that lets the system read exactly what each family bought on any order — across all programs, not just summer. This is the foundation and the bulk of the work.
Once the connection exists, the system attaches a clean summary of the family's actual order — weeks, days, total — onto the waiver document you already receive. Everything you get now, plus the order detail, in one place.
Running real orders through it — full weeks, scattered single days, mixes, $0 promo-code orders, and each program — to confirm it's solid before it's live.
This is web development work, and the job is fairly priced at around $350. I'm offering it to you for the price of a day's pay Uber driving — for two reasons.
First: we already did one of these together, and I genuinely want to keep building out this automation with you, step by step. The idea of being your hero for the rest of your life? I like that.
Second: I'm happy to give you a break, as long as it doesn't get me in trouble for stepping away from guaranteed work. That's my situation right now — today, this week — and there is nothing in this world I want to do less than get up and drive Uber. It's that horrible. I would much rather sit at my desk and work for you at the same rate driving pays — $15 an hour, which isn't even minimum wage in some states — on the days when those are my only two options.
I'll give this one full, long day — 12, maybe 13 hours. I fully expect we finish inside that day. But if something stubborn comes up and we don't wrap, I have to stop — past a certain point I get sloppy and that helps no one.
The price does NOT go up if that happens. What changes instead is the finish date: I'd pick it back up and complete it, but it might not be that next day, because I'll likely be driving. Worst case, the finish gets pushed a few days — to no more than a week — to my next desk day.
So: the cost is locked either way. The only thing at risk if it runs long is the timeline, not your wallet. And honestly, if it does run long, you've just gotten the best deal on development work of all time.