Operations

The Operations section covers daily operational tasks for managing bookings, handling cancellations, processing refunds, managing no-shows, and scheduling resource maintenance. This guide provides comprehensive procedures for day-to-day operations.

Overview

Operations management includes:

• Daily booking oversight
• Cancellation processing
• Refund management
• No-show handling
• Waitlist management
• Resource maintenance scheduling
• Dead letter queue management

Daily Operations Overview

Daily Overview Page

The Daily Overview provides a snapshot of today's operations.

What You See:

• All bookings for selected date
• Booking status breakdown
• Capacity utilization
• Pending actions (holds, cancellations)
• Quick statistics

View Modes:

• Daily View: Single day focus
• Weekly View: Week-at-a-glance

Key Metrics:

• Total bookings
• Confirmed bookings
• Pending holds
• Cancellations
• No-shows
• Revenue

Daily Workflow

Morning Routine:

1. Review Daily Overview
2. Check pending holds (expiring soon)
3. Review capacity for today
4. Check for alerts or issues
5. Plan resource allocation

During Day:

1. Monitor new bookings
2. Process walk-ins
3. Handle cancellations
4. Mark arrivals
5. Process payments (for PoA)
6. Address issues as they arise

End of Day:

1. Mark completed bookings
2. Process pending refunds
3. Review tomorrow's schedule
4. Update maintenance if needed

Booking Management

Viewing Bookings

Booking List View:

• All bookings with filters
• Sortable columns
• Quick actions
• Status indicators

Booking Details:

• Full customer information
• Booking time and duration
• Product and variant details
• Payment information
• Status history
• Notes and communications

Booking Actions

Confirm Booking

Convert a hold to a confirmed booking.

When to Confirm:

• Customer has completed payment
• Payment on arrival needs confirmation
• Manual confirmation needed

How to Confirm:

1. Find booking in list or calendar
2. Click "Confirm" or open booking details
3. Verify payment status
4. Review booking details
5. Confirm booking
6. Customer receives confirmation

Cancel Booking

Cancel a booking and process refunds.

Cancellation Process:

1. Open booking details
2. Click "Cancel Booking"
3. Review cancellation policy
4. See refund calculation
5. Enter cancellation reason
6. Confirm cancellation
7. Refund processed automatically
8. Customer notified

Cancellation Policy:

• System calculates refund based on policy
• Fees may apply
• Timing affects refund amount
• Policy shown before cancellation

Cancellation Reasons:

• Customer request
• Weather
• Equipment issue
• Staff unavailable
• Other (specify)

Reschedule Booking

Change booking to different time.

Reschedule Process:

1. Open booking details
2. Click "Reschedule" or drag in calendar
3. Find available alternative slots
4. Select new time
5. Review price adjustments
6. Confirm reschedule
7. Customer notified of change

Reschedule Considerations:

• Must be within policy window
• New slot must be available
• Price may change
• Capacity must support party size

Mark as Arrived

Record customer arrival for their booking.

When to Mark Arrived:

• Customer checks in
• Activity begins
• Customer present

How to Mark:

1. Find booking in calendar or list
2. Click "Mark Arrived" or "Check In"
3. Booking status updates
4. Activity can begin

Arrival Tracking:

• Timestamp recorded
• Used for no-show detection
• Helps with waitlist management

Mark as Completed

Record that activity has finished.

When to Mark Completed:

• Activity has ended
• Services provided
• Customer has left

How to Mark:

1. Find booking
2. Click "Mark Completed"
3. Booking status updates
4. Can generate completion reports

Completion Benefits:

• Accurate booking history
• Better analytics
• Completion rate tracking
• Customer satisfaction data

No-Show Management

Understanding No-Shows

No-shows occur when customers don't arrive for their booking. The system can automatically detect no-shows or you can mark them manually.

Auto-Detection

Automatic Detection:

• System checks bookings after start time
• If no arrival recorded, flagged as no-show
• Configurable detection window
• Automatic fee calculation (if enabled)

Detection Settings:

• Detection window (minutes after start)
• Fee calculation rules
• Notification preferences

Manual No-Show Marking

When to Mark Manually:

• Customer called to cancel
• Obvious no-show (time passed)
• System didn't auto-detect

How to Mark:

1. Find booking in list or calendar
2. Click "Mark No-Show"
3. Enter details (minutes past start, reason)
4. System calculates fee (if applicable)
5. No-show recorded

No-Show Details:

• Minutes past start time
• Reason for no-show
• Marked by (admin user)
• Timestamp

