FE
Master Platform Plan · Skeleton Draft

Field Engineer
Platform Plan

The single source of truth for what the platform does, how it's built, and where it's going — structured to feed a technical design guide, a user instruction guide, and an investor package.

Working draft · expand section by section
About this draft. This is the skeleton. The Product Overview, Tool Map, and Roadmap sections are written; the per-tool and technical sections are scaffolded with a consistent template and short notes marked [expand] for us to fill in together.

Contents

  1. How to use this document
  2. Product overview
  3. Tool map & how the pieces connect
  4. Status legend
  5. Tool specs — Sales / Survey
  6. Tool specs — Pricing / Price Book
  7. Tool specs — Tech / Repair Copilot
  8. Tool specs — Inventory
  9. Tool specs — Customer Service Request
  10. Tool specs — Install (future)
  11. Data & architecture
  12. Security & credentials
  13. Roadmap & status
  14. Open questions & decisions

01How to use this document

One master plan, three downstream documents. The same facts are told at three depths, so keeping them in one place keeps them from drifting apart.

Downstream documentAudiencePulls from
Technical design guideDevelopersPer-tool step logic, Data & architecture, Security & credentials
User instruction guideTechs & salespeoplePer-tool step-by-step (the friendly retelling), Tool map
Investor packageInvestors / partnersProduct overview, Tool map, Roadmap & status

02Product overview

What it is

Field Engineer is a mobile-first platform for a residential HVAC service-and-replacement business. It standardizes how the company evaluates jobs, prices them, repairs equipment, and manages parts — encoding the judgment of an experienced operator into tools any team member can use in the field.

The problem it solves

Field outcomes today depend heavily on the individual: a strong salesperson sizes and quotes well, a senior tech diagnoses fast, and the right parts are (sometimes) on the truck. That variability caps growth and quality. Field Engineer raises the floor — it makes a newer salesperson or technician perform closer to a seasoned one, consistently, while protecting margin and creating a record of every job.

Who it's for

The core thesis

Encode senior-level process once; deliver it to everyone; protect the business's economics while doing it. The same equipment-identification and AI backbone serves every tool, so the pieces compound rather than stand alone.

03Tool map & how the pieces connect

Five internal tools plus a planned customer-facing app, all sharing one backend and AI layer. Pricing feeds Sales; Inventory is read by Tech and the future customer app; everything that needs the model or an external lookup goes through one backend.

Sales / Surveyrecommendation Pricingcost → customer price Tech / Repairdiagnose & fix Inventorytruck & shop Customerrequest service(planned, separate) prices SHARED BACKEND/api/lookup · holds keys · stateless relay Anthropic (Claude)vision · diagnosis · search RentCastproperty records VendorsFerguson · Johnstone…

04Status legend

Every section is tagged so readers always know what exists today versus what's designed.

Built working and deployed   First pass built but intentionally shallow   Planned designed, not built   Future later stage

05Tool — Sales / Survey First pass

Purpose
Run a replacement evaluation at the home and produce a margin-aware Good/Better/Best recommendation with rebates.
Who uses it
Salesperson / comfort advisor.
Step-by-step (outline)
Customer & property (with address property lookup) → systems (multi-zone, nameplate photo read) → site conditions → comfort & needs → recommendation (per-system sizing, Good/Better/Best, flags) → rebates → copy summary.
Inputs / outputs
[expand] — enumerate each step's required vs. optional fields and the exact outputs.
Rules & logic
[expand] — sizing heuristic, tier selection, flag rules (drafted in the Technical Reference; consolidate here).
Connections
Reads Pricing to put numbers on the recommendation Planned.
Open questions
[expand] — proposal/PDF output; financing; e-signature.

06Tool — Pricing / Price Book First pass

Purpose
Hold vendor cost per item, apply markup rules, produce the customer price — with cost/margin hidden in tech view (protected pricing).
Who uses it
Owner / admin (maintains it); Sales consumes the prices.
Step-by-step (outline)
Build the price book via invoice/screenshot AI import, paste, or manual entry → set default + per-item markup → owner/tech view toggle.
Inputs / outputs
[expand] — price-file ingestion format; vendor cost vs. customer price fields.
Rules & logic
Customer price = cost + markup (percent / multiplier / flat), or fixed override. [expand] — minimum-margin enforcement, manager approval (from original spec).
Connections
Feeds Sales; should link to Inventory by SKU (one source of truth) Planned.
Open questions
Vendor integration path (Ferguson API/PunchOut vs. price files); true cost-hiding needs accounts/roles.

07Tool — Tech / Repair Copilot First pass

