Proposal · June 22, 2026 Prepared by Jason · Axis Labs For: GuestShield · Holiday-Let Operations

The operational engine
that works at 2 AM.

A holiday-let service that scales to hundreds of owners can't run on heroics. Every issue — noise at midnight, no heat on a Sunday, a guest locked out at 2 AM — needs a system that already knows the category, the severity, the SLA, the responsible trade, and the owner-comms cadence before a human looks at it. This proposal designs that system, layer by layer, and hands your developer the exact spec to build from.

5 tiers
Severity model · P1 emergency → P5 info
2 AM
Designed for the worst hour, not paper
Airtable + n8n
Your stated stack · architected against
100s
Owners · the scale this engine targets
Problem → Solution

From chaos to a system that thinks before you do.

Holiday-let operations fail at the seams — the gap between intake and triage, between triage and dispatch, between dispatch and owner comms. Each gap is where the ball gets dropped. The architecture below removes the seams: every node solves a specific failure mode you live with today. Hover any node to see what it solves and how it fits the engine.

PHONE · SMS Voice + Text Line WHATSAPP Business API GUEST PORTAL Issue Form + QR EMAIL Parsed + Routed LAYER 1 · TRIAGE ENGINE Claude Classification Category · Severity · Suggested Action LAYER 2 · SEVERITY ROUTING 5-Tier SLA Clock P1 · P2 · P3 · P4 · P5 — each with response + resolution targets LAYER 3 · DISPATCH Trade Network Vetted · Region · Availability LAYER 3 · ESCALATION On-Call Human Rota · Ringer · Context LAYER 4 · OWNER COMMS Status Cadence Per-Tier Rhythm SYSTEM OF RECORD · AIRTABLE Issue · Resolution · Audit Trail LAYER 5 · QUALITY + LEARNING Audit · Playbook Update
Start Here
Hover any node →
Without this: guest issues land in five different inboxes, get triaged inconsistently, and the ball gets dropped at the seams between layers.
With this design: every node has an explicit failure mode it eliminates. Hover any layer to see what it replaces in today's workflow and how it fits the engine.
Services + Deliverables

What you get. Phase by phase.

This is a design and architecture engagement — the output is a system spec your developer can build from, not the build itself. Every phase ships a concrete document or schema you sign off on before the next phase begins.

🔍
Phase 1 · Week 1
Operational Audit + Failure-Mode Mapping
  • Founder interview + automation dev sync — current state, constraints, and the standard you want to define
  • Catalog the top 30 real-world incidents: noise, heating, access, damage, lockout, no-show, billing disputes
  • Map current escalation paths — formal and informal — and pinpoint where the ball gets dropped today
  • Document the "GuestShield standard" as it exists today vs the standard the architecture will hold the team to
🚦
Phase 2 · Week 2
Triage + Severity Architecture
  • Issue taxonomy — 6 categories × 5 severity tiers with explicit examples per cell
  • SLA matrix — response time, resolution time, and escalation trigger per tier
  • Claude triage prompt + classification logic spec — handed to your developer for n8n implementation
  • Edge-case decision trees: 2 AM, weekends, repeat issues, multi-unit, sentiment escalation
🔧
Phase 3 · Week 3
Workflow Design
  • Trade dispatch workflow — roster schema, availability windows, dispatch logic, fallback rules
  • Owner communication cadence — per-tier messaging rules, channel selection, escalation triggers
  • Internal dashboard spec — what ops sees, what the owner sees, what the founder sees
  • Cross-workflow handoffs — triage → dispatch → comms → resolution → audit, with explicit state transitions
📋
Phase 4 · Week 4 (first half)
SOPs + Service Playbooks
  • Written SOPs for the top 20 scenarios — decision trees ops can follow without thinking at 2 AM
  • Quality control loop spec — post-resolution audit questions, weekly review cadence, playbook update process
  • "GuestShield Standard" definition — measurable service-excellence KPIs with target thresholds
  • Failure-mode runbook — what to do when each system layer breaks (the system that handles its own outages)
🤝
Phase 5 · Week 4 (second half)
Documentation + Developer Handoff
  • Complete visual system diagram showing every layer + data flow — your developer builds straight from it
  • Airtable base schema spec — tables, fields, relationships, automations, validation rules
  • n8n workflow logic outlines — node-by-node decision logic in plain English, ready to wire
  • Quarterly architecture review framework — how the system stays current as GuestShield scales past the first hundred owners
Timeline

Four weeks. Mapping to handoff.

Each week ships a signed-off document the developer can build against. No drifting scope, no "we'll figure it out as we go."

01

Audit + Mapping

Top-30 incident catalog, current-state escalation map, "GuestShield standard" definition. The foundation everything else is anchored to.

Week 1
Foundation
02

Triage + Severity

Issue taxonomy, 5-tier SLA matrix, Claude triage spec, edge-case decision trees. The brain of the engine is on paper.

Week 2
Triage Spec
03

Workflows Designed

Trade dispatch, owner comms cadence, dashboard specs, cross-workflow handoffs. Every layer below triage is fully specified.

Week 3
Workflows
04

SOPs + Handoff

Top-20 SOPs, QC loop spec, Airtable schema, n8n logic outlines, system diagram. Your developer has everything needed to start building.

Week 4
Handoff
Next Step

GuestShield team — let's walk this together.

A 30-minute call where I share my screen, walk through the architecture, pressure-test it against three real incidents from the last 30 days, and confirm scope against your top operational priorities. Happy to walk through commercials on the call.