End to end

A maintenance request, traced across the whole stack

Follow one real workflow — a tenant reporting a fault — from the inbox to an approved contractor quote. Every tool plays one part; the BIFF agent makes the call; the property manager approves in Slack before anything is sent. Below is exactly how it works, with the real data at every step.

The pipeline

Eight steps, one fault

A tenant emails “the air-conditioning has failed, stock is at risk.” Here is the path that turns it into an approved, sent quote request — with a human gate in the middle.

G
GmailCommunicate
Tenant emails the fault. A label/filter tags it as a maintenance matter, so the right emails — and only those — start the workflow.
Z
ZapierTrigger
A trigger fires on the new labelled email and hands the payload to the orchestration workflow.
M
MakeOrchestrate
Runs the multi-step scenario: parse the email, pull the tenant + property from Airtable, call the BIFF agent with that context.
B
BIFF AgentReason / Draft
Classifies the job as HVAC · Urgent, selects the highest-rated HVAC contractor (AirTemp 4.6★), and drafts a quote request. It never sends.
A
AirtableStore
A job record is created; the draft RFQ and the contractor scoring are written to the Approval Queue with status Pending Approval.
SlackHuman gate
The human gate. The PM gets an approval card: “Quote request to AirTemp Solutions (4.6★) — Approve / Reject.” Nothing has been sent yet.
G
GoogleCommunicate
On approval, Gmail sends the RFQ to the contractor and Calendar holds a tentative attendance slot.
N
NotionRecord
The action is logged to the audit / SOP space and the weekly maintenance report updates automatically.

The same shape runs everything

Arrears and renewals follow the identical path — only the agent's classification logic and the draft template change. Build the pattern once; reuse it across every function.

The four layers

What each app actually does

Every tool belongs to one layer and does one job well — trigger & orchestrate, reason & draft, store, then communicate / approve / record.

Trigger & orchestrate

The wiring

G
Gmail
Where work enters the system. A label/filter auto-tags inbound faults (repair, leak, broken, air-con, urgent) so only the right emails start the flow.
Z
Zapier
Watches Gmail. The moment an email gets the “Maintenance” label, a Zap fires and hands the payload downstream. Best at “event in app A → kick off app B.”
M
Make
The conductor for multi-step runs: parse the email, look up the tenant/property in Airtable, then call the agent with everything it needs.
Reason & draft

The brain

B
BIFF Agent
Where judgement happens: classifies the job (HVAC · Urgent), selects the best-rated contractor, and drafts the quote request. It drafts and recommends — it never sends or commits.
Gl
Gumloop (or Lindy)
The no-code way to build that agent — a visual flow of nodes: input → AI classify → rank contractor → AI draft RFQ → output. Same architecture, editable by non-engineers.
Store

The system of record

A
Airtable
The single source of truth. The agent's output is written as a Job record — property, issue, trade, severity, contractor, rating, draft RFQ, status. The “Approval Queue” view shows what's waiting on a human.
Communicate · approve · record

The human + the paper trail

#
Slack
The human gate. The PM gets an Approve / Reject card. Nothing is sent until they approve — the AI did the work, but a human owns the irreversible action.
G
Google — Gmail + Calendar
Acts only after approval: Gmail sends the RFQ to the contractor; Calendar holds a tentative attendance slot. The only point where anything leaves the business.
N
Notion
The memory and paper trail: an Audit Log of every action, the workflow SOP, and a weekly report that updates automatically. This is what makes it auditable.
Worked example

One request, the real data at every hop

This is exactly what each tool receives and produces for a single maintenance request — 1/63 Arthur St, Randwick.

GA · Gmail — the fault arrives
From: tenant.unit1@example.com Subject: Air-conditioning has failed — stock at risk Body: The air-conditioning at 1/63 Arthur St, Randwick has stopped working. We store temperature-sensitive stock — this is urgent. → filter matches "air-con / failed / urgent" → label: "Maintenance"
ZB · Zapier — trigger fires, hands off the payload
{ "from": "tenant.unit1@example.com", "subject": "Air-conditioning has failed — stock at risk", "body": "...has stopped working; temperature-sensitive stock...", "received": "2026-06-08T09:31:00+10:00", "label": "Maintenance" }
MC · Make — parse → look up → call agent
parse: property = "1/63 Arthur St, Randwick" issue = "air-conditioning stopped working; stock at risk; urgent" Airtable lookup → owner, lease, site contact, access notes call agent with { issue, property_record }
BD · BIFF Agent — the decision (drafts, never sends)
{ "trade": "HVAC", "severity": "Urgent", "contractor": "AirTemp Solutions", "contractor_rating": 4.6, "rfq_draft": "Dear AirTemp Solutions, we require an urgent quote for an air-conditioning failure at 1/63 Arthur St, Randwick where temperature- sensitive stock is at risk. Please advise earliest attendance + estimate." }
AE · Airtable — the job record is written
Job #3 | 1/63 Arthur St, Randwick | Air-conditioning failed, stock at risk | HVAC | Urgent | AirTemp Solutions | 4.6 | Pending Approval | <RFQ>
F · Slack — the human gate (nothing sent yet)
🔧 Maintenance — Approval needed Quote request to AirTemp Solutions (4.6★) — HVAC · Urgent 1/63 Arthur St, Randwick · air-con failed, stock at risk [ ✓ Approve & Send ] [ ✕ Reject ] (+ optional note) → PM clicks Approve. This is the only decision that releases the action.
GG · Google — act on approval
Gmail: RFQ email sent → jobs@airtempsolutions.com.au Calendar: tentative attendance slot held Airtable: status Pending Approval → Sent
NH · Notion — record it
Audit Log: 2026-06-08 09:37 · Approved & sent · PM · RFQ → AirTemp (4.6★) · Job #3 Report: weekly maintenance report +1; "urgent" SLA clock started
Build recipe

How the stack is assembled

Each tool is a few minutes of setup. Airtable is already built and live in the demo; the rest wire around it.

AppBuild steps
GmailCreate label Maintenance. Filter on keywords (repair, leak, broken, not working, air-con, urgent) → apply the label.
ZapierZap — trigger: Gmail New Labeled Email (Maintenance); action: Webhooks → POST payload to Make.
MakeScenario: Webhook → Text parser → Airtable Search → HTTP call agent → Airtable Create record → Slack message.
GumloopFlow: Input (issue + property) → AI classify (trade, severity) → rank contractor → AI draft RFQ → output JSON.
Airtable ✓ builtBase BIFF Property Ops → table Jobs (full schema) → view Approval Queue (filter Status = Pending Approval).
SlackChannel #approvals. A workflow (or Make's Slack module) posts an Approve/Reject card that writes the decision back to Airtable.
GoogleOn Status = Approved: Gmail sends the RFQ; Calendar creates the tentative slot (Make's Gmail + Calendar modules).
NotionAudit Log database (Timestamp · Action · Actor · Detail) + an SOP page. Append a row on every action.

Why this is safe to run in a real business

Two things turn an AI demo into a system you can trust with a portfolio: (1) every irreversible action waits behind the Slack approval gate, and (2) every action is written to the Notion audit log. Deterministic where it must be, AI where it adds value, human where it's irreversible.

See it running

The Airtable store and the approval queue are live in the demo Property Agent. Run the agents and watch the queue fill.