Senior Product Designer at Podium

Extending the CRM into a more useful booking journey

Recurring feedback from med spa clients, shared through Customer Success Managers, showed that the existing online booking experience warranted further investigation. I then spoke directly with a small group of beta customers to understand their workflows.

How the approved experience should be evaluated

I do not have verified post-launch analytics. The most relevant proposed measures were:

• End-to-end booking completion and abandonment by step
• Progression from appointment type to provider and time
• Follow-up appointments booked with a preferred provider
• Adoption among eligible med spa businesses
• Guardrail: invalid provider matches or scheduling conflicts

Evidence standard: These are proposed success measures, not claimed results.

One customer journey connected to services, schedules, and the CRM

Provider availability depended on the appointment type. When a customer selected Botox, for example, the system needed to show only providers configured to perform that service, then account for their schedules and locations.

After confirmation, the appointment needed to be saved into the business's Podium CRM. The customer experienced a guided booking flow while service eligibility, provider availability, scheduling, location, and CRM records remained connected behind the scenes.

Helping returning customers find the right provider

Problem. The existing flow supported appointment type, date, and time, but did not clearly help customers book with a provider they already knew.

Evidence. Beta customers explained that provider continuity mattered for check-ins and follow-up appointments, where an established relationship and treatment context were important.

Decision. I made provider selection part of the booking journey. The chosen appointment type filtered the provider options so customers saw only people configured to perform that service.

Why. This gave customers a useful choice while preventing unavailable or ineligible combinations from appearing.

Expected behavior. Returning customers should be able to book online with an appropriate provider while preserving continuity across visits.

Preserving context throughout a multi-step booking

Problem. In the initial experience, customers selected an appointment type and moved forward, but the information they had already chosen was no longer visible.

Evidence. Beta customers reported losing context about the appointment they were trying to book.

Decision. I revised the design to keep an appointment summary visible as customers selected a service, provider, date, and time.

Why. Customers no longer had to remember earlier selections or navigate backward to confirm what they had chosen.

Expected behavior. Customers should be able to move through the flow with greater confidence, catch mistakes, and complete a booking without unnecessary backtracking.

Learning. A multi-step flow can appear simple while still creating cognitive load. Preserving context mattered more than minimizing the amount of information visible on each screen.

Making booking part of the CRM rather than a disconnected tool

Constraint. Med spa businesses already managed clients, appointments, and communication in Podium. A separate booking record would leave the customer-facing and business-facing experiences disconnected.

Decision. The confirmed appointment was designed to save back into the business's Podium CRM while service, provider, schedule, and location rules remained behind the scenes.

Why. Businesses could manage the appointment alongside existing customer information and continue communicating through the system they already used.

Expected effect. Customers received a focused booking journey while businesses gained a connected appointment record without duplicating their workflow.

Service selection and booking confirmation

Turning customer feedback into an approved direction

Evidence. CSM feedback established the initial signal. Conversations with a small group of beta customers then confirmed the importance of provider continuity and revealed that customers lost context between booking steps.

Iteration and status. I built a working prototype with Figma and Claude Code, used it to gather feedback, and added the persistent appointment summary in response. The product direction and final designs were approved and handed to the development team.

Evidence limit: My involvement ended during implementation. I did not have access to the completed release, post-launch analytics, or subsequent customer feedback, so this case study does not claim measured outcomes.

Fast prototyping made customer feedback more actionable

Simplifying the flow required resolving service eligibility, provider schedules, locations, and CRM records behind the scenes. Building the working prototype myself shortened the distance between an idea, a customer conversation, and the next iteration.

In future work, I would define the measurement plan alongside the requirements so customer feedback and post-launch behavior can be evaluated as one continuous product process.