How FRANK works with Checkfront

How FRANK works with Checkfront

The booking lifecycle — a plain-language explainer for the Carlingford team on how FRANK integrates with Checkfront and how information flows from a booking through to the daily schedule and final reports.

The core principle

Checkfront stays the booking system of record. Nothing changes about how bookings are made. FRANK sits alongside it and does the operational work — bed allocation, the activity programme, daily schedules and reporting — all driven from the booking data.

The link between them is one-way and read-only: FRANK reads from Checkfront on a schedule; it can never write to or change anything in Checkfront. This is deliberate — it means FRANK is physically incapable of corrupting the booking system. The data flows Checkfront → FRANK, never back.

The lifecycle, step by step

1. A booking is created in Checkfront.
As it always has been. The booking holds its dates, numbers, status, the activities booked, and any notes or special requests.

2. It appears in FRANK automatically.
FRANK checks Checkfront regularly (about every 15 minutes) and pulls each booking into its own working copy — group name, dates, the gender/age breakdown, status, category, booking notes/special requests, and the booked activities. Nobody re-types anything. (Today, before the live connection is switched on, this step is done by importing a file; once the Checkfront API is connected it happens on its own.)

3. Amendments flow through automatically.
Because FRANK re-checks regularly, any change made in Checkfront — numbers up or down, a cancellation, a status change, activities added or removed — appears in FRANK on the next check. Importantly, FRANK does not silently overwrite the team's work: where a change affects an existing plan, it flags it for review (for example, "this group now has 28 people but 31 are scheduled — please recheck"), so nothing slips through unnoticed.

One clarification on dietary & medical information: per-person dietary and medical/mobility details do not come from Checkfront — they come from the rooming list the group leader fills in (FRANK provides a standard template to send them). That information is per-child and usually isn't held in the booking. Booking-level notes and accessibility requests do come across from Checkfront.

4. Bed allocation.
FRANK's own work, running on the numbers that came from Checkfront. The team places groups into areas, rooms and beds — with the house rules enforced automatically (genders never mixed in a room, leaders in leader rooms, adults apart from children, and so on). Individual names come from the rooming list.

5. Activity programming.
The activities booked in Checkfront become each group's "to schedule" checklist in FRANK. The team schedules them across the week — including splitting a group into bands that rotate through activities — with capacity and clash rules enforced (no two groups on the same activity at once unless allowed, no group repeating an activity, instructor ratios, weather backups).

6. Daily schedules.
Simply the programme viewed by day. It can be printed or exported to a spreadsheet, and a named attendance record is kept for each activity session — who was actually there — for records and incident follow-up.

7. Client-facing bed chart completion.
The rooming-list round trip: FRANK produces the room and bed layout, the group fills in who goes where (on the template), those names come back into FRANK, and from then on who is in which bed — and which activity band — is tracked. A printable rooming list / fire register comes straight out of it, including medical/mobility flags.

8. Final reports and outputs.
Occupancy, revenue (with enquiries, provisional and dead leads excluded, so the figures reconcile — unlike the current Checkfront dashboard), the fire register, attendance records, and spreadsheet exports. The financial figures come from Checkfront's own invoice amounts once connected.

What's automatic vs what the team does

  • Automatic (from Checkfront): booking numbers, dates, status, category, booked activities, booking notes, invoice/financial figures.
  • From the group (rooming-list template): individual names, and per-person swim ability, dietary/allergies and medical/mobility.
  • The team's judgement (with FRANK assisting and enforcing rules): where each group sleeps, and how the activity programme is arranged across the week.

FRANK's job is to remove the re-typing and the cross-checking, enforce the rules so mistakes are caught as they happen, and keep one reliable picture — not to make the human decisions for the team.

What's live today vs what connects with the API

Everything except the live Checkfront link is built and working now on demonstration data — bed allocation, the activity programme, bands and attendance, the rooming-list template, printing and reports. The live Checkfront sync is the one piece waiting on read-only API credentials, which a Carlingford Checkfront administrator generates from the Checkfront account. Once those are in place, the "import/re-type from Checkfront" steps disappear and the booking data simply flows in on its own.

First, honestly: the Checkfront link must be tested before we can be sure

The connection to Checkfront cannot be confirmed until we plug into Carlingford's real account and test it. Everything else in FRANK — bed allocation, the activity programme, the reports — is already built and working on demonstration data, and does not depend on that connection. The connection itself is built to Checkfront's published API specification, but until we connect to the actual account and pull real bookings, we are working on a well-founded expectation that it reads everything correctly — not a guarantee.

If the test shows the data coming back differently than the documentation describes — different field names, or activities recorded in a way we didn't anticipate — we adjust the connection to match. Usually that is a contained change; in an unusual setup it could mean more substantial reprogramming of that one part. That is normal for any system integration, and it is exactly why connecting and testing is the first step, not the last. The test is a short exercise, and everything downstream of it is already proven.

How FRANK is built to read and sort the information

When FRANK checks Checkfront, it asks through the API for every booking in a given date range. Checkfront replies not with a web page, but with the data in a structured, labelled format — the standard way software systems exchange information — where every detail sits in its own named field: the arrival date in a "start date" field, the customer in a "customer" field, the things booked in an "items" list, the status in a "status" field, and so on.

FRANK reads those named fields directly — it does not read free text and try to interpret it — guided by a map that says which Checkfront field belongs in which FRANK field (start date → arrival date; customer name → group name; booked items → the activity list; status → confirmed/provisional/cancelled). Each booking's unique ID lets FRANK tell a brand-new booking from an update to one it already holds, so re-checking updates the record rather than duplicating it (and Checkfront counting an AM and a PM as "two" doesn't fool it — one ID is one booking).

Crucially, all the Checkfront-specific detail lives in one small mapping layer — which is exactly what keeps any adjustment after the test contained to a single, well-understood part, rather than a rebuild. Nothing writes back to Checkfront at any point; credentials are stored encrypted, and access within FRANK is controlled by staff role.