Picklist data fields use a single string for both what the guest sees and what gets written to the CRM. When the destination property's underlying value differs from the wording that belongs on the form, the write fails, and the only workaround is to reword the guest-facing form to match the CRM's internal value.
The clearest case is HubSpot booleans. A booking form asks a yes/no question and should display "Yes" and "No," but the HubSpot property expects true and false. Today the admin has to put "true" and "false" on the form in front of the guest, or lose the field.
Requested behavior, in two parts:
  • Label and value separation: in the Data Field editor, let each picklist option carry a display label and an independent outbound value. The form shows the label, the integration sends the value.
  • Automatic label matching: where a Chili Piper option label matches the destination property's visible option label, resolve to that property's underlying value automatically, so the common cases need no per-option configuration at all.
Why it matters: the guest-facing wording and the CRM's internal representation are answering to different audiences and shouldn't be forced into one string. Today the CRM wins, and buyers see developer values on a booking form.