Airtable prototype · Synthetic data
StayOps Group CRM
A production-oriented Airtable operations hub for two fictional UK accommodation businesses: 23 linked tables, five role interfaces and finance controls that block the wrong invoice instead of hiding it.

One reliable place to see who is staying where
The operator needs one place to see who is staying where, which legal company owns each transaction, whether providers and documents are ready, what money is expected or missing, and which exceptions need a person. I built the base so those relationships are explicit while accounting and channel systems stay authoritative.
Everything is synthetic: people, companies, properties and money. Uplisting, Xero, Stripe, email and AI are represented by controlled queues and sample events, so no live credentials, payments or messages are used.
Bookings are the spine
- Master data (legal entities, organisations, contacts and guests, properties) feeds each booking without being copied into it.
- Finance, operations and integration history hang off the booking as linked child records.
- Stable IDs such as BKG-0001 and INV-0001, plus immutable fields for Uplisting, Xero and Stripe references, keep the base API-ready.
Controls instead of hidden automation
Operational users request a legal entity and Finance approves it. Invoice formulas then show readiness rather than moving money.
- INV-0001: approved entity matches, so it queues a Xero draft.
- INV-0002: approved entity missing, so it is blocked until approval.
- INV-0003: approved entity conflicts with the booking, so it is blocked as a mismatch.
- Original booking dates never change; an approved extension updates only the current checkout.
- A replayed Uplisting event with the same idempotency key is logged as a duplicate and ignored.
Five focused workspaces
Executive Overview, Company A Operations, Company B Operations, Finance & Documents and an Admin Control Centre each show one role what it needs. The executive cards read six bookings, £8,790 booked value and £4,570 expected margin straight from source records.
Tested, with honest limits
Twelve acceptance tests pass, from enquiry-to-booking traceability to marketing suppression for opted-out guests. The one native automation stays disabled until sandbox credentials, reconciliation testing and user acceptance testing are done, and role isolation needs named-user testing before production.