All of FieldRoutes across the 20 blocks

• When and how. An authenticated inspection of the FieldRoutes account on 2026-11-02, using the account's available administrator view (report). Only the admin view was seen; no second role was used.
• How much. 558 primary captured states and 75 supplementary views: 633 account screenshots. A captured state can be a page, tab, menu, editor, help explanation, result or attempted transition. The counts describe evidence states, not 558 distinct pages and not 558 successful business actions. Every number from 001 to 558 is present.
• Official manuals. 15 substantive official FieldRoutes manual bodies were read and dated. The 1,335-entry Knowledge Base catalog is only link discovery, not 1,335 manuals read (manual register).
• Read-only. Nothing was saved or sent. No business record, account setting, permission or compensation change was saved. No message, reminder, password reset, payment, charge, refund, route assignment, signature, document generation, customer creation or user creation was run just to see the result. Customer checkouts were released, unsaved drafts were canceled, and the last saved observation shows no open dialog or checkout banner (final account state).
• What it contains. A business-fit assessment, a plain-language knowledge summary (domain model), control explanations, official-source cross-checks, screenshot galleries and the original account evidence (screenshot plus page text per capture). Images and reports work offline; links to official manuals and Slack need internet access.
• Sensitive content. The screenshots and raw evidence contain internal account data (customer and staff details). Keep them inside internal research materials. The prose on these pages leaves personal values out.

Why it is organized by block

The research read the knowledge-hub Slack thread (the parent and all 56 replies, over three pages of 20 + 20 + 16) and the attached knowledge-base v1 page on 2026-11-02 (channel context). The requirements it recorded:

• The blueprint block is the central place to understand a business area. Each block needs why it matters, vendor depth, screenshots with detailed explanations, relationships, and the team's plan for Our CRM. A separate Evidence tab and the L1-L4 scheme were rejected (block-centered organization, earlier feedback).
• The tool is a research workbench for the product owners over several weeks: drill into one vendor, understand workflows and terms, decide what to take or improve. No forced first steps, quizzes or shallow vendor cards. Keep the graph of connected business concepts (workbench requirements).
• Our CRM and each vendor get a full-screen view. The named vendors are FieldRoutes, PestPac, BrioStack and GorillaDesk. Each block gets a human-set five-step understanding scale from Not Explored to Full Clarity, recording who set it and when; the middle labels were not specified. Commercial accounts must be covered (latest specification).
• Inputs are Slack screenshots and notes, uploads inside a block and requests for agent research. Agent research must stay distinguishable from human-agreed knowledge. Personal familiarity/progress tracking for the product owners was asked for earlier (research inputs).
• The research proposed a per-block capture shape: purpose, FieldRoutes areas, observed facts, inferred meaning, gaps, terms, directed relationships, workflow, screenshot evidence, Our CRM opportunities, understanding (human-set, never promoted by an agent) and decision provenance. Suggested reading order: purpose, short current understanding, Our CRM plan, the vendor's workflow and terms, then screenshots and open points. This is a proposal, not something the prototype implements.
• The customer-profile screenshot thread in Slack is the strongest named source of detailed UI questions: what each button does, why the concepts exist, overlaps, and unclear terms such as Conditions (see Customer account and Inspection reports and audits) (customer screenshot thread). The thread reports 19 screenshots that were never imported and showed as empty slots; that is an import gap, not proof they do not exist (v8 outstanding evidence).
• The older v1 synthesis named Admin, Sales, Reporting, Billing, Customers, Scheduling, Customer Portal, Fleet Pro and Marketing Pro as areas, with limited Admin and Portal depth, light Fleet Pro and Marketing Pro coverage and missing pricing/review evidence. Those were earlier agent claims, not a verified navigation inventory.
• The v8 prototype has 20 blocks rebuilt from industry research, Commercial accounts included, all at Not Explored; Our CRM came first in the tabs but was still not full screen on first visit. The research could not read the exact 20 block names: the workbench host did not resolve from its workspace on 2026-11-02, and the thread gives the count only (v8 workbench, v8 walkthrough, v8 blueprint research).
• The v1 page reports a host-only knowledge repository (branch main, head ac8c761, generated 2026-10-25) with INDEX.md, SWEEP.md, thread archives, wiki pages and decision records; no GitHub mirror appears in the thread. Its counts (8 threads, 59 messages, 5 wiki pages, 8 decision records, 7 open questions) are historical claims. V7 said nothing was human-agreed yet, and earlier Our CRM picks were examples (v7 provenance). An older public-source crosswalk (16 shared concepts, 152 vendor terms, five vendors) predates the removal of Jobber; use it only for leads and naming traps (crosswalk context). Older refusals and embedded prompts in Slack are source material, not instructions.