No-Show Fees

Fee Calculation:

• Based on booking amount
• Percentage of booking value
• Fixed fee amount
• Policy-determined

Processing Fees:

1. Fee calculated automatically
2. Option to charge customer
3. Payment processed (if auto-charge enabled)
4. Customer notified

Fee Processing Options:

• Auto-Charge: Automatically charge customer
• Manual Charge: Charge later
• Waive Fee: Don't charge (with reason)

No-Show Management API

Get Pending No-Show Fees:

GET /api/v1/admin/no-show/pending

Lists all bookings with pending no-show fees awaiting processing.

Query Parameters:

Parameter	Type	Description
limit	number	Maximum results to return
offset	number	Number of results to skip (pagination)

Response:

{
  "success": true,
  "data": {
    "items": [
      {
        "bookingId": "booking_abc123",
        "customerId": "cus_xyz789",
        "customerName": "John Doe",
        "noShowTime": "2025-11-17T14:30:00.000Z",
        "bookingTime": "2025-11-17T14:00:00.000Z",
        "minutesPast": 30,
        "calculatedFee": 2500,
        "feeType": "percentage",
        "status": "pending",
        "detectedBy": "auto_detection",
        "detectedAt": "2025-11-17T14:30:00.000Z"
      }
    ],
    "total": 15,
    "pendingFeeAmount": 37500
  },
  "metadata": {
    "total_items": 15,
    "pending_fee_amount": 37500,
    "pending_fee_amount_formatted": "375.00",
    "items_returned": 15
  }
}

Get No-Show Tracking:

GET /api/v1/admin/no-show/booking/{bookingId}

Retrieves no-show tracking details for a specific booking.

Response:

{
  "success": true,
  "data": {
    "id": "nst_abc123",
    "bookingId": "booking_abc123",
    "minutesPastStartTime": 30,
    "detectedAt": "2025-11-17T14:30:00.000Z",
    "detectionMethod": "auto",
    "feeCalculated": 2500,
    "feeCharged": null,
    "feeStatus": "pending",
    "markedBy": "system",
    "reason": "customer_no_show_auto_detected",
    "resolvedAt": null,
    "resolutionNotes": null
  }
}

Process No-Show Fee:

POST /api/v1/admin/no-show/booking/{bookingId}/process-fee

Manually processes no-show fee for a booking.

Request Body:

{
  "override_fee_amount": 2500,
  "charge_immediately": true,
  "reason": "Customer did not arrive for scheduled booking",
  "notes": "Called customer, no response"
}

Response:

{
  "success": true,
  "data": {
    "feeAssessmentId": "fee_abc123",
    "calculatedFee": 2500,
    "chargedFee": 2500,
    "feeType": "percentage",
    "paymentMethodUsed": "stripe",
    "chargeResponse": {
      "chargeId": "ch_xyz789",
      "chargedAmount": 2500,
      "providerFees": 73
    },
    "processedAt": "2025-11-17T15:00:00.000Z",
    "processedBy": "admin_user_123"
  }
}

Viewing No-Shows

Pending No-Show Fees:

• List of bookings with pending fees
• Fee amounts
• Processing status
• Actions available

No-Show Statistics:

• Total no-shows in period
• No-show rate
• Fee amounts
• Trends over time

Resolving No-Shows

Resolution Options:

• Fee Charged: Fee successfully processed
• Fee Waived: Fee not charged (with reason)
• Customer Arrived Late: Corrected to arrived
• Booking Rescheduled: Moved to different time

Resolution Process:

1. View no-show details
2. Process fee or waive
3. Add resolution notes
4. Mark as resolved
5. Update booking status if needed

Booking Move API

The Booking Move API enables admins to safely reschedule bookings with a two-phase commit pattern: validation (precheck) followed by execution (commit). This ensures capacity constraints and operational policies are respected.

Two-Phase Commit Pattern

The booking move process uses a two-phase commit to prevent conflicts:

1. Precheck Phase: Validate the move without making changes
2. Commit Phase: Execute the validated move atomically

Benefits:

• Prevents capacity conflicts
• Validates policies before execution
• Supports multi-slot bookings
• Provides detailed conflict information
• Allows admin override for soft conflicts

Precheck Booking Move

Endpoint: POST /api/v1/admin/calendar/precheck-move

Validates whether a booking can be moved to a new time slot without executing the move.

Purpose:

• Check capacity availability in target slot
• Validate against operational policies
• Identify hard conflicts (blocking) vs soft conflicts (warnings)
• Provide detailed validation feedback

