Design Exercise Response

Post-Acceptance Partner Communication Flow

Design Exercise Response by Kenneth Buan Pineda

Airtable + Zapier architecture, failure-mode driven design.

11 clarifying questions 4-table schema 9 failure modes mitigated 2 recommendations
Clarifying Questions

1. What I would ask before building

# Link copied

These are the questions I would genuinely ask before writing a single automation. Each one changes the design. Click any question to see why it matters.

Q1 Can one client have multiple accepted offers at the same time? # Link copied +
Why this matters

Decides where the automation triggers. If yes, the trigger must live on the Offers table, not the client record. Getting this wrong means the second offer never fires or fires wrong.

Q2 Who marks the offer as Accepted? # Link copied +
Why this matters

A person clicking a dropdown can misclick and flip it back 30 seconds later. If human-driven, I add a short delay buffer before the send fires.

Q3 Where are partner emails stored? # Link copied +
Why this matters

Is there a Partners table linked to the offer? Some partners have multiple contacts who all need the notification.

Q4 What is the definition of "all required documents"? # Link copied +
Why this matters

A fixed list that is the same for every client means simple checkboxes. A list that varies per offer type means a separate Requirements table.

Q5 Do clients submit documents all at once or one by one over days? # Link copied +
Why this matters

If one by one, does the partner get one email per document (annoying) or one batch email when complete? I default to batch.

Q6 Where do the written clarifications live? # Link copied +
Why this matters

If they sit in a general notes field, internal team comments will eventually be emailed to an external partner by accident. I require a dedicated shareable field.

Q7 What is the expected total attachment size? # Link copied +
Why this matters

Email caps out around 20 to 25MB. Large scanned bank statements need a secure link fallback.

Q8 What email account sends these? # Link copied +
Why this matters

A monitored shared inbox vs no-reply decides whether partner replies and bounces are ever seen by a human.

Q9 Are these documents sensitive or regulated? # Link copied +
Why this matters

Offers with amounts and terms plus supporting documents sound financial. That changes whether attachments are even appropriate (see Recommendation 1).

Q10 What happens if the partner does not act? # Link copied +
Why this matters

Step 1 invites the partner to call the client. Do we track whether they did? Is there a follow-up if 5 days pass silently?

Q11 What is the monthly volume? # Link copied +
Why this matters

10 accepted offers per month vs 500 changes the tooling, the error-handling depth, and whether bounce webhooks are worth building.

Architecture

2. End-to-end automation flow

# Link copied

Three triggered sequences. Airtable validates and flips internal flags; Zapier owns every outbound email and writes a timestamp back only after a confirmed send. Colour legend: trigger · human checkpoint · Zapier · write-back.

1
Offer accepted → notify partner
TriggerOffer status = Accepted
Airtable automationValidate partner email, amount & term all exist
AirtableSet Ready for Partner Notify checkbox
ZapierEmail partner offer details from monitored inbox
Write-backPartner Notified At timestamp → Airtable
2
Documents received → forward to partner
TriggerDocs uploaded to the offer
Human checkpointReviewer ticks Docs Reviewed
Airtable flagFlag raised for Zapier
Size check branch
≤ 20 MBAttach files directly to email
> 20 MBSend secure expiring link
ZapierEmail partner + shareable clarifications
Write-backDocs Sent At timestamp → Airtable
3
Completion → thank partner & pre-frame handoff
TriggerAll required docs checked → formula flips to Complete
Airtable flagCompletion flag raised for Zapier
ZapierThank-you + client handoff pre-frame email
Write-backHandoff Sent At timestamp
AirtableStatus moves to Handed Off

Design principles

  • Everything keys off the OFFER record, not the client. Clients hold multiple offers over time.
  • Airtable validates BEFORE any flag is set, so Zapier never fires with incomplete data.
  • Zapier owns every outbound email, sent from a real monitored inbox, never Airtable's domain.
  • Every send writes a timestamp back to Airtable AFTER confirmed success. The timestamps are the audit trail and the idempotency guard.
  • One human checkpoint (Docs Reviewed) before documents go external. Everything after it is automated.
Data Model

3. Airtable base structure

# Link copied

Four linked tables. Checkboxes drive the automations, timestamps make every send idempotent, and a dedicated Shareable Clarifications field keeps internal notes from ever reaching a partner. Click any table name to collapse it.

