Designing a Demo Booking and Attendance System for Scratch's B2B Sales Motion

Executive summary

Scratch had a B2B sales motion where a demo booking was an important conversion point.

But booking a demo is not the end of the lifecycle journey. It is the start of a more fragile handoff: confirmation, preparation, reminders, sales visibility, attendance tracking, follow-up, and rescheduling when someone misses the meeting.

I designed lifecycle automation around the demo-booking and attendance process in HubSpot. The work connected marketing engagement, prospect state, sales ownership, reminders, and follow-up logic.

Some pieces were launched. Some broader components were constrained by stakeholder resistance and organizational limits. This case study separates the architecture from what can be safely claimed as implemented.

Scratch's B2B sales context

Scratch sold into veterinary practices and related business prospects.

The B2B motion needed more than raw lead capture. Prospects needed education, qualification, demo booking, sales follow-up, and continued nurture when they were not ready to move forward.

The broader system had gaps:

• Limited educational content.
• Incomplete nurture infrastructure.
• Weak connections between marketing engagement and sales activity.
• Demo bookings that needed a stronger lifecycle around the appointment.

The demo system was connected to the broader B2B resource-center and nurture vision, but the demo workflow deserved its own architecture.

Why demo bookings were not enough

A booked demo creates a calendar event. It does not guarantee readiness, attendance, or sales follow-up.

The business needed a process that could:

• Confirm the booking.
• Prepare the prospect.
• Remind the prospect before the meeting.
• Reduce preventable no-shows.
• Help sales understand who booked.
• Support timely follow-up.
• Distinguish booked, attended, missed, and completed demo states.

Without a state model, the prospect can receive messages that no longer match reality.

A person who already booked should not keep getting generic demo CTAs. A person who missed the meeting should not be treated the same as someone who attended. A person who completed a demo should move into a sales follow-up path, not back into early nurture.

Designing the demo lifecycle

The lifecycle model treated the demo as a state machine.

Engaged lead
  |
  v
Demo interest
  |
  v
Demo booked
  |
  v
Pre-demo nurture
  |
  +-- attended
  |     |
  |     v
  |   sales follow-up
  |
  +-- did not attend
        |
        v
      rescheduling or continued nurture

The point was to stop treating the booking as a final conversion.

The actual system needed to manage the messy middle between interest and revenue opportunity.

HubSpot automation architecture

HubSpot could coordinate the workflow through contact properties, lifecycle stages, meeting events, workflows, internal notifications, ownership, reminder emails, sales tasks, and suppression.

The conceptual model looked like this:

Demo booking event
  |
  v
Contact property update
  |
  v
Workflow enrollment
  |
  v
Customer-facing confirmation
  |
  v
Internal sales visibility
  |
  v
Reminder sequence
  |
  v
Attendance evaluation
  |
  v
Post-demo branch

The useful contact properties were state-oriented:

demo_status:
  none
  interested
  booked
  attended
  no_show
  completed

sales_owner:
  assigned representative

last_demo_date:
  scheduled or completed meeting date

demo_follow_up_status:
  pending
  active
  completed

The exact property names matter less than the structure. The CRM needed to know where the prospect actually was.

Sales notifications and ownership

Internal visibility was part of the system.

A demo booking should create a sales-facing signal, not only a customer-facing confirmation.

Prospect books demo
  |
  v
Update demo status = booked
  |
  v
Notify assigned sales owner
  |
  v
Create or update follow-up context

The sales rep needed enough context to prepare:

• Who booked.
• What company or practice they represented.
• What lifecycle stage they were in.
• What engagement preceded the booking.
• Whether they needed follow-up before or after the meeting.

The system was about alignment. Marketing automation should support sales, not throw a booking over the wall and hope the handoff works.

Booking-to-attendance workflow

The designed workflow looked like this:

Prospect books demo
  |
  v
Update demo status = booked
  |
  v
Send confirmation
  |
  v
Notify assigned sales owner
  |
  v
Send pre-demo information
  |
  v
Send appointment reminder
  |
  v
Evaluate attendance status
  |
  +-- if attended:
  |     update lifecycle state
  |     initiate sales follow-up
  |     suppress booking reminders
  |
  +-- if did not attend:
        send rescheduling path
        notify sales
        continue appropriate nurture

This diagram represents the intended architecture. The launched components included demo-related nurture and reminder work. The broader attendance and resource-center ecosystem was affected by stakeholder resistance and access constraints.

That distinction matters.

Attendance and no-show logic

Attendance deserves its own lifecycle state.

A no-show is not the same as a cold lead. The person showed enough intent to book, then failed to attend. The follow-up should reflect that.

Scheduled meeting time passes
  |
  v
Attendance known?
  |
  +-- attended:
  |     move to sales follow-up
  |     suppress booking reminders
  |
  +-- no-show:
  |     send reschedule path
  |     notify owner
  |     keep nurture relevant
  |
  +-- unknown:
        flag for manual review

That last state matters because CRM data is not always clean.

When attendance is unknown, the system should avoid pretending it knows. A manual review path is better than sending the wrong message with confidence.

Implementation constraints

The architecture was stronger than the environment around it.

The broader B2B lifecycle plan depended on content, resource-center infrastructure, sales alignment, and CRM usage. Some of that work was launched. Some of it was limited by stakeholder resistance and organizational constraints.

That is normal in real lifecycle work.

The clean diagram is never the full story. Access, ownership, content availability, data quality, and team adoption all decide how far the system can go.

The technical architecture still matters because it gives the team a direction:

• Track demo state.
• Notify sales at the right moment.
• Prepare the prospect before the meeting.
• Branch after attendance.
• Suppress irrelevant nurture.
• Keep non-ready prospects in education.

Business implications

A better demo system improves the sales motion in several ways.

It gives prospects clearer communication. It gives sales better visibility. It reduces the odds that booked prospects drift without preparation. It creates a path for no-shows instead of losing them completely. It also stops marketing from treating demo-booked prospects like early-stage leads.

The deeper point is simple: a demo booking is a lifecycle event.

It changes the customer's state. The automation should change with it.

Lessons for B2B lifecycle teams

A booking is only one step in the conversion system.

Attendance should be tracked as its own state. Sales should get context before and after the meeting. Marketing workflows should stop once the prospect enters a sales-owned path.

Content matters too. Pre-demo nurture is better when the team has useful education to send. Without that content layer, the workflow can still confirm and remind, but it cannot prepare the buyer as well.

Stakeholder resistance can limit implementation even when the architecture is sound. That is not a technical failure. It is a reminder that lifecycle systems live inside organizations, not diagrams.