What field employees actually need on their phones

Start with five questions—not fifty features

Before choosing buttons and screens, ask whether an employee can answer these questions without searching through old messages:

1. Where do I go next? Show the assigned visit, address, and agreed service window. Make a changed assignment easy to notice.
2. What exactly are we doing? Include the current scope, what is excluded, and any approved changes.
3. What do I need to know before starting? Surface relevant access instructions, equipment needs, and job-specific precautions.
4. What should I record? Explain which checklist items, notes, time entries, or photos the work requires.
5. Who handles a problem? Provide a clear contact and a way to flag work that cannot continue as planned.

MU Extension’s Developing Effective Communications emphasizes choosing language and organizing a message for its audience and channel. Applied here, that means writing instructions for the person doing the work—not copying office shorthand onto a smaller screen. This is our application of a communication principle, not a university-tested app design.

Use your team’s familiar terms. If employees say “visit,” do not make them guess whether “ticket,” “order,” and “task” mean the same thing.

Give the employee one useful record for each visit

The important details should travel with the job. Avoid making someone open a calendar, a text thread, a shared folder, and a separate checklist to understand one assignment.

A customer asking for extra work should not silently change the agreed scope. Give the employee a way to request approval and see the decision. Likewise, show relevant prior job notes without burying today’s instructions under years of history.

Keep required fields purposeful. If nobody uses a particular answer, reconsider asking for it on every visit. A short checklist tied to the service is usually more useful than one enormous form for every kind of job.

Make updates simple—and make their destination clear

An employee should know what a button does. “Submit work for review” communicates something different from “Close job.” If management still needs to check the work, do not label the employee’s action as final customer approval.

• Starting work: confirm the correct visit before recording a job start or time entry.
• Reporting an issue: capture what happened, what help is needed, and a relevant photo when appropriate.
• Finishing work: show what remains to be completed before the submission can go through.
• After submission: clearly confirm whether the update was received and who reviews it.

Do not assume an issue form is an emergency channel. Explain which situations require an immediate call or your established emergency procedure. Employees should stop in a safe place before using the phone, not interact with the system while driving or operating equipment.

In the office, each submitted issue needs an owner and an unresolved status. An easy field form provides little value if its messages disappear into an inbox nobody checks. Our guide to getting the owner out of every handoff explains why responsibility matters alongside software.

Give people the access their work requires

A crew member might need assigned jobs, relevant customer contact details, their own time entries, and a way to report issues. They may not need company-wide pricing, other employees’ records, payment settings, or financial reports.

A crew lead may need a wider view than a new employee. Decide access by responsibility, not by handing everyone the owner’s login. Hiding a menu is not sufficient protection: the system must also enforce access when someone requests the underlying data.

Missouri State University’s mobile-security guidance recommends locking devices, considering device-location options, and reviewing app permissions. It is a 2018 introduction, so use current instructions from your device provider rather than treating its interface examples as current.

For account protection, CISA’s small-business resources cover strong passwords, multifactor authentication, and software updates. Those are useful starting points, not a complete security plan.

Agree on who supplies the phone and data connection, what work information it holds, what permissions the app requests, and how a lost device is reported. Explain any location collection before using it. Have a process to remove account access when someone leaves. Avoid scattering sensitive customer details across personal text threads and photo backups.

Plan for weak signal before promising “works anywhere”

A page that fits a phone does not automatically work without an internet connection. Offline access, saved drafts, photo uploads, and synchronization must be deliberately designed and tested.

For an online-only tool, make the limitation explicit and provide an agreed fallback, such as calling the office from a safe location with service. Do not tell employees an update is saved when the server has not received it.

If offline support is part of the project, distinguish “saved on this device,” “waiting to send,” and “received by the office.” Decide what happens if two people change the same job, an upload fails, or a phone is lost before it reconnects. Limit locally stored customer information to what is necessary.

Show when an assignment was last refreshed. Yesterday’s saved schedule should not look like a confirmed live plan. The previous scheduling guide covers how changes should reach employees and customers.

Test one ordinary visit and one difficult one

Ask an employee to try the workflow on the kind of phone they actually use, with clearly labeled sample information. Let them work through it before explaining where every button is. Watch where they hesitate.

1. Find the next assignment and explain the scope back to you.
2. Locate the access instructions and office contact.
3. Report a blocked entrance or a customer request for extra work.
4. Attach a sample photo and submit the visit for review.
5. Check the office view to confirm the update reached the right job.
6. Repeat an update with connectivity interrupted, then restore it and check for missing or duplicate records.

Also check readability outdoors, larger text settings, straightforward labels, and tap targets that are easy to distinguish. Avoid making color the only difference between “waiting” and “complete.” A screen that looks polished at a desk still needs to work in the conditions your team encounters.

Teach the workflow with a demonstration, supervised practice, and a chance to ask questions. The software supports training; it does not replace it.

The Pebble Creek approach: the same business, a different view

Pebble Creek Media grew from building a custom operating system around Pebble Creek Landscaping & Lawn. The point was not to give everyone more software to manage. It was to put the right information in front of the right person at the right time.

For a custom business operating system, we look at what the owner, office, crew lead, and employee each need to do. They can work from connected records without all seeing the same dashboard. When the website connects to the operating system, customer requests can become organized work instead of another message the owner has to remember.

Permissions, checklists, photos, timekeeping, notifications, and offline behavior are scoped around the business; they are not automatically included in every build. If your existing tool already supports a clear field workflow, improving its setup may be enough.

A useful place to start: write down the last five questions your employees called or texted you about during jobs. Which could have been answered by accurate information on the assignment? Bring that list when you talk with us about your operation. It is more useful than a wish list of fifty features.