```html

Automating Event Calendar Synchronization and Dispatch Operations Across Multi-Site Infrastructure

This session involved significant infrastructure consolidation and automation, integrating Google Calendar management across multiple business domains while establishing automated dispatch systems for field operations. The work demonstrates patterns for managing distributed event data and implementing reliable automation across loosely-coupled services.

Core Problem Statement

Multiple sites and business domains were operating with fragmented scheduling systems:

  • Manual Google Calendar entry for recurring event holds (Sea Scout Wednesday blocks)
  • Disconnected booking platform integrations (GetMyBoat, Boatsetter) without calendar sync
  • Email-driven task management without automated confirmation workflows
  • Boat cleaning operations requiring manual dispatch coordination

The session focused on consolidating these into API-driven automation layers, reducing manual touchpoints and improving data consistency across platforms.

Technical Architecture: Calendar Synchronization System

Google Apps Script Replacement Infrastructure

The primary system for calendar management lives in /Users/cb/Documents/repos/sites/queenofsandiego.com/rady-shell-events/apps-script-replacement/. The CalendarSync.gs file (deployed to Google Apps Script via Clasp) manages bidirectional calendar synchronization:

  • Polling Interval: Every 15 minutes, the script checks for new bookings and platform events
  • Email Notifications: Uses GmailApp.sendEmail() for confirmation and error reporting
  • Calendar API Integration: Direct access to Google Calendar API for event creation/modification
  • External Platform Hooks: Handles iCal feed polling from GetMyBoat and Boatsetter

The script was updated multiple times during this session to correct polling intervals and email destination addresses. The deployment process uses .clasp.json project mappings located in each site directory to route code to the correct GAS project ID.

Lambda-Backed Calendar API

For programmatic calendar operations beyond GAS capabilities, a Lambda function serves as a REST API endpoint:

  • Function Name: Located in the dashboard infrastructure
  • API Gateway Integration: v2 HTTP API with route-based action dispatch
  • Actions Supported: add-calendar-event, list-events, update-event
  • Authentication: Dashboard token-based auth (stored in repos.env)

The Lambda function downloads event requests and interacts with Google Calendar API directly using stored service account credentials. This enables server-side event creation without exposing calendar permissions to client applications.

Dispatch and Automation: Boat Cleaning Operations

A new dispatch automation system was created to manage boat cleaning service coordination:

  • Primary Script: /Users/cb/Documents/repos/tools/dispatch_boat_cleaner.py
  • Purpose: Parses booking notifications and generates dispatch orders
  • Integration Points: Reads from email inboxes via Gmail API, writes to task queue systems
  • Deployment: Shell script wrapper at /Users/cb/Documents/repos/tools/deploy_dispatch_boat_cleaner.sh

The dispatcher subscribes to booking platform webhooks (simulated via polling), extracts key details (date, location, boat ID), and creates time-stamped dispatch records that field operations can retrieve.

Campaign Scheduling Infrastructure

A secondary but important system handles marketing campaign distribution:

  • Configuration: /Users/cb/Documents/repos/tools/campaign_schedule.json defines templates, recipients, and timing
  • Scheduler Script: /Users/cb/Documents/repos/tools/campaign_scheduler.py manages queue and execution
  • Email Templates: HTML templates in /Users/cb/Documents/repos/tools/templates/ directory (separate templates for Rady Shell and other campaigns)
  • Deployment: /Users/cb/Documents/repos/tools/deploy_campaign_scheduler.sh

This system decouples content management from delivery, allowing non-technical staff to modify templates without touching scheduling logic.

Site-Specific Implementations

quickdumpnow.com Operations Tooling

The QuickDumpNow site required specialized tools for consumer engagement:

  • Blast Script: /Users/cb/Documents/repos/sites/quickdumpnow.com/tools/qdn_consumer_blast.py — iterates through customer database and generates email content
  • Statistics Collector: /Users/cb/Documents/repos/sites/quickdumpnow.com/tools/qdn_stats.py — aggregates opens, clicks, and conversion metrics
  • Templates: Located in /Users/cb/Documents/repos/sites/quickdumpnow.com/marketing/templates/
  • Unsubscribe Handling: Dedicated landing page at /Users/cb/Documents/repos/sites/quickdumpnow.com/unsubscribe/index.html with database sync

The consumer blast script went through multiple iterations to handle edge cases around customer segmentation and template variable substitution.

Key Architectural Decisions

Why Lambda for Calendar Operations?

Google Apps Script has execution time limits (6 minutes) and restricted scheduling. Lambda provides:

  • 15-minute timeout capability for batch operations
  • Direct CloudWatch logging and error tracking
  • Fine-grained IAM permissions for service accounts
  • Horizontal scaling for concurrent calendar updates

The split between GAS (for webhook-triggered, low-latency updates) and Lambda (for batch, high-volume operations) reflects these constraints.

Gmail API for Email Parsing

Rather than forwarding confirmation emails to custom processing addresses, the system uses Gmail API directly:

  • Queries existing inbox with label filters (e.g., label:booking-confirmation)
  • Parses message bodies with regex patterns specific to each booking platform
  • Maintains audit trail within Gmail labels rather than separate databases

This reduces infrastructure surface area and avoids setting up custom mail parsing infrastructure.

Polling Over Webhooks

The platform inbox scraper (/Users/cb/Documents/repos/tools/platform_inbox_scraper.py) uses polling rather than requesting webhook setup with third-party platforms:

  • Simpler for platforms without webhook support (some older booking systems)
  • Easier to debug (can replay historical emails)
  • No external endpoint exposure required
  • Trade-off: 15-minute polling interval acceptable for non-urgent updates

Infrastructure Changes and Deployment

No CloudFormation or Terraform changes were