How do you build a trade and priority coding table?

One location reports "AC." Another reports "warm room." A third chooses general repair because it is the first option on the list. All three requests may describe the same problem, but they enter the system under different names.

That makes the first decision harder and weakens every report that follows. The coding table should give location teams a short, understandable way to describe the request while giving facilities enough consistency to route and measure the work.

What should a trade code decide?

A trade code should answer one practical question: who is most likely to receive the work first?

It should not ask the location team to diagnose the failed part. A warm room could come from a thermostat, a control issue, a failed unit, a power problem, or something else entirely. The person submitting the request should report what is happening, and the facilities team can confirm the final trade during review.

Keep the initial code broad enough to choose the right type of service provider. Record the confirmed cause and failed part during closeout, after someone has inspected the problem.

Which trades make a useful starting list?

Ten categories cover a large share of day-to-day facility requests without forcing the requester through a long menu.

Swipe to see the whole table

The final category may need to be separated as volume grows because those systems often require different licenses, inspections, or service relationships. It works as a starting point when each subcategory still routes through the same review team.

Add a narrower code only when it changes a real decision. "Plumbing, drain" may be useful if drain calls go to a different provider. Creating separate codes for every type of sink will not improve dispatch.

How many priorities should you use?

Three priorities are enough for many multi-location programs. The definitions should rely on conditions the location can report, not on how frustrated someone feels.

Swipe to see the whole table

The priority table defines the condition. Response targets should be managed separately because arrival time may change by trade, market, and time of day.

When a real emergency requires the fire department, police, 911, or the utility, the location should make that call first. A work order does not replace public emergency services.

What should the location report?

Ask for facts the person can observe:

• Location and exact area
• Asset, if known
• What they can see, hear, smell, or feel
• When the issue started and whether it is changing
• What part of the operation is affected
• Whether anyone could be harmed
• Whether damage is spreading
• Any safe temporary step already taken
• Photos or video when safe
• A contact at the location

The person reviewing the request can use that information to set or confirm the trade and priority. That decision belongs with someone who works with the coding table regularly, not a manager trying to run the location during a busy shift.

How should mixed work be coded?

Start with the trade that can stop the source of the problem.

A wet ceiling may require two jobs. The roof or plumbing leak comes first. Ceiling tile, drywall, paint, or flooring follows after the source is controlled.

Use one primary trade on each work order and link the follow-up work. This keeps the cost and timing of the original failure separate from the restoration work. Combining everything under general repair makes it difficult to see what the leak actually cost.

When the source is not clear, use the best routing category available and allow facilities to change it after review. Record the original and final trade so repeated routing problems can be found later.

When should a new code be added?

Add a code when it changes who receives the work, which requirements apply, or how the work should be measured.

Review the "Other" category every month. If the same type of request appears repeatedly and follows the same route, it may deserve its own code.

A new code may also be useful when it changes:

• Required license or certification
• Primary service partner
• Response target
• Approval process
• Rate structure
• Closeout requirements
• Warranty or compliance tracking

One unusual request is not enough. The list must stay short enough that different people can look at the same issue and choose the same category.

How should the table be tested?

Test it with real work orders before building it into the platform.

Take a sample from the previous month and ask two people to code each request independently. Compare their answers. If the same jobs regularly land in different categories, the wording may be unclear or the list may contain too much overlap.

Pay attention to:

• Heavy use of "Other" or "General repair"
• Trade changes after dispatch
• Several codes that send work to the same provider
• Codes that are almost never used
• Requests that require the location to guess a failed part
• Mixed scopes placed on one work order
• Similar problems described differently across locations

Fix unclear labels and examples before adding more rules. A shorter list with clear boundaries is easier to use than a detailed list nobody applies consistently.

Who can change the code or priority?

The reviewer should be able to correct the trade or priority when new information arrives. Keep the change visible by recording who made it, when it changed, and why.

Review those changes over time. If refrigeration requests regularly arrive as HVAC, the menu or examples may need work. If routine requests are repeatedly upgraded after waiting, the problem may be the routine queue rather than the original priority.

Coding changes are useful data. They show where the request form and the operating process do not match.

What should closeout add?

The request begins with symptoms. Closeout should add what was actually found.

Record:

• Confirmed asset
• Failed part, when known
• Cause of the problem
• Work completed
• Parts and materials used
• Completion photos
• Remaining or follow-up work
• Warranty on the repair
• Whether the visit was a callback
• Final trade and priority

That information turns a collection of work orders into an asset history the facilities team can use. It supports provider reviews, preventive maintenance, budgeting, warranty checks, and repair-or-replace decisions.

Pebble keeps the original request, coding changes, dispatch, closeout details, and asset history on the same record. This makes the table useful for both daily routing and long-term reporting.

ReferenceUniversity of Kansas Facilities Services, Service Levels