Setting Up Job Types
A job type is the label that says "this is the kind of work this is" — a Service Call, a New Install, an Estimate Visit, a Recall, a Warranty Claim. On the surface it looks like a simple dropdown. Underneath, it's the switchboard that drives which industry forms automatically attach to the job, which department or team it routes to, and how the job rolls up in revenue and operational reports.
Most accounts come with a starter list seeded for them. The starter list is rarely the right list for any specific business — it's a generic shape. Half an hour spent shaping job types to your actual business will save days of cleanup work and report wrangling later.
When you'd use this
- You're setting up a brand-new Suprata account and the seeded job types don't match your jargon.
- You added a new line of business (e.g., started doing chimney sweeping in addition to HVAC) and need a separate job type for it.
- You're trying to run reports by service line and discovering everything's lumped under one generic "Service" type.
- A new industry form (HVAC eval, marine boat info, IT in-store eval) was created and you want it to auto-attach when techs create the right kind of job.
Why job types matter more than they look
Three things hang off the job type.
1. Auto-attached industry forms. When a tech (or a dispatcher) creates a job and picks "HVAC Service Call" as the type, the system reads the form-attachment rules for that type and automatically binds the right industry forms to the job — for HVAC that might be a unit eval form and a refrigerant log; for IT it might be an equipment list and a customer data-handling consent. The tech doesn't have to remember to attach them. If the type is wrong, the wrong forms attach (or nothing does), and the tech ends up filling things out on paper. See Industry forms — what attaches when for the mechanics.
2. Reporting and segmentation. Every revenue and operational report can group by job type. "How profitable were our installs this quarter vs. service calls?" "What percentage of our work is warranty?" "How many recalls did we run last month?" — all of these are job-type questions. If everything's filed under one generic type, those questions can't be answered without rebuilding history.
3. Routing and defaults. Some accounts wire job types to default departments, default teams, or default tag bundles. If you have a "Day Crew" team that handles installs and a "Service Crew" that handles repairs, configuring those defaults on the job type means dispatch doesn't have to remember each time.
The mental model — name them by the work, not the outcome
The single most common mistake is naming job types by the outcome ("Closed", "Quoted", "Approved") instead of by the kind of work being done. Outcomes are statuses; types describe the nature of the work.
A clean type list looks like:
- Service Call
- Maintenance Visit
- New Install
- Estimate / Site Visit
- Recall (return visit on previously closed work)
- Warranty Claim
A messy one looks like:
- Service
- Repair (no different from Service in most shops)
- Quote
- Approved Quote (same job, different status)
- Re-Service
- Recall
- Callback (same as Recall)
- Misc
If you find yourself with two types whose only difference is "what stage it's at", merge them and use job statuses for the stage. Statuses describe where in the process; types describe what kind of process.
Naming conventions that age well
A few conventions that pay off as you scale:
- Lead with the line of business if you have more than one: "HVAC — Service Call", "Plumbing — Service Call", "IT — In-Store Evaluation". Keeps types grouped alphabetically in dropdowns and makes reports self-explanatory.
- Keep names short — they show up in the dispatch board chips, the calendar, and the new-job dropdown. Anything over ~25 characters gets clipped.
- Don't put dates or campaign codes in the name — those are tag territory.
- Use Title Case consistently. "service call" and "Service Call" sort separately and look unprofessional next to each other.
Setting up — the typical workflow
Configuration lives in the Job Settings area (the sidebar group that holds all the job-related lookups: types, statuses, tags). Open the Job Types screen and you'll see a list of the existing types with options to add, edit, or deactivate.
For each type, decide:
- The display name — what techs and dispatchers will see in the dropdown. Use your jargon, not Suprata's. If your shop calls them "calls" rather than "service calls", call them calls.
- The default business unit (if you run more than one) — which sub-brand this type belongs under by default.
- The default department or team (if your account uses these) — who normally handles this kind of work.
- Auto-attached forms — which industry forms automatically attach to a job of this type. Configured separately on the form-attachment screen but conceptually part of the type's setup.
- Active vs. retired — when you reorganize, don't delete old types. Mark them inactive so historical jobs still display correctly but the type stops appearing in the new-job dropdown.

What changes after a job is created
Once a job exists with a particular type, you can usually change the type — but the auto-attached forms don't auto-detach. The system attaches forms appropriate to the new type on top of the ones it already attached. If a tech changes "HVAC Service Call" to "Plumbing Service Call" mid-job, the HVAC eval form is still bound to the job; the plumbing forms get added too. Clean this up by removing the now-irrelevant forms manually.
For this reason: if a job was created with the wrong type, fix it in the first few minutes, before the tech has filled anything in on a now-stranded form.
Common mistakes
- Too many types. "HVAC Service Call — Residential", "HVAC Service Call — Commercial", "HVAC Service Call — Multi-Family" is three types where one type plus an account-side commercial flag would do. If you can derive the distinction from the customer or the location, do that, not a separate type.
- One generic "Service" type that covers everything. Then every report breaks. The minimum useful split for a service business is visit (someone going out to do work) vs. estimate (someone going out to quote work) vs. install (someone going out to install something) vs. recall (someone going back because the first visit didn't fix it). That's four types, not one.
- Naming a type after a customer or job. "ABC Property Management Service" should be a tag or a customer field, not a job type. Types describe the work, not the customer.
- Deleting an old type instead of deactivating it. Historical jobs lose their typing and old reports go sideways. Always retire (deactivate), never delete.
- Forgetting to map forms to a brand-new type. A type with no form mappings is fine for billing-only work — but if your business depends on industry forms (HVAC, marine, IT), every "real" job type needs a form mapping or techs will be filling things out on paper and pasting them in later.
- Building reports against the type name instead of the type record. If you ever rename the type, name-based filters break silently. Filter by the type itself, not the string.
Recommended starting list for common businesses
A residential service business (HVAC, plumbing, electrical, appliance):
- Service Call
- Maintenance Visit
- Estimate / Quote
- New Install
- Recall
- Warranty Claim
An IT services or computer-repair shop:
- In-Store Evaluation
- On-Site Service
- New Build / Install
- Pickup / Delivery
- Recall
A marina or boat-service operator:
- Boat Evaluation
- On-Water Service
- Haul-Out Service
- Diving Service
- Estimate
You can always add more later. Start with five to seven, watch which ones actually get used for a month, and iterate.
Related articles
- Creating your first job
- Job statuses and what each one means
- Industry forms — what attaches when
- The print work order
- Setting up departments and teams (forthcoming)