Airtable was useful, but it was not the product

I like Airtable as a configuration backend. It is structured, flexible, and practical to integrate with automation. But raw records are not automatically a good interface for somebody deciding how a customer conversation should feel.

Fields such as parser confidence, slot step, proposal expiry, or runtime status describe implementation. They do not describe the decision a campaign owner is trying to make.

The translation layer

I designed a focused configuration studio around the tasks people actually recognise: campaign overview, questions, reminders, appointments, tone, FAQ, messaging, templates, and runtime status.

The studio can load a campaign, validate safe edits, save them to the configuration store, and publish a runtime version. Its job is not to hide complexity by pretending it does not exist. Its job is to translate storage structure into understandable choices.

For example, a nested fallback key is a technical storage detail. A useful interface says: β€œThe requested time is outside our callback hours.” The person editing the text should not need to know where that sentence lives internally.

Scenario-based message editing

This matters most for appointment messages. Rather than presenting a JSON-shaped collection of fields, I group text around situations: an unclear request, an unavailable time, a request outside callback hours, a recently taken slot, a cancellation, or a request for more options.

That is closer to how people think about customer communication. It also makes review easier because the interface describes the moment in the conversation rather than an implementation key.

Save and publish remain separate

Saving changes a draft. Publishing validates and activates it. Keeping those actions separate lets someone prepare a campaign without silently changing the next live conversation.

What I learned

A configuration UI is more than a prettier database form. It is a product boundary between the system's internal model and a person's business decisions.

For the related permission boundary, see why the studio has customer and admin views.

What should happen next

I want message previews that show realistic placeholders and example slots. A preview will not replace validation, but it will make a configuration review much more concrete.