A native app or a panel on the phone. The crew loses the job in the basement, not in the store
Author:
Paweł Matusiak
·
The office panel runs in a browser, the technician carries a phone, and the owner is told “you need an app now”. A store listing is a separate channel for installation and patches, not the next stage of the panel. It makes sense when the crew closes a job with no signal, or needs phone hardware the browser will not give reliably. Otherwise a page that fits the phone runs the same flow more cheaply.
The office panel opens in a browser. The technician carries a phone. The owner is told it is time to build an app, because customers carry smartphones and the competitor shows an icon in the store.
That conversation usually skips the working day. The address changes at noon. The motor nameplate is in a dark underground car park. The site manager will come down for five minutes to sign. The signal dies on the ramp. The job that was meant to return to the office in the evening comes back in pieces: a photo in the gallery, a slip in the glove box, a message in a chat thread.
A native mobile app is not the next stage in the life of a company panel. It is a separate channel for installation, store review and patches. It is justified when the crew must close a visit offline, when the browser will not give a reliable camera, location or scanner, or when a store channel is imposed. In other cases a responsive web application — a page that fits the phone and can be pinned to the home screen — runs the same flow more cheaply.
An icon is a maintenance cost. The firm pays extra for the store when the job card dies with the signal and when someone in the office will maintain a second programme.
What the crew does with a phone before anyone mentions the store
In field service the phone is not there for browsing a brochure. It is there so the technician knows where to go, what to take from the van and what to tick off at the site.
In the morning a list of addresses lands in a messenger. At noon an emergency job arrives and the order falls apart. In the evening the gallery holds photos of nameplates, the glove box holds a slip with a part number, a note holds the travel times. In the morning the office builds an invoice and a report that a chain customer wants on its own form.
The jam is simple. The job lives in three places at once: the office panel, a thread on the phone and the supervisor’s head. When the address changes, some people still have the old one. When the nameplate photo stays in a private gallery, stores orders the wrong part. When the signature is on a slip of paper, the invoice waits until someone finds the slip.
What helps here is a shared job card opened on the phone: address, status, a photo attached to the visit, not to a chat. The messenger stays for emergencies and for the call, not for the address list. At this stage a page that works well in the browser is often enough. A field-service application describes that flow from the call to the visit report. A store icon adds nothing yet.
The supervisor will still ring when a door blocks the entrance to a hall. A panel on the phone does not replace that call. It replaces the guessing about which version of the address is true and which photo belongs to which site.
Example: a door service and a report from an underground car park
Imagine a service firm for doors, shutters and drives, with a dozen or so crews. The office has a panel: service contracts on estates and halls, a price list for inspections, invoices. The crews get the day in a messenger. The supervisor pastes in an address, a time, sometimes a drive number.
A typical situation looks like this. The technician drives down into an underground car park. The signal dies on the ramp. An inspection report has to be filled in: drive type, a photo of the nameplate, the state of the tracks, the site manager’s signature. The page in the browser spins and will not load. Notes go onto a slip, photos into the gallery; back on the street the files go into the thread. In the evening someone in the office guesses which photo belongs to which door, because one block has three entrances.
The result is dull and expensive. The warehouse orders the wrong actuator. The crew goes out a second time. The site manager says no signature was given. The invoice for the inspection sits there, and the contract with the housing association runs on anyway.
Two things help in this story. First, a job card in which the photo and the signature sit with the visit. Second, an offline queue: the report saved on the phone and sent when the network returns. Whether that queue lives in the browser or in a store app depends on how often the car park cuts the signal — not on whether the competitor has an icon.
The same firm also has a season. In autumn, associations want inspections before winter; in summer, drive failures pile up on halls. The messenger swells, and the office assembles reports late. The more crews go out at once, the more expensive it is to lack one card and one queue, regardless of where the icon on the screen came from.
Offline, camera and signature. Where a page on the phone falls over
A phone browser copes well with a job list, a status and an ordinary form, provided there is a network. The threshold sits elsewhere. In a car park, in a hall with sheet-metal walls, in a plant room, on a site with no signal, the card has to be fillable and must not vanish.
Offline access means something concrete. The technician opens the job on the street, drives down, fills in the report, takes a photo, collects a signature and comes back up. Only then does the phone send the bundle to the office. If the page needs a live connection for every field, the report goes back onto a slip of paper. The panel on the phone is then an ornament, and the work runs beside it.
The camera has to put the nameplate on the card, with a date, and not leave it in the gallery. A phone browser will take a picture. It can be fussy in poor light, with a series of shots, when returning to the form after taking the photo. A store app usually holds that sequence more firmly, because it uses the camera as a tool, not as an add-on to a page.
A signature on the screen closes the visit. A slip in the glove box does not. A part barcode scanner and a label printer are already hardware that a browser page often will not sustain. Bluetooth, background location, work in the background. A page does not promise those things reliably.
In the door-service example an underground car park cuts the network, the drive nameplate needs a photo, and the site manager’s signature closes the inspection. An industrial scanner and a van printer are not on every crew. What remains to settle is the offline queue and the photo on the card: whether they can be held in a page pinned to the screen, or whether a thin field app is needed that talks to the same panel.
Who puts the programme on the phone and who updates it
A store app has distribution that a web page does not. Someone has to find it, install it, log in, allow notifications, then load a patch. In a service firm with a dozen or so crews that list is not a trifle.
Some people drive on a private phone. Others have a company handset that lives in the glove box and runs an old system. The supervisor sends a store link. A week later two technicians still close the day in the messenger, because “some app would not open”. The office then has two flows: the one from the card and the one from the thread. That is worse than the messenger alone, because nobody knows which is in force.
Updates are a separate cost. A status change in the web panel arrives after a deploy to the server. The same change in a store app waits for review, for the phone to download the package, and for the technician to open it at all. At the peak of autumn inspections the office does not want to wait for the store to release a fix to a field on the report. It wants the crew to see the same status in the morning as the dispatcher.
A page pinned to the home screen skips the review. It has another fault: someone has to create that shortcut, remember the password, and not clear the browser data. The session logs out at the worst moment. The link vanishes when the technician changes phones. Those are real frictions. They are still the frictions of one programme, not of two stores and two reviews.
If the firm already issues company phones and someone in the office keeps the list, the store stops being a scare. A company handset with one installed app is then a channel that can be maintained. If everyone drives on their own mobile, the first job is to say who owns installation. Without that person the native app is back in the messenger within a season.
Two programmes, one status and a muddled customer channel
The cost of a store app rarely ends with the first screen. The office still needs a panel: contracts, invoices, the rota, stores. The crew needs a card on the phone. That is already two ends of the same flow. When each has its own code, every change to a status, a field on the report or the inspection price list goes through twice.
Maintenance of two programmes shows up on a banal change. A housing association wants a different signature layout on the report. In the web panel that is a screen fix. In the store app it is also a review and the phones that have not fetched the version. For a fortnight some crews send the old form, some the new. The office collates documents by hand. The cost of an application swells not from the idea of an icon, but from how many such changes the firm will make in a year.
A separate mistake is mixing the crew’s tool with the customer channel. The owner wants one app: the site manager books an inspection, the technician closes it, the office issues the invoice. Those are two products. Booking an inspection is a short page or an account on a portal. A job card with an offline queue is a working tool. A store listing that holds both swells with roles, permissions and screens nobody uses.
In the example firm the site manager of an association does not need a store app to report that a door will not close at night. A phone call or a short form is enough. The technician needs a card that survives the car park. A chain of halls may want its own portal, not an icon. When those three things are forced into one product “because we need an app”, the firm pays for a store that none of them opens in the way that was assumed.
Hence a simple measure. How many people in the firm will maintain a second codebase and two stores on every change to the report. If nobody — the store is an ornament. If there is a team and there is an offline threshold the web will not pass, the second programme has an owner. Without an owner, what remains is a messenger thread, only with an extra login.
A lost link, a logged-out session, a notification that never arrives
Some of the resistance to a page on the phone does not come from the car park. It comes from how a browser behaves in a pocket.
The technician gets a link, opens the card, closes the browser, comes back two hours later and is logged out. Or there are three tabs with three jobs and it is unclear which is live. Or the iPhone treats the page as another bookmark, not as a tool. A home-screen icon added by the technician vanishes after a change of phone. At the peak of the season that friction goes back to the messenger, because the thread just works.
A notification of a new job or a change of order has to arrive when the technician is in the van, not when the page is refreshed in the office. A browser page is often weaker here, especially on phones that save power and put tabs to sleep. A store app has this channel in order, provided someone actually allowed notifications and has not muted them.
It can be eased without a store. A longer session. A home-screen shortcut made on a company phone, not “when someone has a moment”. One open job card instead of a row of tabs. A day list that still works after a pull-to-refresh, even when the network drops for a while. That is still one programme. Some of the friction goes when the phone is a company handset and someone in the office sets the shortcut once, rather than from scratch with every new hire.
A remainder is left: tabs put to sleep, unreliable notifications, a different browser on every phone. If the dispatcher really reshuffles crews during the day and that change has to reach the phone in minutes, the push channel stops being an ornament. The case for a field app is then organisational, not a matter of marketing.
Counter-argument: a native app is simply more convenient
The technician looks for an icon, not a web address. A native app is faster, more reliable in a car park, better with the camera and location. An owner who sees the competitor’s icon is told that without a store listing the firm looks late. That argument carries weight when the job card really does fail in the browser.
In some service firms that is exactly how the day runs. The crew spends it in halls and car parks. A report without a photo and a signature is worthless. The dispatcher reshuffles the order every hour. The phones are company issue, someone loads them, someone collects them when a person leaves. A browser page then becomes a workaround: slip, gallery, thread. Without the store the job card does not return to the office in one piece.
A full store app on two operating systems is still rarely the cheapest path. The office works in a browser panel. The customer reports a fault by phone or a short form. A thin field app — card, photo, signature, queue, notification — talks to the same panel. The rest stays in the browser. Two stores, two full programmes and a customer portal in one order are three products under one invoice.
The limits of a page pinned to the screen show up fastest on an iPhone: tighter access to notifications and storage, a fussy shortcut after a system update, offline storage less obvious than in a store app. If most of the crew drive iPhones and a queue in the car park is an everyday event, a home-screen shortcut stops being enough. What remains is a thin app, or an agreement that in the car park a slip of paper applies, with a send-up after coming back to the street.
A default page on the phone will not replace a barcode scanner on parts, a printer in the van, all-day background location, or a review that a retail chain demands of a supplier. It will also not fix a firm in which nobody owns the phones. A store app will then sit beside the messenger. Before the office chooses a store, it has to say who installs, who updates and which card is true.
The pressure is sometimes about prestige. The owner wants an icon because the competitor has one. The crew still closes the day in a thread. An icon without an offline queue and without a shared card will change nothing in the car park. The firm then maintains a third place in which a job can vanish.
A spreadsheet, a page on the phone, a home-screen shortcut or a thin field app
Three crews and inspections typed up in the evening by one person — a spreadsheet and a messenger will do, provided nobody runs a second list on the phone. A simple report and a signal on site are handled by a browser page. A ready-made programme for field service is often cheaper than one’s own code when the visit, the part and the invoice are standard. A ready-made programme stops adding up when a chain of halls wants its own report layout and an association wants a different inspection cycle.
A panel of one’s own is justified when the flow is unusual. A door inspection, a drive failure and a lump sum per site in the same day. A part in the van and a part at the warehouse. A site manager’s signature that is not on site, and a second visit just for the initials. Then first one job card in the browser, and only then the decision whether the offline queue needs a store app.
The order that usually hurts less:
- A shared job card in a panel that works well on a phone: address, status, photo, signature.
- A shortcut on a company phone and a session that does not log out in the car park.
- An offline queue in the same page, if it can be held on the crew’s phones.
- A thin field app from the store only when the queue, the camera or the notification fail regularly.
- A separate, short channel for the site manager or a chain customer — not the same store listing as the crew’s tool.
In such work GESOFT first maps the flow: who closes the visit, what must survive a loss of network, where the nameplate photo comes from, how the invoice waits for a signature. Only then is it clear whether a panel in the browser will do, or whether the crew needs a separate card on the phone. Sometimes the result is modest: one card, a home-screen shortcut, a link to the accounts programme. Sometimes the offline queue will not hold in a page, and a thin field app is added that talks to the same panel.
That conversation is cheaper than ordering “an app for the store” before anyone writes down what happens on the car-park ramp. A native app is worth the cost when the job card dies without a network or without a reliable camera, and when someone in the firm will maintain distribution. The service firm in the example needs a report that comes back from the car park in one piece.
Frequently asked questions
- Does a page pinned to the home screen replace a store app?
- Often for a job list, a status and an ordinary form, provided there is a network and someone sets the shortcut on the phone. It weakens when the crew regularly fills in a report with no signal, when the camera and signature fail in the browser, or when most people drive iPhones and an offline queue is an everyday event. A thin field app is then more reasonable than a second full programme.
- Does every field-service firm need a native app?
- No. A few crews, a simple report and a signal on site — a panel that works on the phone, or a ready-made programme, will do. A store app is justified when a car park, a hall or a site cuts the network, and the photo and signature must return to the same card, and when someone in the firm will maintain installation and updates.
- Can the customer and the crew use the same app?
- Usually those are two products. A site manager needs a report or a short form. A technician needs a card that survives a loss of network. A store listing that holds both swells with roles and screens. It is cheaper to give the customer a page or a portal, and the crew a working tool that talks to the same panel.
Related service:
Custom software for companies
Describe your project