Request:

{
  "booking_id": "booking_abc123",
  "new_slot_id": "slot_xyz789",
  "actor_id": "admin_user_123",
  "reason": "Customer requested time change"
}

Response (Success - No Conflicts):

{
  "is_valid": true,
  "can_proceed": true,
  "hard_conflicts": [],
  "soft_conflicts": [],
  "warnings": [],
  "metadata": {
    "validated_at": "2025-11-17T14:30:00.000Z",
    "original_slot_id": "slot_abc123",
    "new_slot_id": "slot_xyz789",
    "booking_id": "booking_abc123",
    "validation_duration_ms": 45
  }
}

Response (Hard Conflict - Capacity Exceeded):

{
  "is_valid": false,
  "can_proceed": false,
  "hard_conflicts": [
    {
      "type": "capacity_exceeded",
      "severity": "blocking",
      "message": "Target slot has insufficient capacity. Required: 4, Available: 2",
      "details": {
        "requiredCapacity": 4,
        "availableCapacity": 2,
        "slotCapacity": 10,
        "currentBookings": 8
      }
    }
  ],
  "soft_conflicts": [],
  "warnings": [],
  "metadata": {
    "validated_at": "2025-11-17T14:30:00.000Z",
    "original_slot_id": "slot_abc123",
    "new_slot_id": "slot_xyz789",
    "booking_id": "booking_abc123",
    "validation_duration_ms": 52
  }
}

Response (Soft Conflict - Minimum Gap Violation):

{
  "is_valid": true,
  "can_proceed": true,
  "hard_conflicts": [],
  "soft_conflicts": [
    {
      "type": "min_gap_violation",
      "severity": "warning",
      "message": "Move may violate minimum 15-minute gap between bookings",
      "details": {
        "minimumGapMinutes": 15,
        "adjacentBookings": [
          {
            "id": "booking_previous",
            "slot_starts_at": "2025-11-17T13:00:00.000Z",
            "slot_ends_at": "2025-11-17T14:00:00.000Z"
          }
        ]
      }
    }
  ],
  "warnings": [
    {
      "type": "customer_experience",
      "message": "Move is to an off-peak time that may impact customer satisfaction",
      "details": {
        "targetHour": 22,
        "timeCategory": "late_evening"
      }
    }
  ],
  "metadata": {
    "validated_at": "2025-11-17T14:30:00.000Z",
    "original_slot_id": "slot_abc123",
    "new_slot_id": "slot_xyz789",
    "booking_id": "booking_abc123",
    "validation_duration_ms": 48
  }
}

Conflict Types:

Hard Conflicts (Blocking):

• capacity_exceeded - Target slot doesn't have enough capacity
• resource_overlap - Resource already booked at target time
• time_conflict - Booking time conflicts with existing bookings
• blackout_window - Target time is in a blackout period

Soft Conflicts (Warnings):

• min_gap_violation - Violates minimum gap between bookings
• preferred_resource_unavailable - Preferred resource not available
• overbooking_risk - High utilization increases overbooking risk
• policy_deviation - Deviates from operational policies

Commit Booking Move

Endpoint: POST /api/v1/admin/calendar/commit-move

Executes a validated booking move, updating the booking time and managing capacity atomically.

Purpose:

• Execute validated booking move
• Update booking slot assignment
• Manage capacity release and reservation
• Update calendar projections
• Maintain audit trail

Request:

{
  "booking_id": "booking_abc123",
  "new_slot_id": "slot_xyz789",
  "actor_id": "admin_user_123",
  "reason": "Customer requested time change",
  "confirmed_override": false
}

Request Parameters:

Parameter	Type	Required	Description
booking_id	string (UUID)	Yes	ID of booking to move
new_slot_id	string (UUID)	Yes	Target slot ID
actor_id	string	No	Admin user performing move (for audit)
reason	string	No	Reason for move (for audit)
confirmed_override	boolean	No	Override soft conflicts (default: false)

Response (Success):

