Inframark Work Orders Kickoff

1Competitive research

What best-in-class tools do, and the gap nobody fills

Maintenance CMMSUpKeep, Limble, Fiix: solid tickets and preventive schedules. But purchasing is a bolt-on module, insurance certificates are a file cabinet nobody checks at dispatch time, and the tech app still reads like a form to fill in.

Contractor field serviceServiceTitan, BuildOps: powerful dispatch and invoicing, priced per technician and built for one contractor’s own office. Wrong shape for a property organization coordinating hundreds of outside vendors across communities.

Enterprise facilitiesCorrigo, ServiceChannel: the closest match on paper - spend caps, vendor compliance, GL coding. In practice: enterprise pricing, punishing vendor portals, and field UX that assumes a back-office team.

The gap: nobody runs Inframark’s actual loop in one simple tool: request → approval that issues the purchase order → an insurance check that can actually stop a dispatch → required photo proof at arrival and completion → verified work → the cost landing in the community’s ledger and the vendor getting paid. Every tool above does two or three links of that chain. The MSA asks for the whole chain - and for field users who are maintenance and facilities people, not software people.

2Slices explained

The angles that make this version better

The PO is the spine, not a moduleApproving a request issues its purchase order in the same tap. The money then rides the order through completion: budget cap, running total, invoice match, ledger, payment. There is no such thing as untracked spend.

The insurance check can say noCOI compliance is not a report - it is a gate inside dispatch. BlueBonnet’s expired certificate visibly stops a job in the prototype, and November auto-renewals (Inframark listed as insured) are designed in.

Photos are the workflowArrival photo required, completion photo required, both matched to the order automatically - their MSA rule enforced by design. The field app will not let a job finish without them.

A field app a delivery driver could useOne decision per screen, 60px buttons, plain words. The crew never sees a PO, a status name, or a form - “what did you use” is their entire purchasing interface.

Plain English on top, system truth underneath“Crew assigned”, “On the job”, “Work done” - with the real workflow status as a small sub-label. Their vocabulary, our audit trail.

The money flows homeEvery PO line carries a GL code. Closed orders post job + cost to the community’s Vantaca ledger (designed in, shown dark) and pay out via QuickBooks - the finance-reporting ask, answered end to end.

3The prototypes

Two clickable halves of one system, seeded with realistic Inframark community data

Office view · Work Order Command · 6 surfacesToday (start-here decisions + live crew board), Work orders (list and board), the full order record with the integrated money panel, Approvals (new requests, change orders, verify-and-close), Vendors & crews with live COI status, and plain-English Reports. Every number drills to the orders behind it.

Field crew app · 7 phone screensRamon’s whole day: My Day → the job → required arrival photo → checklist + “what did you use” → required finish photo → wrap up → done. A side rail narrates what each tap does to the order, the PO and the office view.

The demo story · WO-1041One order, start to finish: a splash pad pump fails before a Saturday event. Request at 7:05 AM, approval issues PO-1041-A, Ramon’s arrival photo at 7:42, parts logged against the cap, completion photo, verify, ledger, paid. This is the walkthrough for Chris.

Seeded honestlyOne vendor with expired insurance blocking a dispatch, one job paused over its budget cap with a change order waiting, one request aging unassigned for six days. A system that only shows green tells you nothing.

Sample vs real: every community, vendor, price and photo is representative sample data. The stage ladders mirror the real backend workflow exactly (maintenance and construction kinds from work-order-workflows.ts), the PO states mirror purchase-orders.ts, and anything not yet built (Vantaca sync, COI auto-renewal season, voice notes) is shown greyed with a “designed in · Wave 2” tag - never presented as live.

3bWhat Inframark asked for, and where it shows

Their MSA deliverables list, mapped line by line

Inframark’s ask (their words)	Where it lives in the prototype
“Work order system for Maintenance solutions and Construction projects”	The whole Office view. Both kinds are real: the splash pad pump is a maintenance order, the Sienna fence replacement runs the construction ladder (scope → schedule → punch list).
“With a po system… Purchase Order system tied to all work orders and AP”	The money panel on every record: approval issues the PO, lines accrue against the cap, then invoice match → ledger → payment. The Approvals queue is the AP front door.
“…connected to Vantaca (Inframark’s current financial software)”	The Community ledger card on each order and the “Synced to Vantaca” step in the money chain - shown dark with a Wave 2 tag until credentials exist.
“Quick Books (equivalent) with API… on automation for approval any payment”	“Paid via QuickBooks” is the last step of every money chain; the closed HVAC order (WO-1030) shows it completed.
“COI - Annual auto renewals… listing Inframark as the insured”	Vendors & crews: live COI status per vendor, the expired certificate stopping BlueBonnet’s dispatch, and the November renewal-season automation card.
“Company CAM… pictures upon arrival… completion of work (matching work order to photo requirement)”	The field app’s required arrival and finish photos, matched to the order; the Photo proof panel on every office record; the “Proof on file” report.
“Financial Reporting / Budget Management… with GL coding”	Every PO line carries a GL code; Reports answers “where the money went” by community and drills to the orders. Built for the monthly readout.
“CRM… to tie into all work being quoted, proposals submitted, and work completed”	Out of scope for this prototype on purpose - the existing RippleCore CRM module is that system. Work orders link to it rather than rebuilding it.

