Utarbeidet med KI.
The six system statuses are too broad for most users. “In progress” does not distinguish between a technician being unable to proceed while waiting for parts and the work actually being carried out. Substatuses solve this—and are the right way to do it, since the system statuses should not be changed.
Review one month’s worth of work orders with the planner and a couple of technicians. Note which situations actually occur: waiting for parts, waiting for the customer, waiting for access to the building, requires two technicians. These are the ones that should become sub-statuses—not what someone thinks might be relevant.
Each sub-status is linked to one system status. “Waiting for parts” typically falls under In progress, while “cancelled by customer” falls under Cancelled. This link determines which automations are triggered, so choose it carefully.
Substatuses are created as separate entries in the Field Service settings. Give them names people will actually recognize—use the terms the technicians themselves use, not system jargon.
This is the whole point. Do not add, remove, or change the system status values for work orders. Invoice generation, conversion of products to customer assets, and travel fees depend on them. If you need different wording externally, an administrator can change the labels without altering the values.
Technicians and planners need to know that the system status controls the process, while the sub-status explains why. Without that explanation, the two are used interchangeably, and then you are no better off.
The value becomes apparent once you start counting. How many work orders are waiting for parts, and for how long? That figure is often the first concrete basis for taking action on inventory management or supplier agreements.
Still et spørsmål eller del hva som hjalp deg.
Har du et spørsmål eller en erfaring å dele?
Bli den første som bidrar.