📁 BKH-style Base
├── 📋 Clients
│   ├── Name (single line text)
│   ├── Email (email)
│   ├── Phone (phone)
│   └── Offers (linked → Offers)
├── 📋 Offers  ← all automation keys off this table
│   ├── Offer ID (autonumber)
│   ├── Client (linked → Clients)
│   ├── Partner (linked → Partners)
│   ├── Amount (currency)
│   ├── Term (single select)
│   ├── Status (single select: Pending / Accepted / Docs In Progress / Docs Complete / Handed Off / Dead)
│   ├── Ready for Partner Notify (checkbox, set only by validation automation)
│   ├── Docs Reviewed (checkbox, human checkpoint)
│   ├── Shareable Clarifications (long text, ONLY field the Zap reads)
│   ├── Partner Notified At (timestamp write-back)
│   ├── Docs Sent At (timestamp write-back)
│   ├── Handoff Sent At (timestamp write-back)
│   ├── Docs Complete (formula: all required docs received)
│   └── Attachments (attachment)
├── 📋 Partners
│   ├── Partner Name (single line text)
│   ├── Contact Name (single line text)
│   ├── Email (email)
│   ├── Backup Contact Email (email)
│   └── Offers (linked → Offers)
└── 📋 Required Documents  (only if checklist varies per offer)
    ├── Document Name (single line text)
    ├── Offer (linked → Offers)
    ├── Received (checkbox)
    ├── Attachment (attachment)
    └── Notes (long text)

Responsibility split

Each tool does what it is best at: Airtable owns the data and the gatekeeping logic; Zapier owns everything that talks to the outside world and can fail.

Airtable Automations

  • Pre-send validation (email, amount, term all present)
  • Completion formula across required documents
  • Setting and clearing internal flags & checkboxes

Zapier

  • Outbound email from a monitored inbox
  • Attachment size branching (attach vs. secure link)
  • Timestamp write-backs after a confirmed send
  • Error handling and retries
The one-line reason: Airtable automations are fast and free, but they have poor error visibility and send from Airtable's own domain — which looks unprofessional to partners. Zapier sends from your real monitored inbox, surfaces failures, and retries.
Resilience

4. Failure mode analysis

# Link copied

The section that matters most. Nine ways this design can break, and how each one is prevented or surfaced.

1Double firing # Link copied
What goes wrong
Someone sets status to Accepted, realizes it is the wrong offer, changes it back, then sets the correct one. Or the same offer is set to Accepted twice.
Prevention
Before sending, the Zap checks if Partner Notified At already has a timestamp. If yes it stops. Every send is idempotent. I used this exact pattern on a Fanbasis webhook integration where payment webhooks sometimes fired twice.
2Missing partner email # Link copied
What goes wrong
Offer accepted but the partner record has no email or a typo.
Prevention
The validation automation refuses to set the Ready flag, marks the record Blocked: missing partner email, and alerts the team. The problem is visible immediately instead of a silent Zap error.
3Email bounce # Link copied
What goes wrong
The address exists but bounces. Zapier reports success because the handover to the mail server worked.
Prevention
Send from a real monitored inbox so bounces are seen. At higher volume, route through an email API with bounce webhooks that write back to Airtable.
4Oversized or wrong attachments # Link copied
What goes wrong
A 30MB scan or an unreadable photo.
Prevention
A size-check branch routes oversized sends to a secure folder link and flags the record. For wrong content, the human Docs Reviewed checkpoint is the catch; no automation can recognize an unusable document.
5Partial documents looping # Link copied
What goes wrong
Client sends 2 of 5 docs, then 1, then 2 more. Triggering on attachment changes means 3 partner emails with overlapping files.
Prevention
Trigger on the reviewed/complete checkbox, not attachment events. If interim updates are wanted, a daily digest instead.
6Internal notes leaking # Link copied
What goes wrong
Clarifications stored in a general notes field means an internal comment eventually goes to an external partner.
Prevention
A dedicated Shareable Clarifications field is the only field the Zap reads. Internal notes live elsewhere.
7Zap fails mid-flow # Link copied
What goes wrong
Failure after downloading attachments but before sending leaves the record stuck.
Prevention
Timestamps are written only after a confirmed send, so failures are visible as flagged-but-not-timestamped records. A daily sweep automation alerts on any record stuck in that state for more than a few hours. Nothing fails silently.
8Status moved backwards # Link copied
What goes wrong
An offer at Docs Complete is manually dragged back to Accepted.
Prevention
Every send checks its own timestamp first, so re-fires are no-ops. The timestamps protect the system from humans doing human things to the status field.
9Partner replies lost # Link copied
What goes wrong
Replies to a no-reply or unmonitored address die.
Prevention
Send from a monitored shared inbox and name the contact person in the email body.
Considered Pushback

5. What I would push back on

# Link copied

Both keep effort roughly the same while removing real risk — the kind of thing worth flagging early rather than discovering in production.

1Email attachments for financial documents # Link copied

These appear to be financial documents. Attachments are uncontrolled copies: cannot be revoked, cannot be tracked, and sit in inboxes forever.
Recommendation

Send a secure expiring link to a per-offer shared folder instead. Same automation effort, better security posture, and the attachment size problem disappears entirely.

If partners insist on attachments, fine, but that should be a conscious decision, not a default.

Same effortRevocableNo size limits

2Partner calls the client before the client is told # Link copied

Step 1 invites the partner to call a client who has not been told to expect the call. From the client's side, a near-stranger suddenly calls about missing paperwork.
Recommendation

Either send a parallel client email in Step 1 ("you may hear from [Partner], they can help with your documents") or hold the call invitation until Step 2.

The parallel email is one extra Zap step and keeps the client experience clean.

One extra Zap stepCleaner client experience