4Good / better / best scope

Each row cites the real state of the backend, not a hand-wave

Capability	Tier	Verdict	The real blocker (or why it is close to free)
Work-order lifecycle - both kinds, full status ladder	Must	OK - Wave 1	Already built server-side: `work-order-workflows.ts` (W2.2) owns the `maintenance` + `construction` unions and transitions, with intake and closeout services beside it. Wave 1 is the v3 frontend surface, not new backend.
Integrated PO on approval - caps, lines, GL codes	Must	OK - Wave 1	`purchase-orders.ts`, `procurement-policy.ts`, `procurement-authorization.ts` and `cost-codes.ts` shipped in the W3 wave, including PO-to-budget-line linkage (migration `w3-4`). The approve-issues-PO tap is wiring, not invention.
COI gate at dispatch + renewal season	Must	Partial	`vendor-compliance.ts` already tracks per-vendor `coi_status` / expiry and surfaces coverage warnings on assignment, with `vendor-compliance-renewals.ts` beside it. The hard stop at dispatch plus the automated November chase emails are the remaining build.
Required photo proof - arrival + completion, matched	Must	Partial	R2 photo rails exist across the platform (PM daily logs, document vault). What is new: the “required at this status” enforcement and arrival/completion pairing on the work-order record.
Field crew flow - the phone experience	Must	Partial	The native mobile app (the platform’s field-facing surface, currently in QA per the maturity board) does not yet have a work-order module. Wave 1 option: ship this flow responsive-web inside v3 for the pilot crews, then graduate it into the native app.
Change orders - over-cap pause + one-tap approval	Should	Partial	Caps and approval states exist in the procurement services; the automatic pause-and-request loop shown on the Bridgeland heater is new workflow logic on top.
QuickBooks payment leg	Should	Partial	The QuickBooks / Stripe finance core is live in production (Seth, Aug 21) with sandbox connections to test against. Remaining: mapping verified work-order invoices onto it.
Vantaca ledger sync - job + cost to the community	Differentiator	Gated	The push schema already exists (migration `w3-11-vantaca-wo-po-push`). The blocker is not code: it is Vantaca API credentials and per-community ledger mapping from Inframark. Shown dark in the prototype until that exists.
Vendor self-serve - vendors accept jobs + upload COI themselves	Differentiator	Gated	Depends on vendor identity/portal decisions tied to the 456-vendor onboarding program (IOO). Design shown only as the renewal-request emails vendors receive.
Plain-English reports - money by community, response time, proof on file	Should	OK - Wave 1	Pure reads over PO lines + cost codes + status history. Frontend work with existing data.

5What this means for Wave 1

Plain recommendation, honest cost

The call: build the Office view first - the backend is already waiting for it. The W2/W3 waves quietly built most of this system’s server side (lifecycle, POs, procurement policy, cost codes, vendor compliance, even the Vantaca push schema). What Inframark cannot see or touch yet is a surface. Wave 1 is the six office surfaces in v3 wired to those existing services, plus the required-photo rule and the COI hard stop - roughly a CRM-facelift-sized frontend wave with two focused backend tickets.

Ship the field flow as responsive web inside v3 for the pilot, exactly as prototyped (it is seven screens), and graduate it into the native mobile app once the app clears QA. That gets real crews using it in weeks without waiting on an app-store cycle, and the “behind the screen” contract stays identical either way.

Honest cost: the two gated items are genuinely gated on Inframark, not on us - Vantaca needs their API credentials and ledger mapping, and vendor self-serve needs the vendor-identity decision from the onboarding program. Until then the prototype shows both dark rather than pretending. The photo-matching rule and the dispatch hard stop are real new logic and deserve their own tested tickets; everything else in the Must tier is wiring and UI.

Sequence that keeps risk low: order record + list first (they prove the data model end to end), then Approvals (the PO tap), then the COI stop, then the field flow with photos, then Today and Reports last - they are reads over everything else. Demo to Chris with the WO-1041 story the moment the record view is real.

Gate 1 deliverable · representative data only · nothing here touches the live app · branded for Inframark on the RippleCore platform