Service-call intake: the 7 fields dispatch needs every time

Jude Rosario, Co-Founder & CEO at Auralis AI

Jude Rosario

October 21, 2026 · 5 min read

Hands taking a tool from an open toolset
On this page
  1. The seven fields
  2. Why intake is where the first-time fix starts
  3. Sources

e-automate lets you create a service call with Unknown Equipment/Items, and when you do, it adds a row to the Equipment/Item grid labeled UNKNOWN EQUIPMENT/ITEM. You can replace that row with the real equipment later, by editing or clearing the call, or e-automate can create the equipment/item record for you when the call is invoiced. It is a real escape hatch for a call taker who hasn’t identified the machine yet.

In our view, standardizing what actually goes on the service call intake form, before the call leaves intake, is the fix worth making first, well before anything about the software itself.

e-automate’s Creating Service Calls page documents fields such as customer, location, equipment, contract, problem description, caller, call type, priority, technician, an estimated duration, a PO number, a bill code, and a job, plus a handful of display-only fields (the same window even has a button for Canon SnapShot, unrelated to intake, one more thing crammed onto the screen). In our reading, a good share of that supports billing and scheduling once the call is moving. Only part of it is what a dispatcher needs before anyone picks up the phone and sends a technician out.

Here’s the set we’d fill in every time, and the reason for each one.

The seven fields

  1. Customer. The lookup that pulls the customer whose equipment needs service. The service call also has a display-only field showing that customer’s payment terms, one more reason getting the customer right at the start matters.
  2. Location. e-automate provides separate Customer and Location fields. Its Customer lookup can also filter for “Location Customers” or “Master Customers.” Once a known piece of equipment is selected, its equipment details display the associated street, city, state, zip and country, giving dispatch the address tied to that equipment.
  3. Equipment/item number. Selecting a known equipment/item here is what avoids the UNKNOWN EQUIPMENT/ITEM placeholder. It’s also what populates the equipment information region below it: contact, phone, office hours, location remarks, and the primary equipment note, if present, none of which the system shows until this field is filled in.
  4. Problem description. The help page is specific about this one: a description of the problem “according to the caller,” not a category assigned after the fact. In our view, that specific wording is worth protecting, because a call type alone won’t tell a technician what a customer actually said.
  5. Caller. e-automate provides two separate fields here. Caller contact is pulled from a stored list, filtered to the people already on file for that customer or location. Caller is a plain text field for the name of whoever is actually on the phone, and if it’s a known piece of equipment, e-automate will try to fill it from that equipment’s contact automatically. Together, the two fields give dispatch somewhere to record who actually called, on file or not.
  6. Call type. The category that best matches the nature of the problem, based on how the caller described it. e-automate uses it to populate the estimated duration of the call, and it can also drive the priority, which is otherwise calculated from the equipment’s own weighting. Get the category wrong and the duration estimate follows it.
  7. Priority. Populated from the call type or calculated from a weighted average using the equipment’s weight or priority, and a dispatcher can still change it by hand. This is the field meant to indicate which of several calls should be handled first.

Call these seven our recommendation, not a rule e-automate enforces or a standard ECI publishes. We’d rather see all seven filled before the call leaves intake, even if it means the caller stays on the line a little longer.

Why intake is where the first-time fix starts

PTC, a field service software vendor, cites Aberdeen Group research splitting service organizations into three tiers by first-time fix rate: the top tier resolves the issue on the first visit 88% of the time, the average tier 80%, and the weakest tier 63%. The same piece connects that directly to dispatch: equip dispatchers with the information they need, in real time, to send a technician with the right skills and parts, which is how PTC frames improving the odds of a first-time fix.

In our operational read, every one of the seven fields above is dispatch information in that sense. A blank equipment field can make parts selection harder. A call type standing in for a real problem description can leave tool needs unclear. A wrong location can turn into a wasted trip before the technician even opens the van.

Pull a week of calls, check them against these seven fields, and see which ones keep coming back blank.

For the intake itself, How do we connect to your E-Automate? shows how Auralis captures the machine, location, problem code and contract and creates the service call for your dispatcher.

Sources

  • ECI, e-automate online help (version 250), Creating Service Calls.
  • Sumair Dutta, What is First-Time Fix Rate?, PTC blog, Mar 15, 2024. First-time fix rate figures are Aberdeen Group research as cited there.
  • Auralis conversations with dealers (internal).

Share this

For e-automate dealers

See Auralis on your own service desk

A 30-minute walkthrough on your workflow — meter reads, dispatch, supplies and escalation.

Book a demo
Jude Rosario, Co-Founder & CEO at Auralis AI

Jude Rosario

Co-Founder & CEO

Jude founded Auralis after years as a software solutions architect at Toptal, where he saw that most support problems were really systems problems: fragmented tools, buried knowledge, and processes that broke the moment volume spiked. As CEO he sets the vision for agentic AI customer support — from the first chatbot to today's Auralis platform — and still evaluates every product decision like an architect: if it doesn't scale, it doesn't ship. He leads Auralis with a simple conviction: great support is a customer walking away feeling taken care of, and AI should be judged on resolutions, not deflections. He writes regularly on where agentic AI and the support industry are headed.

We use cookies to run this site and, with your consent, to analyze usage and improve our marketing. You can accept all, reject non-essential, or choose. See our Cookie Policy.