Customer Operations
Customer operations covers the work created after people interact with the public site: submissions, orders, bookings, tickets, replies, consent, payments, and follow-up.
Outcome
At the end:
Customer records are linked
Orders, bookings, tickets, forms, consent, payments, and communications attach to the right customer in the right workspace.
Inbox events route to owners
Form submissions, replies, tickets, booking events, and customer questions land where the responsible team actually works.
Forms and tickets are actionable
Operators can see context, assign ownership, reply, escalate, and close the loop without leaving the source record unclear.
Notifications are configured
Customer and operator messages use the intended sender, template, reply path, and notification preferences.
Customers can use the portal
The portal exposes the correct profile, orders, bookings, billing, tickets, saved items, and notification preferences.
Operators know the context path
Before replying, the team knows whether to start from Inbox, Customers, Scheduling, Sales, Forms, or Tickets.
Step 1: Configure Customer Records
Console surface: Customers.
Customer records should unify:
- Profile details.
- Bookings.
- Orders.
- Payments.
- Forms.
- Consent documents.
- Communications.
- Support tickets.
- Activity history.
- Internal notes.
Verify:
- Guest actions can become customer records.
- Returning customers link to existing records when possible.
- Customer detail is scoped to the active workspace.
Failure checks:
- Duplicate customers usually indicate mismatched email, guest flow, or incomplete claim logic.
- Missing history usually means the action was not linked to the customer record.
Step 2: Configure Forms
Console surfaces: Forms, form editor.
For each launch-critical form, configure:
- Name.
- Slug.
- Fields.
- Required fields.
- Validation.
- Success state.
- Notification behavior.
- Destination or routing expectation.
Verify on sites:
/forms/{formSlug}renders.- Submission succeeds.
- Required fields block incomplete submissions.
- File uploads work if enabled.
- Success state is clear.
Verify in console:
- Submission appears in Forms, Inbox, Responses, or the intended triage surface.
- Customer record is linked when possible.
- Notification is sent when configured.
Step 3: Configure Inbox Triage
Console surface: Inbox.
Inbox should help operators answer:
- What happened?
- Who is the customer?
- What record is involved?
- What should the team do next?
- Has this already been handled?
Verify:
- New items show the source record and customer context.
- Operators can assign, snooze, close, or escalate the item.
- Replies use the correct workspace identity.
- High-risk items have a clear owner and next step.
Inbox should reduce handoff ambiguity. If operators still need to search across bookings, orders, forms, and tickets before understanding an item, add routing rules, labels, or playbook context before launch.
- New form submission appears.
- Booking event appears.
- Notification event appears.
- Ticket or support event appears.
- Links open the right customer or record detail.
Step 4: Configure Email Notifications
Console surface: Email Notifications.
Configure messages for:
- Booking confirmation.
- Booking reschedule.
- Booking cancellation.
- Booking payment.
- Order confirmation.
- Shipping or fulfillment updates.
- Form submission acknowledgement.
- Ticket updates.
- Account or portal events.
Verify:
- Sender identity is correct.
- Variables render correctly.
- Links use the final domain.
- Reply-to goes somewhere monitored.
- Unsubscribe or email preference paths are honored where required.
Step 5: Configure Consent Documents
Console surfaces: Customers, Consent Documents, Settings > Privacy and Legal.
Use consent documents for:
- Service waivers.
- Treatment or appointment consent.
- Marketing opt-in.
- Policy acknowledgement.
- Custom intake agreement.
Verify:
- Required documents appear before the customer action completes.
- Completed consent is visible from the customer, booking, form, or order context.
- Operators know which services or workflows require each document.
Consent documents should be specific to the action that needs them. Avoid attaching broad waivers to every customer path unless the business has confirmed that the extra friction is intentional.
- Consent appears in customer detail.
- Waiver appears in booking flow when attached.
- Operators can tell whether consent is missing, pending, or complete.
Step 6: Configure Tickets And Help
Console surfaces: Inbox, Customers, Help content.
Sites surfaces:
/help./help/{treeSlug}./tickets./tickets/new./tickets/{id}.
Verify:
- Public help answers the most common questions.
- Ticket creation reaches a monitored console surface.
- Customer replies are linked to the right workspace and customer record.
- Operators can close or escalate tickets without losing history.
Help content and tickets should share ownership. If a repeated ticket topic appears during launch, update public help or form copy so the next customer can self-serve.
- Customer can create a ticket.
- Ticket appears in console or customer context.
- Customer can see replies in portal.
- Operators have enough context to respond.
Step 7: Verify Customer Portal
Sites surfaces:
/account./profile./profile/notifications./orders./billing./tickets./account/my-bookings./account/saved.
Test:
- Customer signs in.
- Profile displays correct identity.
- Notifications can be adjusted.
- Orders show only that customer’s orders.
- Bookings show only that customer’s bookings.
- Tickets show only that customer’s tickets.
- Billing and subscriptions are scoped.
Step 8: Run Operator Reply Flow
Test one full support cycle:
- Customer submits a form or opens a ticket.
- Inbox receives it.
- Operator opens customer context.
- Operator reviews bookings, orders, payments, forms, and prior communications.
- Operator replies or takes action.
- Customer receives notification.
- Customer sees the update in portal if applicable.
Customer Operations Done Criteria
Use these criteria when handing a workspace from setup to the team that will answer customers. The workflow is ready when every customer action has a visible console destination, a responsible operator, and a customer-facing response path.
- Customer actions appear in the right console surfaces.
- Operators have enough context to act.
- Notifications are correct.
- Portal is scoped and useful.
- Consent and communication preferences are respected.
- Support loops close cleanly.