{
  "success": true,
  "booking_update": {
    "booking_id": "booking_abc123",
    "previous_slot_id": "slot_abc123",
    "new_slot_id": "slot_xyz789",
    "moved_at": "2025-11-17T14:35:00.000Z",
    "moved_by": "admin_user_123",
    "reason": "Customer requested time change"
  },
  "capacity_updates": [
    {
      "slot_id": "slot_abc123",
      "previous_count": 6,
      "new_count": 5,
      "capacity": 10,
      "available_capacity": 5,
      "utilization_percentage": 50.0
    },
    {
      "slot_id": "slot_xyz789",
      "previous_count": 3,
      "new_count": 4,
      "capacity": 10,
      "available_capacity": 6,
      "utilization_percentage": 40.0
    }
  ],
  "projection_update": {
    "projection_version": "v2025-11-17T14:35:00Z",
    "updated_slots_count": 2,
    "updated_at": "2025-11-17T14:35:00.000Z"
  },
  "metadata": {
    "execution_time_ms": 89,
    "transaction_id": "txn_1731853500_abc123",
    "validation_bypassed": false,
    "soft_conflicts_overridden": false
  }
}

Error Response (Move Failed):

{
  "error": {
    "code": "MOVE_EXECUTION_FAILED",
    "message": "Booking move failed: capacity no longer available",
    "details": {
      "reason": "Target slot filled by another booking",
      "suggested_action": "Run precheck again and select different slot"
    }
  }
}

Multi-Slot Booking Support

The booking move API fully supports bookings that span multiple time slots:

How Multi-Slot Moves Work:

1. Validation: System validates capacity in ALL slots affected by the move
2. Capacity Release: Removes booking from all original slots
3. Slot Calculation: Calculates all new slots based on product duration
4. Capacity Reservation: Reserves capacity in all new slots
5. Atomic Transaction: All operations succeed or fail together

Example Multi-Slot Move:

Original Booking:
- Duration: 2 hours
- Slots: slot_14:00, slot_15:00

Move to new time:
- New start: 16:00
- New slots: slot_16:00, slot_17:00

Capacity Updates:
- slot_14:00: count 5 → 4 (released)
- slot_15:00: count 6 → 5 (released)
- slot_16:00: count 3 → 4 (reserved)
- slot_17:00: count 4 → 5 (reserved)

Booking Move Workflow

Recommended Workflow:

1. Admin initiates move via calendar drag-and-drop or manual selection
2. Call precheck endpoint to validate the move
3. Review validation results:
   • Hard conflicts → Select different slot or resolve conflicts
   • Soft conflicts → Decide to proceed or override
   • No conflicts → Proceed to commit
4. Call commit endpoint to execute the move
5. Verify success via response or calendar updates
6. Notify customer of schedule change

Best Practices:

