Case study

Five manual steps became one human decision.

A writers' community runs two virtual rooms that members book around the clock, from quiet co-writing sessions to public meetups. I built the system that takes a booking from "member picks a time" to "published community event" with one decision in the middle and no retyping anywhere.

Role · Design & build Shipped · August 2026 TidyCal → Airtable → Circle

The original system was an inbox.

For every meetup, a member emailed the community manager, and she did the rest by hand. Five steps, every event, and she was the only person who could do any of them.

Check the calendarCross-reference the request against whichever calendar seemed authoritative that week

Hold the roomPut the event on the calendar by hand

Create the Zoom roomMake the meeting, copy the link

Write the postRebuild the member's email into a community post on Circle, recurrence and all

Confirm backOne more email, with the details retyped one more time

Reschedules restarted the chain. Recurring events multiplied the calendar work. None of it was hard; all of it was constant.

Now one link does the machinery.

TidyCal shows members only genuinely free slots, assigns one of the two rooms, creates the Zoom meeting, and holds the room calendar the moment the member confirms. Three of her five steps are gone before she even knows the booking exists, and private sessions never reach her at all.

Booking

One link, two rooms, 24/7. Zoom and the calendar hold happen the instant the member confirms.

Synced · 5 min→

Review queue

The community post arrives pre-drafted from the member's own answers, with clash warnings.

One decision→

Publish

Publish direct, or draft in Circle to preview first. Recurrence confirmed in one panel.

→

Runs itself

Room held for the series, confirmation emailed, every step stamped so nothing fires twice.

Private bookings skip review entirely · Cancellations reverse themselves Branded confirmation → Host

A desk, not a database.

The community manager never sees a spreadsheet. The Library Desk is a review app I built on Airtable's interface extension SDK: a queue of pending bookings, a two-week room calendar, and buttons that map to decisions, not fields. What she sees in the editor is exactly what publishes.

The Library Desk queue: two bookings pending review, each card showing host, time in London, room, and whether it is a public meetup or private booking, with Needs info and Decline actions — The queue
Soonest first, each card carrying the facts and the quick decisions. The full review, with a rich-text editor and the Publish and Draft in Circle actions, lives one click deeper.

The Library Desk calendar tab: bookings listed under each day for the coming two weeks, with room tags and review status — The calendar
The two-week room picture, grouped by day: published, in review, and pending, all in one glance. The Pulse button opens monthly stats.

Under the hood, three workflows.

Each one polls on a schedule, does its one job, and stamps its own completion marker. Recovering from any failure is usually clearing a single field.

n8n sync workflow: fetch TidyCal bookings every five minutes, split live bookings from cancellations, upsert into Airtable, and route cancellations to delete or soft-cancel depending on whether the event was published — Sync · every 5 min
TidyCal to Airtable. Live bookings upsert by booking ID; cancellations fork on "was it published?", deleting quietly or flagging for human cleanup.

n8n publish workflow: find newly published bookings every ten minutes, compose the Circle event payload, create the event or publish an existing draft in place, then create a recurring room hold in Google Calendar — Publish · every 10 min
Approved bookings become Circle events. One branch creates fresh, the other publishes an existing draft in place, edits intact. Recurring events hold the same room calendar the booking started on.

n8n notify workflow: find unconfirmed approved bookings every ten minutes, send a templated confirmation email via Resend, and mark the confirmation sent — Notify
Branded confirmations through Resend. The sent-marker means it can never send twice.

Airtable automations: stamp new bookings pending review, notify on pending booking, and seed the formatted post with a script — In-base
Inside Airtable: new bookings stamped for review, the reviewer notified, the post drafted by script.

Machines own facts. People own judgment.

The design choice I'd defend hardest: every field in the base has exactly one writer. That's why the whole thing re-runs every few minutes without stepping on anyone's work.

The sync owns the factsTimes, rooms, Zoom links, the member's answers. Re-asserted on every run, so a reschedule simply refreshes itself.

The reviewer owns the judgmentThe post, the title, the decision, the real schedule. Never touched by a machine after creation.

Each workflow owns its proofPublished-at, event ID, confirmation-sent. Completion markers, one writer each. Clear a marker and that step safely re-arms.

5 → 1

Steps per event

Rooms, 24/7

Workflows

Copy-paste steps