Zapier + Procore: Slack Notifications for Any Project
Zapier's Procore triggers lock you to one project. Here's how to build a custom Zapier trigger against the Procore API so Slack alerts work across all projects.
BlueWatch to Notion: Sync bookings, inventory, and CRM with Zapier webhooks
Sync BlueWatch bookings, inventory, and CRM data into Notion using Zapier webhooks or Make. Step-by-step integration guide for surf schools and tour operators.
TABLE OF CONTENTS
TL;DR
If your booking system (like BlueWatch) doesn’t have a native Zapier app, you can still sync bookings into Notion by using Zapier Webhooks (or Make.com) as a middleware layer. The core pattern is: Booking system event → webhook/API → Zapier/Make → Notion databases, then Notion automations handle follow-ups, reminders, and reporting.
Who this is for
- Surf schools, watersports schools, tour operators, and other booking-based businesses
- Teams running multiple locations (separate accounts) who want a single “source of truth” in Notion
- Operators who need a lightweight CRM + inventory + staffing layer on top of the booking tool
BlueWatch–Notion integration architecture (how the pieces fit)
The standard flow
- BlueWatch captures bookings, customers, payments, and lesson schedules.
- Middleware (Zapier or Make) receives events (webhooks) or pulls data via API on a schedule.
- Notion stores operational data in databases (Bookings, Customers, Inventory, Coaches, Partners).
- Notion automations create internal notifications and workflows (overdue rentals, follow-ups, weekly coaching totals, etc.).
What you can’t do directly
BlueWatch typically won’t connect to Notion “directly” without a middleware step. If there’s no native Zapier connector, you’ll rely on:
- Webhooks (push-based, real time), or
- API polling (pull-based, runs on a schedule)
Step 1: Design your Notion databases first (so your sync doesn’t get messy)
Create these core databases in Notion:
Bookings
Recommended properties:
- Booking ID (unique; should match BlueWatch ID)
- Customer (relation)
- Location
- Lesson type / service
- Start time / end time
- Coach (relation)
- Status (booked / completed / cancelled / no-show)
- Amount paid
- Source system (BlueWatch)
Customers
- Customer ID (unique)
- Name
- Phone
- Total spend (rollup)
- Last booking date (rollup)
Coaches
- Coach ID (unique)
- Name
- Location(s)
- Lessons (relation)
- Lessons this week (rollup filtered by date)
- Lessons this month (rollup filtered by date)
Inventory (boards, wetsuits, gear)
- Item ID (unique)
- Category (board / wetsuit / other)
- Size
- Current status (available / out / needs repair / retired)
- Current renter (relation to customer)
- Due back (date/time)
- Returned? (checkbox)
Partners (hotels, agencies, affiliates)
- Partner ID (unique)
- Name
- Contact info
- Location
- Bookings (relation)
- Revenue driven (rollup)
Step 2: Choose your sync method (decision tree)
Use this to pick the simplest reliable option.
A) If BlueWatch supports webhooks (best for real-time operations)
Pick this when you need:
- Instant booking alerts
- Inventory “due back” workflows
- Near-real-time staffing updates
How it works:
- A booking is created/updated in BlueWatch
- BlueWatch sends a webhook to Zapier/Make
- Zapier/Make creates or updates a row in your Notion Bookings DB
B) If you only have API access (good enough for most teams)
Pick this when:
- Real-time isn’t required (e.g., reporting dashboards)
- Your API coverage is strong but webhooks aren’t
How it works:
- Zapier/Make runs every X minutes
- It fetches recent bookings/customers
- It upserts them into Notion
C) If API access is limited (or the tool is “CSV-first”)
Pick this when:
- Your booking tool can export CSVs but the API is limited/locked
- You want a low-maintenance fallback
How it works (common pattern):
- Export (or automatically drop) CSVs into a Google Drive folder
- Middleware watches the folder and parses new CSVs
- Middleware upserts rows into Notion
Get help building your BlueWatch–Notion integration
Once data is reliably in Notion, you can build workflows like:
1) Overdue rentals (replace the paper checklist)
Pattern:
- Booking/rental comes in with start time + duration
- Notion calculates “Due back”
- If “Returned?” is unchecked and current time > due back → trigger notification
2) Weekly coach lesson counts
Pattern:
- Each booking links to a coach
- A filtered rollup counts bookings this week by coach
- A weekly view shows who is under/over target
3) Lightweight CRM and follow-ups (Gmail-driven leads)
Pattern:
- New lead email (tagged in Gmail) creates a Lead record in Notion
- Notion stages: New → Contacted → Proposal → Won/Lost
- Automations remind your team to follow up if a lead stalls
4) Marketing reporting (Google Ads + SEO)
Pattern:
- Pull campaign performance into Notion (daily/weekly)
- Maintain a simple dashboard with spend, ROAS, and top campaigns
- Link campaigns to locations/services to spot what’s working
Step 4: Implementation checklist (quick start)
Confirm which BlueWatch plan includes public API access
Identify which objects you need: bookings, customers, coaches, inventory, partners
Create your Notion databases + decide the “unique ID” for each
Build the middleware workflow (webhook or polling)
Upsert into Notion (create if missing, update if exists)
Add Notion automations for alerts and reminders
Create views/dashboards for weekly operations
Common pitfalls (and how to avoid them)
- No unique IDs → you’ll get duplicate rows. Always store the source system ID.
- Trying to sync everything → start with bookings + customers; add inventory and partners next.
- Real-time expectations → if you’re polling, set realistic refresh times.
- Multi-location complexity → standardize IDs and location naming across accounts.
CTA
If you’d like help building this end-to-end (BlueWatch → middleware → Notion databases + automations), book a discovery call: https://connex.digital/book/website
Related Posts
InvestNext webhooks to HubSpot: implementation playbook
Sync InvestNext webhooks into HubSpot via Zapier or Make: event mapping, object modeling, idempotency, retries, and monitoring to prevent duplicate records.