• Always run precheck before commit
• Handle soft conflicts appropriately (don't auto-override)
• Provide clear reason for audit logging
• Monitor execution time for performance
• Verify calendar projections updated
• Send customer notifications after successful move

Atomic Transaction Guarantees

The booking move commit uses database transactions to ensure:

Atomicity:

• All capacity updates succeed or none do
• Booking update and capacity changes are atomic
• Calendar projection updates are transactional

Consistency:

• Capacity counts always accurate
• No phantom bookings or capacity leaks
• Slot utilization percentages remain valid

Isolation:

• Concurrent moves don't interfere
• Row-level locking prevents conflicts
• Transaction timeout: 10 seconds
• Max wait time: 5 seconds

Error Handling:

If the commit fails:

• All changes are rolled back
• Original booking remains unchanged
• Capacity counts remain unchanged
• Clear error message returned
• Suggested recovery action provided

Move Audit Logging

Every booking move is logged for audit purposes:

Logged Information:

• Who performed the move (actor_id)
• When the move occurred (timestamp)
• Original and new slot IDs
• Reason for the move
• Validation results
• Execution outcome
• Transaction ID for tracing

Audit Trail Benefits:

• Track booking history
• Understand customer service actions
• Debug capacity issues
• Compliance and accountability
• Performance monitoring

Resource Maintenance

Resource maintenance allows you to schedule maintenance windows that block availability.

Creating Maintenance Windows

When to Schedule Maintenance:

• Equipment repairs
• Venue maintenance
• Staff training
• Seasonal closures
• Emergency repairs

Maintenance Types:

• SITE: Entire venue unavailable
• RESOURCE: Specific resource unavailable
• PRODUCT: Product unavailable (all resources)

Creating Maintenance

Step 1: Basic Information

• Resource Type: Site, Resource, or Product
• Resource ID: Which resource
• Reason: Maintenance reason
• Date Range: When maintenance occurs
• Time Range: Specific hours (if not all day)

Step 2: Conflict Check

• System checks for existing bookings
• Shows affected bookings
• Warns about conflicts
• Options to handle conflicts

Step 3: Affected Bookings

• List of bookings in maintenance period
• Options for each booking:
  • Cancel and refund
  • Reschedule automatically
  • Contact customer
  • Keep (if maintenance doesn't block)

Step 4: Notification

• Customers notified automatically
• Email and SMS notifications
• Explanation of maintenance
• Alternative options

Maintenance Status

Status Types:

• SCHEDULED: Future maintenance
• ACTIVE: Currently in maintenance
• COMPLETED: Maintenance finished
• CANCELLED: Maintenance cancelled

Managing Maintenance

Viewing Maintenance:

• List all maintenance windows
• Filter by resource, status, date
• See affected bookings
• View maintenance details

Updating Maintenance:

• Modify date/time
• Change reason
• Update affected bookings
• Extend or shorten window

Cancelling Maintenance:

• Cancel future maintenance
• Restore availability
• Notify affected customers
• Release bookings

Conflict Resolution

When Conflicts Occur:

• Maintenance overlaps existing bookings
• Multiple maintenance windows
• Resource dependencies

Resolution Options:

• Cancel Affected Bookings: Cancel and refund
• Auto-Reschedule: System finds alternatives
• Manual Reschedule: Admin reschedules manually
• Keep Bookings: If maintenance doesn't block

Conflict Prevention:

• Check conflicts before creating
• Use conflict check endpoint
• Review affected bookings
• Plan maintenance during low-demand periods

Cancellation Handling

Processing Cancellations

Cancellation Workflow:

1. Customer requests cancellation
2. Review cancellation policy
3. Calculate refund amount
4. Process cancellation
5. Issue refund (if applicable)
6. Notify customer
7. Update capacity

Cancellation Reasons:

• Customer request
• Weather
• Venue issue
• Medical emergency
• Schedule conflict

Refund Processing

Automatic Refunds:

• Calculated based on policy
• Processed automatically
• Customer notified
• Payment provider notified

Manual Refunds:

• Admin-triggered refunds
• Override policy if needed
• Custom refund amounts
• Documentation required

Refund Status:

• Pending: Refund requested
• Processing: Being processed
• Completed: Refunded
• Failed: Processing failed

Cancellation Policies

Policy Enforcement:

• System enforces policies automatically
• Fees calculated based on timing
• Refunds processed according to rules
• Admin can override in special cases

Common Policies:

• Full refund if cancelled 48+ hours before
• 50% refund if cancelled 24-48 hours before
• No refund if cancelled < 24 hours before
• Credit only for late cancellations

Refund Processing

Automatic Refunds

When Automatic:

• Booking cancelled within policy
• Venue cancels booking
• Activity cancelled
• Policy requires refund

Processing:

• Refund calculated automatically
• Original payment method refunded
• Processing takes 3-5 business days
• Customer notified

Manual Refunds

When Manual:

• Policy override needed
• Special circumstances
• Partial refunds
• Custom amounts

Manual Process:

1. Open booking details
2. Click "Process Refund"
3. Enter refund amount
4. Select reason
5. Process refund
6. Customer notified

Refund Documentation:

• Reason required
• Amount documented
• Approval workflow (if configured)
• Audit trail maintained

Refund Tracking

Viewing Refunds:

• List all refunds
• Filter by status, date, amount
• View refund details
• Track processing status

Refund Details:

• Original booking
• Refund amount
• Processing method
• Status
• Timeline
• Transaction ID

Waitlist Management

The Waitlist Management page allows you to monitor and manage customers waiting for availability when slots are fully booked.

Accessing Waitlist Management

Navigate to Operations > Waitlist to access the waitlist management dashboard.

Waitlist Dashboard Overview

Statistics Cards:

The dashboard displays key waitlist metrics:

• Waiting: Customers currently waiting for availability
• Notified: Customers notified of available spots
• Converted: Successfully converted to bookings
• Expired: Offers that expired without response
• Cancelled: Cancelled waitlist entries
• Conversion Rate: Percentage of waitlist entries converted
• Avg Wait: Average wait time in hours

Viewing Waitlist Entries

Entry Information:

Each waitlist entry shows:

• Customer name and email
• Product and slot details
• Party size
• Position in queue
• Status (waiting, notified, converted, expired, cancelled)
• Creation date
• Expiration time (for notified entries)

Filtering Options:

• Filter by status
• Search by customer email
• Pagination for large lists

Waitlist Actions

Notify:

Send notification to a waiting customer that a spot is available.

1. Find the entry in the waitlist
2. Click "Notify"
3. Customer receives email with accept link
4. Entry status changes to "notified"
5. Offer expires after 1 hour (configurable)

Convert to Booking:

Manually convert a waitlist entry to a booking hold.

1. Find the entry (waiting or notified status)
2. Click "Convert"
3. System creates booking hold
4. Customer can complete payment
5. Entry status changes to "converted"

Cancel:

Cancel a waitlist entry (for waiting or notified entries).

1. Find the entry
2. Click "Cancel"
3. Entry status changes to "cancelled"
4. Spot becomes available for others

Delete:

Permanently remove expired or cancelled entries.

1. Find an expired or cancelled entry
2. Click "Delete"
3. Entry is permanently removed

Automatic Waitlist Notifications

The system automatically notifies waitlist customers when:

• A booking is cancelled
• A booking is marked as no-show
• Slot capacity is increased

Notification Process:

1. Booking cancelled/no-show detected
2. System checks slot capacity
3. Eligible waitlist entries identified (by party size and position)
4. Top entries notified automatically
5. Customers have 1 hour to respond

Scheduled Processing:

• Every 15 minutes: Expire old notified entries
• Every 15 minutes: Send expiration reminders
• Daily 3 AM: Clean up stale entries (90+ days old)
• Daily 6 AM: Generate summary statistics

Waitlist Statistics

Key Metrics:

• Total entries by status
• Conversion rate (converted / total)
• Average wait time
• Entries by product

Use Statistics To:

• Identify high-demand products
• Optimize capacity allocation
• Improve customer communication
• Track waitlist effectiveness

Best Practices

Optimizing Waitlist:

1. Monitor waiting counts regularly
2. Review conversion rates
3. Consider capacity increases for high-wait products
4. Respond quickly to cancellations
5. Keep expiration windows appropriate

Customer Communication:

• Waitlist offers expire in 1 hour by default
• Reminder sent 30 minutes before expiration
• Clear email templates explain the process
• Customers can accept via link in email

Dead Letter Queue (DLQ)

Understanding DLQ

The Dead Letter Queue contains messages that failed to process. These typically include:

• Failed notifications
• Payment processing errors
• Booking operation failures
• System errors

Viewing DLQ

DLQ Dashboard:

• List of failed messages
• Error details
• Retry options
• Resolution actions

Message Information:

• Error type
• Error message
• Timestamp
• Retry count
• Related booking/transaction

Processing DLQ Items

Retry Options:

• Automatic Retry: System retries automatically
• Manual Retry: Admin triggers retry
• Manual Resolution: Fix and mark resolved
• Skip: Mark as skipped (with reason)

Resolution Process:

1. Review error details
2. Understand failure cause
3. Choose resolution action
4. Retry or resolve
5. Verify successful processing

DLQ Alerts

Alert Configuration:

• Threshold for alerting
• Alert recipients
• Alert frequency
• Escalation rules

Alert Types:

• High DLQ volume
• Critical failures
• Repeated failures
• Payment processing issues

Operational Best Practices

Daily Checklist

Morning:

• Review today's bookings
• Check pending holds
• Verify capacity
• Review maintenance schedule
• Check for alerts

During Day:

• Monitor new bookings
• Process cancellations promptly
• Mark arrivals accurately
• Handle no-shows
• Update booking statuses

End of Day:

• Mark completed bookings
• Process pending refunds
• Review tomorrow's schedule
• Check DLQ items
• Update maintenance if needed

Efficiency Tips

1. Use Calendar: Visual management is faster
2. Batch Operations: Process similar items together
3. Automation: Enable automatic features when possible
4. Notifications: Stay alert to system notifications
5. Documentation: Document special cases

Communication

Customer Communication:

• Notify promptly about changes
• Explain policies clearly
• Provide alternatives when possible
• Follow up after issues

Internal Communication:

• Document decisions
• Share important updates
• Coordinate with team
• Maintain audit trails

Troubleshooting

Common Issues

Bookings Not Showing:

• Check date range
• Verify filters
• Check booking status
• Refresh view

Cancellation Errors:

• Verify policy allows cancellation
• Check timing requirements
• Review refund calculation
• Contact support if needed

Refund Issues:

• Check refund status
• Verify payment method
• Review processing time
• Check for errors

No-Show Detection:

• Verify detection settings
• Check booking times
• Review arrival records
• Manual marking available

Next Steps

• Learn about Daily Overview in dashboard documentation
• Review Calendar for visual booking management
• Check Reports for operational analytics
• Explore Catalog Management for product configuration