Codes 'n' Coffee Tech
My Pain Clinic Global · Pain management and wellness

Valid appointment options across doctors, rooms, and treatment machines.

A configurable scheduling platform that replaces spreadsheet-led coordination with constraint-first slots, optional smart recommendations, CRM, and a connected patient and doctor workflow.

Updated 24 July 2026

Scheduling engine used: Zlot Manager

Illustrative workflow
A valid slot aligns the doctor, room, machine, and service
Clinic resource planning
Resource
09:00
10:00
11:00
Doctor
Room
Machine
Service
All required constraints agree Ranked slot
Illustrative workflow based on the described operating scope. No live client data is shown.
My Pain Clinic Global logo
At a glance

From operating constraint to working system.

Problem statement

My Pain Clinic Global was coordinating multiple doctors, treatment rooms, machines, leads, appointments, and treatment stages through Google Sheets. That approach could not scale safely because an appointment is only valid when the service, doctor, room, required machine, and duration align, while the patient's journey continues well beyond the first booking.

Delivered system

Codes 'n' Coffee Tech configured Zlot Manager as the booking infrastructure behind each service and treatment context. Slot types identify the required duration and resource model; master data supplies doctors, rooms, machines, services, and lifecycle context; conditional layers reject combinations that cannot be delivered. Optional recommendation logic ranks only the valid set. Around that engine, CRM and doctor-facing workflows connect the complete patient lifecycle: Lead, Consultation, Single Session, Package, Treatment Delivery, Completion, and outcome follow-up focused on the patient's pain-management goal.

How the system connects

Constraint-first scheduling inside the complete patient lifecycle

The booking engine is not an isolated calendar. The service selects a configured slot type, master data and statuses supply the current clinical-resource context, and conditional layers validate the complete combination before options return to booking and doctor workflows.

SystemProcessDecisionExceptionOutcome

The booking engine is not an isolated calendar. The service selects a configured slot type, master data and statuses supply the current clinical-resource context, and conditional layers validate the complete combination before options return to booking and doctor workflows.

  1. System: CRM and patient lifecycle. Lead, consultation, session, package, completion, and follow-up states stay connected.
  2. Process: Service definition. Each service supplies duration and required resource context.
  3. Process: Doctor, room, and machine availability. Every required resource contributes to appointment validity.
  4. Decision: Complete combination valid?.
  5. Exception: Invalid candidates excluded. Incomplete resource combinations stop before recommendation.
  6. Outcome: Constraint-valid slot set. Only operationally deliverable options continue.
  7. Process: Smart slot ranking. Recommendation logic orders the valid choices.
  8. Process: Booking and doctor applications. Teams act from shared appointment, lifecycle, and resource context.
  9. Outcome: Treatment and follow-up journey. The confirmed appointment continues through delivery, completion, and follow-up.
  • CRM and patient lifecycle to Service definition: Service context.
  • Service definition to Complete combination valid?: Duration + resources.
  • Doctor, room, and machine availability to Complete combination valid?: Availability.
  • Complete combination valid? to Invalid candidates excluded: Invalid.
  • Complete combination valid? to Constraint-valid slot set: Valid.
  • Constraint-valid slot set to Smart slot ranking: Rank.
  • Smart slot ranking to Booking and doctor applications: Recommended options.
  • Booking and doctor applications to Treatment and follow-up journey: Continue journey.
Zlot Manager owns slot configuration and booking eligibility. CRM and the doctor application retain lifecycle actions, while optional recommendation logic remains downstream of deterministic resource checks.
Operating modules

Designed around the work people need to complete.

Each module has a clear responsibility and passes the right context into the next owned action instead of becoming another isolated tool.

01Lead and consultation

CRM follow-up carries an enquiry into consultation with the service and patient context needed for the next decision.

02Zlot Manager booking layer

The service selects its slot type, duration, doctor, room, machine, lifecycle, and status conditions before the engine returns a valid appointment option.

03Session and package delivery

Single-session and package-based treatment workflows carry appointment, resource, and progress context across the planned course of care.

04Doctor workflow and completion

The doctor-facing application connects treatment activity, completion, and outcome follow-up to the patient's operational journey.

How the operation runs

Constraint-first scheduling inside the complete patient lifecycle

The lifecycle begins in CRM, separates single-session and package slot contexts, loads the required master data and statuses, validates every conditional layer, optionally ranks the valid set, and carries the confirmed appointment into the doctor workflow and completion follow-up.

EntryProcessDecisionExceptionOutcome

The lifecycle begins in CRM, separates single-session and package slot contexts, loads the required master data and statuses, validates every conditional layer, optionally ranks the valid set, and carries the confirmed appointment into the doctor workflow and completion follow-up.

  1. Entry: Lead. Capture the enquiry, need, source, and follow-up context.
  2. Process: Consultation. Establish the service and scheduling context for the next step.
  3. Decision: Single session or package?.
  4. Process: Single Session. Prepare the selected service for one appointment journey.
  5. Process: Package. Carry the plan into a sequence of appointment requirements.
  6. Process: Resolve service requirements. Load duration and the required doctor, room, and treatment machine.
  7. Decision: All resources valid?.
  8. Exception: Reject invalid combination. An option missing any required resource cannot enter ranking.
  9. Process: Rank valid options. Recommendation logic orders only the constraint-valid set.
  10. Process: Booking and Treatment Delivery. The appointment and resource context continues into the doctor application.
  11. Outcome: Completion and outcome follow-up. Close the planned journey and retain follow-up context without promising an outcome.
  • Lead to Consultation: Qualify.
  • Consultation to Single session or package?: Decide journey.
  • Single session or package? to Single Session: Single session.
  • Single session or package? to Package: Package.
  • Single Session to Resolve service requirements: Requirements.
  • Package to Resolve service requirements: Requirements.
  • Resolve service requirements to All resources valid?: Generate + validate.
  • All resources valid? to Reject invalid combination: Invalid.
  • All resources valid? to Rank valid options: Valid.
  • Rank valid options to Booking and Treatment Delivery: Select + book.
  • Booking and Treatment Delivery to Completion and outcome follow-up: Complete.
