Part 1 — Understand BigWave · Chapter 1

What BigWave Is

BigWave is field service management software. Underneath every screen sits one small data model, and once you have it the product stops feeling like two hundred features and starts feeling like five ideas arranged sensibly.

The four core records

Customer. Who you do the work for. A business (Harbor Grill Restaurants) or an individual (the Okafor family). The customer record holds the account-level facts: names, contacts, billing addresses, payment history.

Site. Where the work happens. Every customer has one or more sites, each a physical location with its own address, contacts, documents and service history. Harbor Grill is one customer with twelve sites. The Okafors are one customer with one site, until they buy the lake house, at which point they’re one customer with two sites. A second property is a second site, never a second customer.

Work order. A unit of work. One job, at one site, tracked from creation to completion to payment. The work order carries the description, status, schedule, assigned technicians, time and materials, photos, documents, comments and invoice lines. Almost everything your team does all day happens on a work order.

Project. The container work orders live in, and the piece people most often misunderstand, so it gets its own section below.

What a project really is

A project is a line of work in your business. Not a customer folder, not a date range, not a job.

Every setting that shapes how work gets done lives at the project level: the status flow, the custom fields, the work order templates, the rates, the alert rules, the document templates. So “should this be its own project?” is really “does this kind of work run differently?”

If you do inspections, that’s a project. If you do general service, that’s a project. If a national chain hires you for a 300-store rollout, the rollout is its own project, because it has its own statuses, its own paperwork and its own team.

Beacon Electric runs three:

  • Residential Service. All homeowners share it. A panel repair for the Okafors and a ceiling fan install for another family follow the same simple flow, so they belong to the same line of work.
  • Commercial Service. Ad-hoc commercial calls, all commercial customers together.
  • Harbor Grill Annual Inspections. Dedicated to one customer, because the inspection contract has its own close-out paperwork, its own statuses (Inspection Scheduled, Report Submitted) and contract rates that apply to nobody else.

A project can be per-customer, and the inspection contract is. It earns that by being a different line of work, not by belonging to a big customer. When a customer’s work runs exactly like everyone else’s, put them in the shared project and keep your setup small.

Commercial (Harbor Grill): one dedicated project for the inspection contract, while their emergency service calls go through the shared Commercial Service project. Same customer, two lines of work, two projects.

Residential (the Okafors): no project of their own. Their work orders live in Residential Service alongside every other homeowner.

The supporting cast

Partners. Other companies you exchange work with. Subcontractors you dispatch, or general contractors who send work to you. Partners get their own record, their own technicians, and optionally their own portal logins. Chapter 21.

Technicians. The people who do the work, employees or partner techs. Each has a record with contact info, assignments, work history, documents and time off. Chapter 6.

Assets. Equipment you service, registered at customer sites. The electrical panels and emergency lighting at each Harbor Grill location, a generator, an HVAC unit. Assets carry their own service history, and Asset Scheduling generates recurring maintenance work orders for them on its own. That’s what turns a maintenance contract into recurring revenue without anyone remembering to create the jobs. Chapter 20.

Workflows. Checklist-style processes that ride on a record: a work order, a project, an asset or a technician. A workflow type defines the steps once, and each workflow instance routes itself between people, departments or the project team until it’s done. New hire onboarding on a technician, permit application on a work order. Chapter 7 introduces them alongside statuses.

How a job flows through the system

The Okafor panel job, end to end:

  1. The Okafors exist as a customer with one site.
  2. Priya creates a work order in the Residential Service project.
  3. She puts it on the calendar and assigns Tom.
  4. Tom sees it in My Assignments, does the work, adds photos and a comment, records his time.
  5. The status moves forward at each step, so anyone can see where the job stands without calling anyone.
  6. Grace turns the work order’s line items into an invoice and emails it.
  7. Payment lands, the work order closes, and the whole trail stays queryable. Who, when, what, for how much.

Why the model is shaped this way

Separating customer from site means a chain of restaurants is one account with one payment history, while service history stays per-location. That’s the only arrangement where either number is worth reading.

Separating project from customer means your operational rules follow the kind of work rather than the buyer. Add your fiftieth residential customer and there’s nothing to configure. They drop into a line of work that already runs.

Keeping everything on the work order means there’s one place to look for any job, whether you’re the dispatcher, the tech on site, the bookkeeper, or the customer checking status in the portal.

Next: chapter 2 shows you around the screens where all of this lives.