One page was serving two different jobs

Appointment configuration combines ordinary business decisions with implementation details. Callback hours, duration, and customer-facing messages belong in a conversation about service. Parser settings, internal mappings, proposal expiry, and data-source fields belong in a conversation about operating the system.

Putting everything on one page makes both conversations worse. A customer sees fields they should never need to interpret, while an administrator has no clear boundary around settings that carry operational risk.

Customer view

The customer-facing view centres on safe choices: when callbacks are available, how long they take, how many alternatives are proposed, how far ahead the assistant can search, and what it says in common situations.

The labels describe behaviour rather than storage. That sounds small, but it changes whether somebody can review a setting with confidence.

Admin view

The administrative view exposes the controls needed to maintain the integration: fallback behaviour, confidence thresholds, status mappings, proposal validity, data mapping, and technical notes.

The important part is not merely hiding those fields. A customer save must preserve technical values it cannot see. Otherwise a limited form can accidentally submit empty defaults and destroy a working integration.

customer save → update allowed business fields
               → preserve protected technical fields

What I learned

This is more than visual simplification. Separate views communicate responsibility. Customer View means communication and safe campaign behaviour. Admin View means the technical contract that makes those choices work.

The save path must enforce that distinction, not just the screen.

What should happen next

The natural next step is role-based authentication and server-side field allowlists. A mode switch is a useful design tool, but it should eventually be backed by an access model that cannot be bypassed by a crafted request.