Interview Guide · Round 4

The channel inventory is foundational to documenting how documents move through the organization. Every workflow diagram that shows a "received via WhatsApp" step needs to name the specific group. Without this list, diagrams will be incomplete or wrong, and onboarding new staff will be inconsistent.

The roster currently captures: Shlomo, Andrew, Hector, JJ, Jenn, Mark, Ritchie, Michelle, Edmar, Elmie, Jao, Kim. Any additional people — lenders, title agents, inspectors, recurring subs — need to be accounted for in the workflow map so no step is attributed to a ghost role.

We have four streams (money-out triggers, money-out proofs, records, ops data). Diagramming all four simultaneously fragments attention. Knowing which one Shlomo cares most about — and whether these diagrams are for internal onboarding, the accounting team, or external review — shapes the level of detail and the visual format.

The four routers (Mark, Jenn, Ritchie, and Andrew) are single points of failure. If any one of them is out sick or traveling, documents could pile up or get lost. The playbook needs to document a named backup for each role so the system doesn't stall.

As Dropbox and QuickBooks accumulate records across multiple properties, there's no documented retention policy. This matters for compliance, cost (Dropbox storage), and clean handoffs when properties close. Knowing the rules now prevents a messy cleanup later.

Currently, the workflow docs assume all stage transitions happen through manual action (someone checks the VPT, someone sends a message). If any step triggers an automatic notification — a Zapier automation, a Google Sheets alert, a calendar reminder — those should be documented so the diagram is accurate.

The documented escalation is: router → Ritchie → Shlomo. But the playbook needs a final answer: when does Shlomo make the call, and what does he do with truly unrecognizable items (wrong party, misdirected, junk)? This ensures the "unclassifiable" path is fully closed.

The AP and accounting workflows feed into year-end reporting, but the tax extraction process itself is undocumented. Understanding who pulls QB reports, whether a CPA is involved, and what format the data needs to be in helps complete the "what happens after Elmie reconciles" picture.

The tools-systems documentation currently covers: QB Online, Dropbox, VPT (Google Sheets), Admin Junkie (WhatsApp group), Edmar's Receipts App (Port 3333), MET (bit.ly/40rgGpJ), and the JJ Allocation GSheet. But Edmar's day-to-day likely includes additional tools — bank portals, bill-pay systems, QB add-ons — that aren't yet captured. A complete inventory ensures every step in every workflow diagram points to a real tool.

We know three routing rules from Ritchie's interview: (1) Andrew/Shlomo/Brian reimbursements → Admin Junkie directly; (2) Jenn reviews Andrew's "Docs to File" items for completeness before forwarding; (3) Hector/JJ bulk receipts go to their property WA group, not Admin Junkie. But the full classification decision tree — how Jenn decides what goes where, in what order, and what edge cases she handles — is still incomplete.

The documented step is: Jenn checks completeness (property present? amount present?) and forwards to Admin Junkie. But classification likely involves adding tags, cost codes, WO references, or notes. Knowing what Jenn adds during this step determines what arrives at Edmar's inbox with full context vs. requiring follow-up.

The "RTS" status appears in the workflow but the triggers are undocumented. Knowing what makes Jenn send something back — missing property, unrecognizable vendor, duplicate submission, wrong format — lets us accurately diagram the Stage 03 exception path and helps train any backup for Jenn's role.

The documented workflow shows bills flowing from Andrew's approval to Michelle's payment prep to Shlomo's authorization. But a blocked bill — disputed amount, missing WO code, duplicate entry, vendor dispute — needs a separate path. Without documenting this, the exception will be handled differently every time, creating QB inconsistencies.

Stream 02 (money-out proofs) documents how payment screenshots flow from Shlomo to Elmie. But the reconciliation mechanics likely differ: credit card statements arrive monthly and require matching against individual charges, while bank payments are matched transaction-by-transaction. Elmie confirmed the CC sub-flow but Edmar's side of that process — how QB Bills are matched to CC charges — is still undocumented.

The pathways for labor bills and reimbursement receipts to reach QB are fully documented. General vendor expense receipts (materials, supplies, small purchases) are less clear: once Mark files them in Dropbox, something must trigger Edmar to find and enter them. Without that trigger, receipts could sit in Dropbox indefinitely. Ritchie's guess was "the weekly AP run," but that needs confirmation.

Elmie confirmed that JJ's crew billing (J&M labor) flows through the standard VPT path. But JJ's personal GC supervision fee bypasses VPT and is paid privately by Shlomo. Without documenting this, the AP system map shows a financial outflow with no record path — which creates a blind spot for any accounting review or audit.

The IHA design workflow (Jao and Kim producing architectural plans) is undocumented. Without knowing the assignment logic, version control for plan files, and the Dropbox naming convention for IHA deliverables, the design → permitting → construction handoff diagram can't be completed.

An architect template referenced a "P0/P1 Handoff Checklist" that doesn't yet exist as a VG document. Creating this document formalizes the gate between design/permitting and construction start — ensuring permits are pulled, IHA plans are in Dropbox, scope is locked, vendors are assigned, and pre-approved budget is signed before Andrew starts scheduling crews.