When the Customer's Only Status Channel Is the Phone

Picture the dispatcher's afternoon. It's 2:30, and the queue of things waiting for a decision includes a reassignment, a parts delay, and eleven voicemails. Nine of the eleven are the same question in different words: where's my technician?

The system knows. The job record says the technician is on the way, and roughly when they'll arrive. The customer doesn't have access to that record, so the only way to find out is to ask a person.

That's the thesis of this article. The customer is calling because the record can't reach them.

Gap 5, and what it costs

The fifth of the six information gaps is that the customer's only status channel is the phone. A customer needs service and they call. They want a status update and they call. They want to pay an invoice and they call.

The visible cost is easy to compute: status calls per week, times minutes per call, times the loaded hourly cost of whoever answers. It's one of the six formulas in what disconnected field service systems actually cost.

The cost that doesn't appear in the formula is the dispatcher's attention. A call about a status check comes in the middle of deciding who covers a no-heat emergency. The interruption is small each time, and there are a lot of them.

What a portal has to read

What is a customer portal in field service management? It's a branded, self-service site where customers submit requests, follow jobs, review estimates and invoices, and see their service history without calling anyone. What matters most is what it's connected to.

The question to ask is whether the portal reads the same job record the dispatcher sees, or a copy of it. A copy is a second system with a lag, and a lagging portal produces the calls it was meant to prevent. A portal that reads the live record means the customer sees what the dispatcher sees.

A useful portal covers the whole service relationship:

• Service requests go straight into the work order queue, with no voicemail to transcribe and no detail lost.
• Real-time job tracking shows scheduled, on the way, on site and completed as it happens.
• Estimates and invoices can be reviewed and approved, and invoices can be viewed and paid, with service history visible by property or location.
• Branding is per customer account, so the customer sees your company and their own sites.

Behind the portal, automated ETA and on-the-way notifications go out when a technician's status changes, so the customer hears about the change before they'd think to ask.

Residential is one address. Commercial is forty.

Residential work is one address and one decision-maker. Commercial work is a property group with forty sites, three people who can authorize a repair, and a facilities director who expects you to know the building.

Software built around the single service call can't hold that shape, so the office holds it instead. Someone in the office knows that the north campus needs a different contact than the south, and that the loading dock on site twelve is the only door open after six. That knowledge lives in a person's head, which is fine until they're out.

How should field service software handle a customer with many locations? With a customer account that holds as many sites as it needs.

Many sites, one customer

Each site has its own address, contacts and history. A chain and a single location use the same structure. The customer is one record for billing and relationship, and the sites are as many records as service requires. A quote can be for one, the dispatch goes to the right site, and the invoice goes to the parent.

Full service history per site

What is a site record in field service? It's everything that has happened at one location: every prior work order, with its photos, notes and parts. It's on the technician's phone before they get out of the truck, so the person arriving knows what the last visit found, what was replaced, and what was recommended and declined.

Access notes that save the first twenty minutes

This is the detail people underestimate and technicians remember. A gate code. Where the key is kept. Which parking area is for service vehicles. That there's a dog on site, and that it's friendly except at the back door.

Access notes get worked out by whichever technician first ran into the problem, usually after twenty minutes of phone calls. The right way to keep them is to capture them once, on the site record, by the technician who worked it out, so they're available to whoever goes next. The second technician to visit doesn't spend the first twenty minutes calling the office to ask what the first one learned.

It sounds small and it isn't. Multiply twenty minutes by every first visit to every new site and it's a large amount of paid time that nobody logs as lost.

One portal per account, covering every site

For a commercial customer, the portal is scoped to the account and not the visit. The facilities director sees their sites, work orders, estimates and invoices in one place, under your brand, without calling anyone.

Property management is the clearest example. Tenants submit maintenance requests directly, with no phone call. Owners see reporting dashboards configured for their needs. Work orders are organized by property, unit and tenant, each with its full service history. The property manager gets fewer inbound calls, and the tenant gets a request that's tracked from submission to completion.

The same structure fits a retail chain, a hospital campus or a school district: one relationship, many locations, and a single place for the customer to look. (Property management is a subject of its own and we'll leave it as a worked example here.)

Three people who can authorize a repair

Commercial customers have a habit that residential software rarely handles: several people can say yes, and they don't all have the same authority. A site manager can approve a small repair. A regional facilities director approves anything larger. Accounts payable wants the invoice, and doesn't want to hear about the work.

A customer account that holds its own contacts for each site gives the office one place to record who is who. The map stops living in a spreadsheet or in someone's memory, and the technician standing in a lobby can see who to ask.

It also changes the first call. When a customer with forty locations phones about site nineteen, whoever picks up sees the site's history and its contacts before they say hello.

How to know it's working

You can measure a portal the way you'd measure any process change. Count status calls per week before and after. Watch the days between an estimate being sent and approved, since a customer who can approve from a link doesn't have to call back. And ask technicians how often they lose the first part of a visit to a locked gate or a missing contact. If the number of each falls, the record is reaching the people who need it.

Why this only works on one record

The portal works because of what's underneath. A request enters the queue as a work order. The customer tracks the same record the dispatcher sees. The invoice they pay came from the work the technician logged on site.

If any of those is a copy, the portal is a view of something that might be out of date, and the calls come back. On one record, there's no lag to explain.

MangoApps Field Service Suite is built that way, on the same data layer as the rest of the platform. The work order lifecycle article traces one job through all six steps, and recurring revenue that schedules itself shows how site-level agreements and inspections use the same site record.

A portal is read access to the record you already keep

A portal isn't a customer-experience feature. It's the customer's read access to the record you already keep. If the record is right, the calls stop. If it isn't, a portal will show the customer exactly how wrong it is.

That's the test to put to any vendor: change a status on the work order, then refresh the portal. It's question two in how to evaluate a field service platform.

The portal and site records are covered alongside the rest of the suite in the Field Service Management guide. You can also see the Field Service Suite itself.

Frequently asked questions

What can customers do in a field service portal?

They can submit service requests that land directly in the work order queue, track a job as it moves from scheduled to on the way to on site to completed, review and approve estimates, view invoices, make payments, and see their service history by property or location. The portal can be branded per customer account, so a commercial customer sees all of its sites in one place.

How does a portal reduce inbound calls?

Most inbound calls in a service business ask for status, a quote or an invoice. When customers can see the live job status, review estimates and view invoices themselves, and when automated ETA notifications tell them a technician is on the way, the reasons to call go away. The portal only works if it reads the same record the dispatcher sees.

How should software handle one customer with many service locations?

With a customer account that can hold as many sites as needed. Each site has its own address, contacts and service history, while billing and the relationship sit with the customer. A chain and a single location use the same structure, and a customer's portal can show all of its sites and their work in one place.

What are site access notes and why do they matter?

Site access notes are details a technician needs to get in and work: gate codes, key locations, parking, hazards or a dog on the property. They matter because without them each new technician spends the first twenty minutes working out what the last one already knew. Capturing them once on the site record makes them available to whoever goes next.

Can customers approve estimates and pay invoices online?

Customers can review and approve estimates and view invoices and make payments through the portal, with the approved estimate converting into a work order.