Deterministic resource rules run before recommendation logic. Smart ranking receives only appointment options that already satisfy doctor, room, machine, duration, and service requirements.
Implementation process

From operating reality to a system teams can run.

The implementation separates discovery, domain rules, architecture, module delivery, validation, and live operational improvement.

  1. Phase 01

    Spreadsheet and lifecycle discovery

  2. Phase 02

    Clinical-resource modelling

  3. Phase 03

    Zlot Manager configuration model

  4. Phase 04

    Patient and doctor workflows

  5. Phase 05

    Scenario and recommendation validation

  6. Phase 06

    Operational rollout and refinement

Implementation phase detailRead how discovery, modelling, architecture, delivery, validation, and continuous improvement were handled.
  1. Phase 01

    Spreadsheet and lifecycle discovery

    Map the Google Sheets process, lead hand-offs, consultation decisions, service durations, treatment stages, and the resources checked for every appointment.

  2. Phase 02

    Clinical-resource modelling

    Represent services, doctors, rooms, machines, durations, availability, and lifecycle states as explicit rules and relationships.

  3. Phase 03

    Zlot Manager configuration model

    Configure service and treatment slot types, doctor-room-machine master data, statuses, and conditional layers so only valid appointments can enter the optional recommendation set.

  4. Phase 04

    Patient and doctor workflows

    Build CRM, consultation, booking, session, package, treatment, and doctor-facing journeys around the shared patient lifecycle.

  5. Phase 05

    Scenario and recommendation validation

    Exercise resource conflicts, duration changes, rescheduling, lifecycle transitions, and the rule-before-ranking behaviour of smart slot recommendations.

  6. Phase 06

    Operational rollout and refinement

    Move teams away from spreadsheet coordination, support live scheduling, and refine services and treatment workflows as operating needs change.

Implementation detail

Decisions, validation, and clear system boundaries.

The complete technical explanation remains available here without interrupting the primary operating story.

Technical decisionsHow each operating constraint shaped an implementation choice and ownership boundary.
Constraint

Google Sheets could display schedules but could not govern a multi-resource booking decision.

Implementation

Model service and treatment slot types, master data, statuses, availability, and lifecycle context in a dedicated booking domain.

Why it matters

The system can explain why a slot is valid or unavailable instead of relying on manual cross-checking.

Constraint

Doctor availability alone does not make an appointment deliverable.

Implementation

Attach doctor, room, machine, duration, service, lifecycle, and status conditions to the relevant Zlot Manager slot type.

Why it matters

Every recommended option begins as an operationally valid resource combination.

Constraint

Recommendation logic must not override clinical-resource constraints.

Implementation

Apply deterministic booking-eligibility rules before optionally ranking the remaining slot options.

Why it matters

Smart recommendations improve choice ordering without manufacturing an invalid appointment.

Constraint

The patient's operational journey continues across multiple appointment types and treatment stages.

Implementation

Use a connected lifecycle from lead through consultation, sessions, package delivery, completion, and follow-up.

Why it matters

CRM, booking, and doctor workflows retain the context required for the next owned action.

Validation and rolloutScenarios used to test the combinations most likely to disrupt live operations.

Simultaneous resource demand

Test overlapping requests for the same doctor, room, or machine and confirm that only one valid allocation is returned.

Service-rule changes

Re-evaluate availability when a service duration or required resource combination changes.

Rescheduling and lifecycle state

Ensure cancellations and reschedules preserve the correct consultation, session, package, and treatment context.

Constraint-before-ranking

Assert that recommendation logic receives only slots that already satisfy every required resource rule.

Technical boundariesWhat the architecture owns, and where adjacent systems or human decisions remain responsible.
  • Zlot Manager owns slot configuration and booking eligibility while CRM and the doctor application own lifecycle actions.
  • Smart recommendations are optional, rank valid options only, and are not described as making clinical decisions.
  • Scheduling coordinates resources and workflow state; it does not make clinical decisions or promise medical outcomes.
Ongoing engineering partnership

Technology that keeps moving with operations.

The live system is supported through ongoing product engineering, application releases, workflow refinement, maintenance, and day-to-day operational support.

Related capabilities and industries
Intelligent Resource Scheduling Healthcare operations
Scheduling engine used
Zlot ManagerConfigurable booking infrastructure for slot types, rules, and workflows
Let's talk

Recommend appointments that satisfy every required resource.

We can model your services, availability rules, resources, and booking journey before designing the scheduling system.

Book a discovery call
Codes 'n' Coffee Tech
Share the constraint
Map the operating flow
Choose a practical next step