Build the smallest shared job record that keeps the office and field aligned. Define the work order, allowed status changes, assigned technician, required evidence, blocked-job route, and connectivity rule before adding maps or automation.
KasiLabs can create tailored workflow software around that definition for private testing. It is not a prebuilt field-service platform and does not automatically include offline sync, route optimisation, GPS tracking, invoicing, or a native mobile app.
The short answer
A focused first version usually needs three views:
- a dispatcher queue showing unassigned, scheduled, active, blocked, and overdue jobs;
- a technician job card showing only the work, instructions, evidence, and actions assigned to that person;
- a supervisor review queue for exceptions, rejected completion, repeat visits, and release decisions.
Behind those views, keep separate records for the work order, assignment, visit, task, evidence item, part or service used where relevant, status transition, exception, and completion review.
If standard field-service software already handles your scheduling, mobile work, invoicing, parts, and reporting, use it. A tailored app is most useful when the job rules are stable but do not fit the standard route.
Write the job-state contract
Start with one ordinary service job and one awkward job. Decide which states exist and who can move the job between them.
A route might look like:
requested → triaged → assigned → accepted → travelling → on site → blocked or completed → reviewed → closed
Do not copy this route without checking your work. A maintenance visit, inspection, installation, delivery, property repair, and mobile health or safety job can have very different obligations. High-impact or safety-critical work also needs qualified professional and technical review beyond a general workflow app.
For each transition, settle:
| Transition question | Example decision to define |
|---|---|
| Who acts? | Dispatcher, technician, supervisor, customer contact, or integration |
| What is required? | Appointment, instructions, asset, checklist, evidence, or reason |
| What is recorded? | Actor, time, location if lawful and necessary, note, and result |
| What can block it? | Missing part, unsafe condition, no access, wrong asset, or no customer |
| What happens next? | Reschedule, escalate, create a follow-up, review, or close |
Microsoft's Field Service documentation connects work orders with customer accounts, tasks, parts or products, services, scheduling, and technician completion. That breadth is useful as a reference, but a focused app should include only the records your operation needs. Microsoft Field Service overview
Separate assignment from the visit
The work order describes the job. The assignment says who is expected to handle it and when. A visit records what happened on one attempt.
Keeping them separate handles real exceptions:
- a technician declines or cannot attend;
- a dispatcher reassigns the job;
- the customer is unavailable;
- the job needs a second visit;
- two people work on the same order;
- the appointment changes without changing the requested work.
Do not overwrite the original technician and scheduled time. Preserve the assignment history, and let the current view show the active assignment.
The technician should receive only the records required for their jobs. A calendar or daily list can lead to the job card, but the application must enforce access beyond the visible list. OWASP recommends least privilege, default denial, and permission checks on every request. Test whether a technician can retrieve another person's work order by changing an identifier. OWASP Authorization Cheat Sheet
Make field evidence part of completion
Completion should mean more than selecting “done.” Decide which tasks, measurements, notes, photos, attachments, customer acknowledgement, parts, or exception reasons are required for each job type.
Microsoft describes inspections as question sets tied to work orders, with required questions, validation options, images, attachments, asset history, and published templates. This illustrates an important control: the work instructions and the evidence expected at completion should be connected. Microsoft inspections overview
Use conditional evidence with care. A failed check might require a note and photograph. A replaced part might require quantity and identifier. A blocked job needs a reason and next owner. Do not force staff to capture data that no one uses, especially sensitive customer or location data.
Customer signatures or acknowledgements need a precise purpose. A drawn mark on a screen is not automatically a legally valid signature, proof of identity, or acceptance of every commercial term. Verify the jurisdiction, consent language, identity method, storage, and downstream use before making that promise.
Design the blocked-job route before the happy path automation
Field work fails in predictable ways. Turn each one into an owned state instead of a free-text note.
| Blocker | Useful response |
|---|---|
| Customer unavailable | Record attempt, reason, next contact owner, and reschedule decision |
| Missing or wrong part | Identify item, quantity, responsible team, and whether the job can continue |
| Unsafe condition | Stop the workflow and route according to the customer's approved safety procedure |
| Instructions unclear | Return to the office owner; preserve the version the technician received |
| Scope changed | Require an approved change before additional work where policy demands it |
| App or connection failed | Preserve a safe fallback and later reconciliation route |
Notifications should bring the next owner to the record. Avoid putting private job information, access links, or unnecessary customer data into ordinary messages.
Connectivity is a product requirement, not a styling detail
A phone-friendly web page is not an offline field app. If staff work in basements, rural areas, remote sites, or buildings with unreliable connectivity, write a testable offline requirement before choosing the platform.
Microsoft's Field Service guidance shows how deliberate offline support is: administrators choose which tables and records a device downloads, apply filters, define sync behaviour, and handle status. Its current documentation also notes that the newer mobile experience does not support offline work. Microsoft offline profile, work offline
Answer these questions:
- Which assigned jobs must be available without a connection?
- Can staff create evidence offline, and how is it protected on the device?
- What happens if the dispatcher changes the job while the device is offline?
- How are duplicate completion and conflicting edits resolved?
- Can the user see last sync, pending work, and failed uploads?
- What is the safe fallback if sync does not complete?
Treat KasiLabs as online-only for this use case unless offline behaviour has been implemented and tested for the exact app. The same rule applies to live GPS, mapping, route optimisation, telephony, SMS, asset telemetry, payments, and invoicing.
Test the job on real devices and bad days
Run these cases in the private working version:
- An ordinary assigned job from acceptance to completion.
- Reassignment after the first technician accepts.
- A technician trying to open another person's job.
- Stale or changed instructions.
- Missing part and an owned follow-up.
- A repeat visit linked to the original order.
- Required evidence omitted.
- A supervisor rejecting completion with a reason.
- Customer unavailable.
- Failed notification, outside connection, or loss of connectivity.
- Duplicate completion submission.
- An application change that requires the previous release.
Use the actual phones, tablets, browsers, protective equipment, lighting, and network conditions where possible. A field form that works at a desk can fail when someone has one hand free, wears gloves, or must capture evidence quickly.
In KasiLabs, operators describe the job and awkward cases in plain language. The plan becomes a private working version. Technicians, dispatchers, and supervisors test only the roles they will use. Owners select access and paid-action limits, then an authorised reviewer approves the exact release. Earlier app versions remain available, but rollback cannot undo a message, payment, customer interaction, or physical service already performed. Working copy versus live release
Choose packaged field-service software when breadth matters
Packaged field-service products are usually better when standard scheduling, dispatch, route optimisation, offline mobile operation, invoicing, payment, parts, maintenance contracts, customer communication, and integrations fit the business. Dynamics 365 and Salesforce also carry established administration and ecosystem depth. Rebuilding that scope is a substantial product commitment.
A focused tailored workflow is more reasonable when one unusual job, evidence, approval, or exception route keeps falling outside the system and the organisation is ready to own it. It is not a fit for emergency dispatch or safety-critical decisions without the appropriate specialist review and resilience.
KasiLabs helps customers create the tailored workflow; it does not deliver a finished field-service product. Use the hardest-workflow trial and current security controls before putting real job or customer records into any new app.
Describe one ordinary and one blocked field job in KasiLabs. Test them privately on the devices and connection conditions your team actually uses, and release only when assignment, evidence, access, and recovery are clear.