I build the automations operations teams run on.

ProblemWhen a guide, price or balance changed on a booking, the reason sat in a long audit log that only a few people could read. Support and ops waited on the tech team for every answer.

What I builtAnyone mentions the bot with a booking reference and a question. It reads the booking's full history without any ability to change it, parses every entry, and replies in the thread with the cause. Follow-up questions continue in the same thread without another mention. I extended the same pattern to product and promotion logs.

Design choice: strictly read-only, so the bot can explain a booking but can never alter one.

1. @mention in Slack
2. Extract booking ref
3. Read-only log fetch
4. Parse history
5. LLM explains cause
6. Threaded reply

ProblemCustomer reviews from several platforms were logged by editing a shared Google Sheet by hand. Rows could be overwritten and low ratings were logged without evidence.

What I builtA small web app for logging reviews. Each entry is validated on save, and anything under five stars needs a screenshot. An LLM call suggests whether a complaint is about the guide or something else. Edits go into a queue and a writer workflow flushes it into the sheet every minute, while a snapshot copied every 10 minutes keeps the app fast. Direct edit access to the sheet was removed.

1. Web app
2. Save webhook + validation
3. Edit queue
4. Writer, every 1 min
5. Sheet

ProblemOverpaid or part-paid bookings were found late, often only at reconciliation time.

What I builtA watcher that posts to Slack when a booking's balance goes off or changes, and replies in the same thread once it returns to zero. It combines a webhook queue, a 5-minute check and a daily sweep so a missed event cannot hide a problem. A companion batch job read each flagged booking's log and stored the cause.

Related data work: recovered 444 bookings missing from the master sheet by looking them up directly in the booking API and appending what it found.

1. Webhook queue
2. 5-min check
3. Daily sweep
4. Compare to known balance
5. Slack alert
6. Thread reply when settled

ProblemTeam leads wanted regular numbers on reviews, sales, merchandise and upgrades, but the data lived across Monday boards, a warehouse and several sheets.

What I builtA monthly pipeline that joins the three sources across a five-layer team structure and posts to each team's Slack channel. It picks one of three message templates (standard tour, cooking class, single-tour destination), unifies four cooking class types, and ranks city-level sales leaderboards where team-level attribution was not possible.

1. Monthly schedule
2. Monday + BigQuery + Sheets
3. Roll up by team layer
4. Choose template
5. Slack post

ProblemReviews arrived on several marketplaces, each with its own format and account, and replies were written from scratch.

What I builtPipelines that pull reviews from each platform, remove duplicates, match them to the right guide, draft a reply, and write everything to one unified Monday.com board. Reviews under five stars follow a separate path.

1. Platform APIs
2. De-duplicate
3. Match guide
4. Draft reply
5. Unified board

ProblemMonth-end statements for partners and suppliers were assembled by hand, and every correction meant redoing the summary.

What I builtOn the first of each month, a workflow pulls the previous cycle's bookings, totals them per partner, applies manual adjustments from a sheet, and files the result on a Monday.com board. It builds a spreadsheet and Excel breakdown and emails the partner with a response link to confirm or dispute. Promo-code partners run through a second stream, adjustment problems raise an alert, and a corrected summary can be re-sent through one generic webhook. A companion invoice flow handles disputed and approved states, confirmation and upload.

1. 1st of month
2. Pull bookings
3. Total per partner
4. Apply adjustments
5. Sheet + Excel breakdown
6. Email: confirm or dispute

ProblemOffboarding steps lived in email threads and memory, and HR depended on someone technical for every change.

What I builtA Monday.com offboarding board driven by a Make scenario. A submitted form triggers the notice email and creates the board with its checklist. I made the logic readable enough that HR can ask for changes directly, and tested edits on a copy of the scenario before touching the live one. I also wrote plain-English documentation of recruitment, onboarding and offboarding scenarios for a leadership presentation.

1. HR form
2. Make scenario
3. Notice email
4. Offboarding board
5. Checklist groups

ProblemReplying to Google reviews meant checking each business profile by hand. Reviews with a star rating but no text, and reviews logged but never answered, slipped through.

What I builtOne hourly poller that replaced a separate workflow per location. It reads the list of live locations from a Monday.com board, so adding a location means adding a row. A shared review agent removes duplicates against the board, logs each review, decides whether it needs a reply (including star-only reviews), drafts one with an LLM, posts it through the Google API, and writes the outcome back to the board and Slack. Every failure branch raises a Slack alert.

Debugging worth noting: I traced a silent loss of items (50 in, 34 out) to a built-in node that batched many lookups into one call, and a sub-workflow that returned only its last branch. I replaced both with direct API calls and an explicit merge step.

1. Hourly schedule
2. Live locations from Monday
3. Fetch reviews
4. De-duplicate + log
5. LLM drafts reply
6. Post to Google
7. Outcome to board + Slack

ProblemWhen a sales channel removed a discount from an existing booking, someone had to notice and re-apply it by hand.

What I builtA webhook receives every booking update, checks whether an offer was removed, matches it to the right internal offer, and re-applies it through the booking API. Slack gets a summary of what changed. A discount with no internal match stops and raises an alert instead of guessing, with instructions for the fix.

1. Booking update webhook
2. Offer removed?
3. Match internal offer
4. Re-apply via API
5. Slack summary

ProblemGuides and hosts needed a dependable heads-up about the next day's tours, without checking a scheduling board.

What I builtAt 8 PM local time, a workflow pulls tomorrow's tours from the scheduling board, skips cancelled ones, and splits multiple guides and hosts. It matches each person to a private Slack channel from a directory sheet, tags them by looking up their Slack account by email, and sends one message per person, sorted by time, even when they have several tours. Each message says plainly that pax can still change, and warns when a tour shows zero pax. I migrated it from Make to n8n.

1. Daily 8 PM
2. Tomorrow's tours
3. Skip cancelled
4. Match to directory
5. Tag in Slack
6. One message per person

ProblemCustomer questions by phone and text were answered one at a time by staff, including many routine ones.

What I designedAn architecture for AI agents with a four-tier escalation hierarchy, tying together telephony, voice, SMS, workflow automation and the booking and operations systems, so routine questions are resolved early and complex ones reach a person with context.

1. Inbound call or SMS
2. Tier 1
3. Tier 2
4. Tier 3
5. Tier 4