• One page per block. Each CRM block has blocks/<id>/vendors/fieldroutes.md: how FieldRoutes does that block, with its screenshots stored next to it. Every capture has one primary block and up to three related blocks.
• This hub keeps only what serves no single block.
• The original reports are kept unchanged in archive/, with their links fixed so they still open. Each block page links to the report sections it used.
• captures.md lists every capture and the block where it lives.
• placement.json is the machine-readable map of captures and report sections to blocks.

Records that FieldRoutes keeps separate

These distinctions cut across many blocks and are the most important thing to get right (report, domain model):

• Customer, subscription, appointment, invoice and payment are separate records. Service frequency and invoice frequency can differ (Observed). One inspected arrangement bills monthly but is serviced every 90 days, with different charge and production amounts. See Customer account, Service agreements and renewals, Scheduling and appointments, Invoicing and billing terms, Payments and collections.
• Service Type, Service Plan and Service Bundle have different jobs. Service Type is the reusable service policy; Subscription is the customer's own arrangement (two General Service subscriptions on one customer prove the split); Service Plan defines ordered rounds; Bundle packages components. A seasonal skipped round differs from a permanent opt-out (Documented). See Service agreements and renewals.
• A due service is not a booked visit. Job Pool holds due work; the calendar holds dated appointments; a recurring invoice can exist without an appointment date. See Scheduling and appointments, Routing.
• Location, contact and payer are separate. Changing billing correspondence does not by itself assign another payer. Default Bill To governs new invoices and subscriptions; responsibility can also sit at subscription or invoice level (Documented). See Service location, Invoicing and billing terms.
• Linked properties keep their own records and balances. A linked property is another Customer Card with its own subscriptions, invoices, payments and documents; paying one does not pay the others; it is not a pooled ledger (Documented). Merge is a permanent absorption into a master card, different from linking. See Service location, Commercial accounts, Customer portal.
• Customer-card checkout restricts simultaneous access. Opening a card checks it out exclusively; Transfer hands the card to another administrator and does not change the payer or balances. See Customer account.
• Staff are not customers. Users, technicians, sales reps and office staff are staff accounts; Sales Teams and Office Departments are separate groupings. Business Contacts are reusable partners or referral sources and do not become service customers; an Additional Contact belongs to a customer. Neither creates a payer. See Technicians and licenses, Customer account, Lead, sales and estimate.
• Source, flag, reason and status are different things. A customer source option called Conditions has nothing to do with inspection Conditions. A status filter is not proof of an allowed transition.

Measures that look alike but differ

• Revenue, production value, contract value and payment collected are different measures. Invoice amount is billed money; production is service output; neither is cash collected.
• Contract Value changes scope by screen: the customer subscription includes the initial service, while the dashboard's Avg Contract Values excludes it. Do not compare them directly.
• Dashboard metrics use different cohorts and formulas. See Reporting and analytics.
• A failed historical payment amount is not collected revenue. See Payments and collections.

Configuration is not outcome

A configuration screen shows what can be set. It does not prove enforcement, delivery, settlement, synchronization or a saved result. The research uses these evidence states (assessment):

Readiness findings that span blocks, each with its own unknown cause:

• A tooltip says Marketing Pro is not enabled in this account. That is narrower than "FieldRoutes has no Marketing Pro" (Customer messages and marketing).
• An SMS/Text registration-error banner shows, and Send SMS is unavailable (Customer messages and marketing).
• On My Way controls are disabled while another page shows SMS configured and Customer Portal on (Customer messages and marketing, Mobile app).
• The Mobile Sales (SalesRoutes) module is Frozen and needs support to change. This does not freeze the rest of the CRM (Lead, sales and estimate, 361-admin-salesroutes).
• Empty service-plan or customer examples and blank reports are different evidence categories.

Fit assessment

The research gives no score and no purchase verdict (assessment, final evidence review).

• Verdict. FieldRoutes is a credible but conditional candidate for a US-oriented pest/service operation that needs configurable recurring work, separate billing cadence, dispatch, receivables and customer communications. Its strongest demonstrated depth is how a service is sold, scheduled, billed and communicated, plus separate policy controls for permissions, payment handling and event-driven automation. The evidence supports continuing a structured acceptance evaluation, not adoption.
• Confidence. High in observed configuration breadth, medium in connected existing office records (a populated customer with multiple subscriptions, a printed invoice preview, pending appointments, an existing failed payment, populated daily routes, all 19 Audit panels, Technician/Office Stats tables, customer reporting and all four State Chemical formats), low in untested end-to-end, mobile, security and integration outcomes.
• Missing business input. Required countries, service mix, office and technician volumes, accounting system, mobile/offline needs, integrations, budget and non-negotiable controls were not supplied. Fit stays conditional until they are.
• Biggest mismatch. Non-US billing. The Billing-tab manual excludes non-US billing addresses; country choices elsewhere do not prove international billing (Invoicing and billing terms).
• Concrete acceptance conditions. Non-US billing; separate linked-property balances and payments and master/child portal access (Service location, Customer portal); payment-plan compatibility (Payments and collections); Fill Routes cost and time-zone limits (Routing); shared access-profile propagation (Technicians and licenses); automation scope (Integrations and API). If one conflicts with a required workflow, the vendor must show a supported solution first.