Purpose
Guide a technician through a trouble call — confirm the problem, identify the system, diagnose on real readings, repair, verify — gated to the tech's credentials.
Who uses it
Service technicians; admin sets profiles.
Step-by-step (outline)
Pick equipment → reported vs. confirmed complaint → capture components (nameplate read, "other?") → diagnostic loop (name-it / how / enter real value) → safety stops & credential gates → repair → verify → stamped record.
Inputs / outputs
Real measured values per step + multi-photo; outputs next step / diagnosis / hard stop. [expand].
Rules & logic
Credential gating & hard stops enforced in app, not the model. Detailed in the Stage 2 spec — consolidate here.
Connections
Will read Inventory when a part is needed Planned.
Open questions
Curated diagnostic trees for top calls; offline mode; admin console.

08Tool — Inventory First pass

Purpose
Track parts on hand per location (shop & each truck); find where a part is; flag low stock.
Who uses it
Techs (find a part), admin (manage stock & trucks).
Step-by-step (outline)
Define locations → add parts with per-location quantities → search/find a part across locations → low-stock badges.
Inputs / outputs
[expand] — barcode/photo add; usage decrement; transfer requests.
Rules & logic
[expand] — reorder thresholds, auto-decrement on job use.
Connections
Link to Pricing by SKU; read by Tech and the Customer app Planned.
Open questions
Trucks per tech (tie to tech profiles?); decrement workflow; reorder list.

09Tool — Customer Service Request Planned

Purpose
A customer-facing way to request service / a quote; checks availability and routes to the team.
Who uses it
Homeowners (public).
Critical constraint
Separate build from the internal app — a customer's browser must never load internal cost, margin, inventory, or credential logic. Talks to the system only through the backend.
Step-by-step (outline)
[expand] — likely: describe problem / equipment → contact & address → preferred time → (optional) inventory/availability check → confirmation.
Open questions
Scheduling integration; lead routing; how much it reveals (availability, ballpark price?).

10Tool — Install / Commissioning Future

Purpose
Guide installation and commissioning of new systems (explicitly out of scope for the current service-focused build).
Status
Named as a future stage; not designed yet. [expand later].

11Data & architecture First pass

Shape

Single-page internal app (one HTML file, multiple tool "modes") + one stateless serverless backend (/api/lookup) that holds API keys and relays to Anthropic, RentCast, and (future) vendors. Customer app to be a separate front end on the same backend.

Storage

Per-device browser storage (platform store or localStorage fallback). Keys: surveys, tech profile, tech calls, price book + settings, inventory + locations, backend URL/token. [expand] — full data models per tool; the move to a central database for cross-device + multi-user.

AI & external services

Claude (current model) for nameplate vision, repair diagnosis, rebate search, and price extraction. RentCast for property data. Vendor pricing via files/API. [expand] — per-action request/response contracts (several already in the Technical Reference).

[expand] Consolidate the data models and the backend action contracts (property, nameplate, rebates, diagnose, parseprices) here as the canonical reference.

12Security & credentials First pass

13Roadmap & status

StageItemStatus
1Sales / Survey + recommendationFirst pass
1Property & rebate lookups (backend)Built
1Pricing / Price Book + markupFirst pass
1AI nameplate read + published-spec lookup (per equipment type)Built
1AI bill ingestion — electric & gas, two utilities, real ratesBuilt
1Tonnage-aware incentive engine + live multi-jurisdiction lookupBuilt
1AI sizing sanity check (recommendation → proposal)Built
1White-label brand config + suite naming (Empower Toolbox)Built
1/2All-electric / baseboard → ductless multi-zone path (zone pricing, gas-service gating)Built
1Capture existing cooling (swamp/none) → sell added ACBuilt
1AI multi-unit equipment identification (batch photos → auto-assembled systems)Built
3Bill consolidation & energy-story chart (customer offering)Built first pass
2Tech / Repair Copilot (Sidekick) — separate app, credential gating, safety stops, diagnostic loopBuilt first pass
2Inventory (truck & shop)First pass
3Sales↔Pricing wired; Inventory↔Pricing linkBuilt first pass
3Proposal / customer-facing pricing presentationBuilt first pass
3Customer Service Request app (extends Concierge)Built first pass
4Accounts, roles, admin console, central DBBuilt first pass
4Curated diagnostic trees; vendor API integrationBuilt first pass
5Install / Commissioning tool (Foreman)Built first pass

14Open questions & decisions

A running log so decisions are captured once and don't get re-litigated. [expand as we go]

Field Engineer — Master Platform Plan (skeleton draft). Sections marked [expand] are placeholders to fill collaboratively. Update status tags as the build advances.