Part 2 — Set Up Your Company · Chapter 7

Statuses & Workflow Design

Status is the load-bearing wall of BigWave. Every work order sits in exactly one status, and that one word drives what shows on whose screen, which alerts fire, when billing happens and what the customer sees in the portal. Companies that thrive with BigWave designed their status flow on a whiteboard first. Companies that struggle let statuses accumulate like barnacles.

How statuses work mechanically

Statuses belong to projects. Each project carries its own list, edited under Project Setup/Statuses / Tags, and two projects match statuses by name, not by a hidden global ID. That’s deliberate. Your inspection project can have Report Submitted while residential service has Awaiting Parts, and neither pollutes the other.

So new projects don’t start from a blank page, Setup/Status Defaults holds the company-wide starter set. Every new project begins with a copy of the defaults, then edits freely. Get the defaults right early. They’re the culture your future projects inherit.

Each status has a name, a description, an order, and settings that control its behavior, including visibility to portal users and its part in billing.

Design before you build

Rules that hold up:

Model the pauses, not just the steps. The states where work waits are where money leaks. Awaiting Parts. Awaiting Customer Approval. If a job can sit somewhere for a week, that somewhere deserves a status, because a status is the only thing anyone can filter, count, or set an overdue timer on.

One status, one owner. For every status, someone should be able to say who’s responsible for moving jobs out of it. In Progress is the tech’s. Ready to Invoice is Grace’s. A status with no owner is where work orders go to die.

Fewer is better until proven otherwise. Six to ten statuses run most service flows. If two statuses always change together, or nobody can explain the difference, merge them. Use tags (chapter 10) for attributes that aren’t steps. Warranty is a tag, not a status.

Name for the reader, not the writer. Waiting on customer signature beats Pending 2.

Beacon’s two flows

Residential (the Okafors): the Residential Service project runs New, Quoted, Approved, Scheduled, In Progress, Complete, Invoiced, Paid. Eight statuses, each with an owner, none of them visible outside Beacon, since homeowners get emails rather than portals.

Commercial (Harbor Grill): the inspection project runs Inspection Due, Scheduled, In Progress, Report Submitted, PO Received, Invoiced, Paid. Report Submitted and PO Received exist because Harbor Grill won’t pay without the signed report and their purchase order number, and Beacon needs to see at a glance which of twelve sites is stuck at which gate.

What status drives

A status change can:

  • Fire alerts (chapter 13), notifying people on any status change or on one specific status being reached. Timers can also fire when a work order stays in a status too long, which turns your one-status-one-owner rule into an enforced one.
  • Gate billing (chapter 19). Invoicing keys off status, so “work complete but not invoiced” is a filterable list instead of a monthly archaeology dig.
  • Drive the portal. Statuses control what progress a customer login sees.
  • Power the pipeline view. Each project’s Site Tracking screen counts work orders per status, which answers “where are we on the rollout” at a glance. Chapter 22.
  • Respond to emails. An emailed quote can carry an Approve button that moves the work order to your approved status when the customer clicks it, chapters 13 and 18. The button targets a status by name, one more reason names deserve care.

Workflows: processes that ride on records

Statuses track the job. Workflows track processes around the job that have their own steps and their own responsible parties. A permit application on a work order. Onboarding on a new technician. A monthly safety review on an asset.

You define a workflow type once, globally under Setup or inside a project, and it acts as a template: the steps, the statuses the workflow itself moves through, its custom fields, and how it routes. Each running workflow attaches to its record and moves between queues:

  • the originator, whoever started it,
  • a department, where anyone in that department can pick it up,
  • or the project team.

Workflow types exist for four kinds of record: work orders, projects, assets and technicians. Everyone sees the workflows sitting in their court in the home page Workflows group, and stale items surface under Attention Required. Where a status answers “where is this job”, a workflow answers “who’s holding this process, and what’s the next step”.

Start with statuses alone. Add your first workflow type when you catch a real process being tracked in someone’s inbox instead of in BigWave.

Checklist

  1. Whiteboard each line of work as boxes with owners before touching the software.
  2. Enter the common denominator into Status Defaults.
  3. Let each project adjust its own copy. Chapter 9 creates the projects.
  4. Wire the automation. One overdue timer on your stickiest status is a good first alert, chapter 13.
  5. Revisit quarterly. Delete statuses with a standing population of zero, and go look at the ones where jobs pile up.