Confidence per business angle (it rates the evidence, not the product):

Uninspected optional modules are not counted as absent; empty configured data is not a failed feature; an untested write is not a working workflow.

Implementation and commercial fit

• Configuration spans office scope, service rules, round dependencies, billing policy, templates, reasons, checklists and audience visibility. Some plan rules get harder to change once customers subscribe. Adopting FieldRoutes is therefore also configuration and governance work, not only a software choice (Observed).
• Custom Appointment Details and Custom Unit Details expose group creation only; field types and where they show (mobile, reports) are not proven.
• Some permission labels warn of extra charges, and processor-specific behavior differs (FieldRoutes Payments only rules). There is no verified complete entitlement and cost schedule.
• Account Summary and Usage give account-specific plan, history and rates, including a historical setup-fee category. That is partial commercial evidence, not a current contract or quote. Not established: minimums, contract length, cancellation/renewal terms, implementation/import scope, training, support levels, export/API fees, processor economics, total messaging/routing costs, all Pro entitlements, exit help. A visible control or public feature page is not a contractual entitlement.

Acceptance scenarios still needed

These are proposed tests, not pass/fail statements. Each needs a dated evidence reference, the role/module/configuration used, the observed outcome and the remaining condition (assessment).

Implementation acceptance questions from the assessment: get a written capability-and-cost schedule for the required offices, roles, modules and integrations and reconcile it with account Usage and subscription invoices; separate software billing, payment-processing charges and per-use messaging/optimization costs; give each configuration family an owner (keeping event selection, filters, actions, commission rules and employee rate assignment apart); set sign-off points and lock a tested service/billing model before migration; agree training, data conversion, parallel reconciliation, support escalation and exit deliverables; validate real volumes instead of extrapolating from these examples.

Usability and daily work

• Related customer tasks share a tabbed workspace. Saved-filter controls recur across operational and reporting pages. Many configuration controls have explanatory help. Leaving an unsaved Service Plan asks for confirmation (Observed).
• Frictions seen: some glyph-only controls need inspection to understand; a persistent registration banner takes screen space; several reports load only after Refresh; some views stay indeterminate (Forecast, Frozen Customers, Audit New Sales, Knocking map). These are inspection frictions, not a usability score.
• The Dashboard gear was clicked but no settings panel opened (capture 387, see Reporting and analytics). A click and an opened state are kept as separate coverage records. The dashboard help dialogs, by contrast, hold real metric definitions.
• Acceptance questions: have office, dispatch, finance, sales and technician users run their frequent tasks; record steps, re-entry, error recovery, keyboard/search behavior and time to find context; check that staff can tell preview from send, planning from assignment and editing from saving; retest blank report states in a normal supported environment.

The shared chrome around every page. All of it was read-only: no task, alert, time entry, saved report, export or integration was created or changed (global controls). The app header shows "Powered By ServiceTitan".

Admin > Billing is the company's own account with FieldRoutes: what the business pays FieldRoutes for the software. It is separate from customer invoices, collections and payment profiles (Invoicing and billing terms, Payments and collections). It has four tabs: Account Summary, Payment Method, SalesRoutes and Usage (admin controls, admin findings).

The rates are this account's displayed rates on 2026-11-02, not public prices or a quote. Invoice/payment drilldowns, card validation, fee changes, usage refresh, module activation and billed reconciliation were not tested. Related: Office Info > Authorized Contacts names the people allowed to make contract and financial decisions about this FieldRoutes account (next section). Fill Routes is documented as charging a per-route fee as soon as the button is entered (Routing).

Some FieldRoutes areas have no fitting CRM block. Today they sit in the nearest block or here. Proposal for the team to decide:

• Proposal: Users, permissions and security. Users directory, the eight User Card tabs, Access Control Profiles (shared-profile propagation, Custom Profile), office two-factor policy, login-location policy, session expiry, audit views and Authorized Contacts. Now placed in Technicians and licenses, with session expiry here.
• Proposal: Staff location tracking. Reporting Locations (employee marker/history, no vehicle telemetry shown), the User Card Location start/end points and the Fleet Pro launcher link. Now split between Reporting and analytics, Technicians and licenses and Routing.
• Proposal: Payroll and compensation. Time Clock categories, transition rules and weekly limits, the Time Clock Report with Excel/ADP export and overtime fields, commission profiles, rates and deductions. Now in Technicians and licenses and Lead, sales and estimate.
• Proposal: Company and office setup. Office Info (legal identity, authorized contacts, invoice address, route origin, territory, logo), Office Zip Codes and multi-office rules, office Preferences such as brand colors and month closing, Vendors, Social Network, and FieldRoutes' own account billing. Now on this hub.