Nursery: Monthly Fees, Attendance, and Parent Communication Without Exposing Excess Information

In a nursery almost every field concerns a child, so the practical question is not what may be stored but which fields each screen and each message actually need in order to work. Minimisation is a design principle: start from the action, and add a field only when the action fails without it. What follows is a technical description, not legal, medical or financial advice.

Which fields does a message to a parent actually need?

Three, occasionally four. The rest are fields that entered the message because they were available in the query, not because anyone decided on them.

The notes row demands the most explicit decision. A free-text notes field pulled automatically into a message is the fastest route from an internal record to an outbound one. If the field exists, it should not be wired to any template that leaves the building.

Four stores, not one wide sheet

A single sheet where every row is a child and every column is something somebody added once fails not because of size but because of access: whoever needs to tick attendance also sees outstanding balances.

• Attendance - arrival and departure events. Group staff read and write.
• Authorised contacts - who may collect the child, with a validity range. Staff read, management writes.
• Billing - charges, payments, balances. Bookkeeping only.
• Documents - forms, certificates, consents. Management only, with view logging.

That separation costs no more to maintain, and it is what makes a simple question answerable: who looked at this document and when. A shared sheet cannot answer it at all.

The monthly billing cycle as a dated pipeline

Billing in a nursery is a recurring event with the same stages every month. When the stages are not dated, each month is improvised. A workable configuration, in which the day numbers are an example rather than a rule:

1. Day 24 of the prior month - generate a draft charge per child from their own arrangement: attendance days, extended hours, meals.
2. Day 26 - management reviews exceptions only: any amount that moved more than a set threshold against last month.
3. Day 28 - lock the draft and issue the charges. From here a change is a credit, not an edit.
4. Day 1 - send an individual message to each parent with the month and the amount.
5. Day 3 - present the charges for collection on the chosen route, whether a direct-debit batch or a card.
6. Day 6 - handle failures only. A failed charge is a row with a reason and an owner, not a general list.

The stage that gets skipped is the second, and it is the only one that catches an error before it becomes a message. Reviewing amounts that jumped takes five minutes; a wrong charge that reached parents is an hour of phone calls. The collection routes themselves are compared in Masav direct debits vs card payments.

What has to come out of a group message?

Everything that is not common to everyone. A message to a group must be true for every recipient in it, so any field that varies from child to child simply cannot appear.

• Group messages suit times, events and general changes at the nursery.
• Anything concerning one specific child is sent individually, even when the content is nearly identical.
• A WhatsApp group exposes every participant's number to every other participant. Individual sends do not.
• Initiating outside the 24-hour window requires an approved template, so a billing template is best built with name, month and amount as three separate variables.

The third line is the one that gets forgotten. Another parent's phone number is data the nursery held, and a visible distribution list republishes it to the whole group without anybody deciding to. A comparison of channels by message type sits in SMS vs WhatsApp vs email for reminders.

Attendance as events, not a monthly total

Attendance stored as the number "22 days" cannot be checked. Attendance stored as events can:

• child_id, an event_type of arrival or departure, and a timestamp.
• recorded_by - who marked it. A parent at a kiosk, a staff member, or a system.
• source - app, entrance terminal, or a manual entry made after the fact.
• corrected_from - on a correction, a pointer to the event being corrected.

The timestamp is stored with an explicit offset. A nursery operates in morning hours that cross a daylight-saving change twice a year, and the IANA Time Zone Database is what stops the same day being a different length in two calculations. The monthly total is computed from the events whenever it is asked for, so two calculations in the same month return the same number.

What actually breaks

• A group message carrying an amount. A figure correct for one child goes out to fifty parents.
• A spreadsheet emailed to a staff member. A file that has left the system is no longer subject to any permission.
• A notes field wired to a template. Internal text becomes the body of an outbound message.
• A hand-edited attendance total. Once edited, there is no way to show which events it came from.
• A duplicate charge for the same month. With no uniqueness constraint on child plus month, a second run creates a second charge. That kind of constraint is documented in PostgreSQL Constraints.
• An authorised contact with no validity range. Somebody removed stays on the list because no field says until when.

What to have ready before you start

• A defined payment arrangement per child, rather than an amount retyped every month.
• A list of authorised contacts with start and end dates.
• A decision on who approves an exception during the day 26 review.
• One designated channel per purpose, so an invoice does not go out three different ways.

Sources

• Masav - the Israeli banking clearing centre
• IANA Time Zone Database
• PostgreSQL - Constraints