Office
- Routes
- Assignments
- Visit calendar
- Documents
Executive summary
1. What the review found
The work rests on connected objects: employee, client, visit, route, task, working time, a signed service record, payout and vehicle. What makes the sector distinctive is that almost all of it happens away from the office and is confirmed only afterwards.
The review found that the office reconstructs what happened after the work is done. The actual picture is assembled by hand from rotas, messages, timestamps and paper documents. The problem is not missing features but the breaks between planning, confirmation of delivery and reconciliation.
The question of location data stands apart. It is resolved not by technology but by a rule: a mark is needed at the start and at the completion of a task, and between those points staff are not tracked and should not be.
| Finding | Statement |
|---|---|
| Primary constraint | The actual picture of work is assembled by hand from rotas, messages, timestamps and documents — after the visits have already happened. |
| Recommended first step | Create a single visit record holding the assignment, timestamps, checklist, signature and exceptions — from planning through to payout preparation. |
| Expected effect | Less manual reconciliation, clear ownership and earlier detection of missing confirmations. Quantitative effect is assessed after rollout. |
Areas reviewed
Field work
- Mobile tasks
- Start and completion
- Checklist
- Client signature
Settlement and control
- Hours
- Exceptions
- Payout data
- Change log
Fleet
- Assignment
- Mileage
- Fuel
- Maintenance
Starting position
2. Baseline capture of current work
The review starts by capturing one full working day. For each operation we record who performs it, how often, which carrier holds the data, and whether the same data is moved again. Everything else in this document rests on this table.
| Operation | Who performs it | Frequency | Where the data lives | Re-keyed |
|---|---|---|---|---|
| Visit planning | Office dispatcher | Daily and weekly | A rota in a spreadsheet | Yes — the plan is duplicated in messages to staff |
| Communicating the route | Dispatcher | On every change | Messenger, phone call | Yes — changes are passed by hand and do not always arrive |
| Starting a visit | Field employee | Per visit | Memory, a mark after the fact | Yes — the time is reconstructed at reconciliation |
| Working through the checklist | Field employee | Per visit | A paper sheet or memory | Yes — the service content is copied into the record |
| Client signature | Field employee and client | Per visit | A paper service record | Yes — the record is carried to the office and linked to the visit by hand |
| Completing a visit | Field employee | Per visit | A mark after the fact | Yes — the actual duration is estimated later |
| Reconciling hours | Office | Weekly and at period end | Comparing rota, messages and service records | Yes — this is the main manual work of the period |
| Handling an exception | Office | When noticed | Correspondence | Yes — the exception is found at reconciliation, not on the day |
| Preparing payouts | Office and bookkeeping | Monthly | A manual roll-up | Yes — hours are interpreted a second time |
| Vehicle records | Fleet owner | Irregularly | Paper documents, a photo of the odometer | Yes — mileage and costs are entered by hand |
What follows from thisIn ten operations out of ten the data is moved again. The sector’s defining feature shows in rows three and six: start and completion are marked from memory after the visit. That makes unreliable not only the hours but everything that follows from them — payouts, cost per visit and route planning.
Diagnostic panel
3. State of the operational system
The main losses do not occur inside individual actions but between the office, the field employee and the reconciliation that follows.
47/100average process maturityManual reconciliation risk high
10points of re-keyingCandidates for removal
6critical data handoversNeed an owner
2priority pilot flowsVisit + exceptions
Process maturity
Expert assessment on a 0–100 scale. Higher means a more resilient process.
Structure of operational risk
Distribution of recorded observations by type.
18observations
39% — scattered data33% — late exceptions28% — unclear ownership
The numbers on this demonstration panel are illustrative. In a paid review the assessments are derived from interviews, a sample of working records, process observation and an agreed 0–100 scale.
Process map
4. Current process and handover points
The map describes the typical flow of information that generates manual work in mobile care. It is a process model, not a snapshot of any particular client system.
Planning
The office allocates visits and staff in the rota.
Assignment
The employee receives the task and confirms it.
Delivery
The visit is carried out against a checklist on route.
Confirmation
Time, service content and client signature are recorded.
Exceptions
Missing confirmations surface and are handled.
Approval
The period’s hours are accepted by an owner.
Payout
Settlement is built from accepted visit records.
Fleet
Mileage and maintenance enter the vehicle history.
Risks at the handover points
| Handover | What can be lost | Consequence | Priority |
|---|---|---|---|
| Plan → employee | The current assignment, task details or a change | The wrong order of visits, or repeated clarification | High |
| Employee → office | Start, completion, checklist or signature | Manual chasing before the visit can be closed | Critical |
| Time → payout | Approved hours and the reason for an exception | Manual recalculation and delayed control | Critical |
| Fleet → operations | Driver, mileage or maintenance status | Incomplete vehicle history and extra checks | Medium |
| Message → record | A decision or task stays in a private chat | There is no shared log of decisions | High |
| Service record → documentation | The link between a signed record and a specific visit | The proof of service exists but is attached to nothing | High |
Risk heatmap
| Area | Likelihood | Impact | Detection | Result |
|---|---|---|---|---|
| Incomplete visit confirmation | High | Critical | Late | Critical |
| Discrepancy in working time | High | High | Late | Critical |
| Route change not delivered | Medium | High | During the day | High |
| Document without a current status | Medium | Medium | On review | Medium |
| Incomplete vehicle history | Medium | Medium | Regularly | Medium |
Root causes
5. Why this happens
Missing hours, unsigned service records and repeated status questions share the same structural causes.
A. There is no single visit recordRota, task delivery, time, signature and payout data exist as separate facts. None of them is the visit as a whole.
B. Ownership changes at every handoverThe office owns the plan, the employee owns the confirmation, and a third person reassembles the result. At the seam, ownership is not passed on — it disappears.
C. Exceptions surface lateA missing signature or an unfinished visit shows up at reconciliation rather than when the task closes. By then the circumstances can only be recovered from the employee’s memory.
D. Communication is not attached to the workA clarification can stay in a private chat and never reach the visit record it belongs to. A month later it cannot be found — and sometimes cannot be proven.
Decision principleAutomate the capture of confirmations first and optimisation second. Reliable timestamps, task state, signature and exception handling create the basis for improving routes, workload and cost. In the reverse order, unreliable data gets optimised.
Responsibility zones
6. Who does what — and how much of it is moving data
The real work happens away from the office, so the office is busy reconstructing it. Below is where work is duplicated and where a role does not decide anything but gathers data out of other people’s messages and documents.
| Role | What it does today | How much of that is moving data | Review observation |
|---|---|---|---|
| Office dispatcher | Route planning, assignments, communicating changes | Manually duplicating the plan in messages and ringing round on changes | The plan is delivered into the app; the role keeps decisions about routes and cover |
| Field employee | Visits, care, checklist, service records, reporting back | Reconstructing time and service content after the fact | Confirmation is captured on site; the role keeps the work with the client |
| Reconciliation owner | Comparing rotas, messages, service records and hours | Practically the entire function is moving and comparing data | Reconciliation is built from confirmed visits; the role keeps resolving exceptions |
| Bookkeeping | Calculating payouts, documents | Re-interpreting hours from a manual roll-up | Settlement is taken from accepted visit records |
| Fleet owner | Repairs, maintenance, mileage, fuel | Manual entry from paper documents and photos | Vehicle history grows at the moment of the event |
| Management | Quality control, handling complaints, client relationships | Reconstructing what happened from correspondence | The visit history is available without reconstruction |
The organisational conclusion stays with the companyThe review shows which part of the work is moving data and which part is deciding. What happens with the time freed up — redistributing tasks, retraining people or changing the structure — is the owner’s call. Mobile care carries a sector constraint: almost no time is freed among field staff; it is freed in the office and in reconciliation.
Observation and confirmation are different thingsA mark at the start and completion of a task exists to confirm a delivered service, not to monitor an employee. The practical rule: location is stored at two points — task start and task completion — and nothing is recorded in between. This distinction determines whether staff accept the system; an attempt at continuous monitoring yields resistance and workarounds instead of data.
Target operating model
7. States, boundaries and rules
Every visit passes through explicit states. Each defines an owner, the required data and the condition for moving on.
| State | Owner | Required information | Transition condition |
|---|---|---|---|
| Planned | Office | Client, task, time window, employee | Assignment published |
| Accepted | Employee | Task confirmed in the mobile application | Start of the route or the visit |
| In progress | Employee | Start time and permitted location data | Checklist completed |
| Completed | Employee and client | End time, notes, signature, reason for an exception | Confirmations passed validation |
| Approved | Office | Exceptions reviewed, working time accepted | The record enters the payout data |
Boundaries of automation
The system should determine
- Whether the mandatory confirmations for a visit are present
- Whether a record is incomplete and exactly what is missing
- Who performs the next action
- What data changed and when
- Whether a vehicle is due for maintenance by mileage or date
The system should not decide
- Clinical questions and the scope of care required
- Whether a disputed visit is paid
- Whether disciplinary measures are taken
- Whether routes change without an authorised dispatcher
- Whether staff are monitored between visits
Rules, deadlines and escalation target
A rule without a deadline and an addressee does not work. Below is the minimum set that brings missing confirmations into handling the same day.
| Rule | Deadline | Escalates to |
|---|---|---|
| A visit does not count as complete without a checklist and a signature | At the moment of completion | Blocking rule, no escalation needed |
| Task not accepted by the employee | 30 minutes before the time window opens | Office dispatcher |
| Visit not started within the agreed window | 15 minutes after the window opens | Dispatcher, then management |
| Visit completed without a client signature | Same day | Dispatcher, then management |
| Visit exception not handled | 1 working day | Reconciliation owner, then management |
| Period hours not approved by the cut-off date | The payroll cut-off | Management, then bookkeeping |
| Odometer reading not entered | At end of shift | Fleet owner |
| Mandatory vehicle maintenance falls due | 14 days before the due date | Fleet owner, then management |
Priorities and sequence
8. What to do and in what order
The sequence is oriented towards transparency and acceptance by staff. Each stage must deliver value on its own.
| No. | Recommendation | Why now | Acceptance criterion |
|---|---|---|---|
| 1 | Visit record and mobile completion | Connects plan, task, time, checklist and signature | A visit is traceable from assignment to an approved confirmation |
| 2 | Exception queue | Brings missing signatures and unfinished visits into same-day handling | Every incomplete record has an owner and a reason |
| 3 | Working time approval | Removes manual reconstruction before payouts | Approved hours are derived from accepted visit records |
| 4 | Contracts and documents | Standardises creation, storage and online signing | Status and the signed version are visible on the employee record |
| 5 | Fleet records | Connects vehicle assignment, mileage, fuel and maintenance | Every vehicle has a current driver and an event history |
| Later | Odometer recognition and route optimisation | Useful only once the core data is stable | Recognition errors and accuracy are measured before scaling |
Do not start with a full platform rebuildIntroduce the visit confirmation path and the exception queue first. Extend the system once staff perform the daily process reliably. In field work, acceptance by staff is a technical precondition rather than a communication question: an unconvinced employee will not break the system — they simply will not use it.
Rollout plan
These durations are indicative for a demonstration sample. A real estimate is formed after access to the tools, record samples, roles and integration constraints.
| Stage | Duration | Outcome | Checkpoint |
|---|---|---|---|
| Discovery and data map | 1–2 weeks | Agreed process, roles, fields, exceptions and migration boundaries | Owners approve the target visit record |
| Pilot of core operations | 4–6 weeks | Planning, assignments, mobile delivery and validation of confirmations | The pilot team performs real daily work |
| Time approval and documents | 3–5 weeks | Exceptions, approved hours, payout data and documents | The office closes the period without parallel manual reconstruction |
| Fleet and communication | 2–4 weeks | Vehicle history, assignments, work chat and notifications | Rules on ownership and retention are agreed |
| Optimisation | As measured need dictates | Odometer recognition, extended reporting or route support | Baseline and target metrics are defined |
Measuring the outcome
9. Metrics, reporting horizon and next step
This sample claims no numeric effect. In a real review the baseline is recorded first, then the metrics are compared after an agreed period of use.
| Metric | How it is calculated | How to capture the baseline | Direction |
|---|---|---|---|
| Incomplete visit records | Completed visits without mandatory confirmations / all visits × 100 | Checking a two-week sample of visits at first review | Down |
| Reconciliation effort | Office time spent correcting hours, signatures and tasks per period | Measured across the last two period closes | Down |
| Age of an exception | Time from a problem appearing to its resolution | Manual timing on a sample of incomplete records | Down |
| Mobile completion | Visits completed through the intended process / assigned visits × 100 | A count from the log over two weeks | Up |
| Payout corrections | Number of corrections after working time is approved | Roll-ups from the last three periods | Down |
| Completeness of vehicle history | Vehicles with current mileage and service date / all vehicles × 100 | A snapshot of the fleet at the reporting date | Up |
Horizon: from the visit to the annual report
A review does not end at a confirmed visit. Operational data has to reach management and annual reporting without being entered again — otherwise cost per visit and route profitability remain estimates.
| Level | What must arrive without manual assembly |
|---|---|
| Day | Visits delivered, incomplete confirmations, open exceptions |
| Week | Route completion, hours by employee, mileage and fuel |
| Month | Approved hours, payout data, documents and their statuses |
| Quarter | Cost per visit, staff workload, fleet costs |
| Year | Management reporting for the service on one data model |
If cost per visit is only approximately known, the cause is usually not the calculation but that time and travel costs are not attributed to a specific visit at the moment of the event.
Questions to settle before development
- Who can create, reassign, complete, correct and approve a visit?
- Which timestamps and location data are lawful, necessary, and how long are they retained?
- Which confirmations are mandatory before a visit is approved?
- Is involvement of an employee representative body required, and in what form?
- Which payroll, accounting or care systems have a documented exchange interface?
- Which functions must work offline for field staff?
Recommended next decisionRun a focused study of the visit confirmation path. Use one week of anonymised rotas, task descriptions, time corrections and sample documents. Output: a data model, a role matrix, an exception list and the pilot scope.
This document demonstrates the structure and level of detail of the deliverable of the “Process review” service. It is based on the mechanics of a delivered, anonymised platform for mobile care services, is not legal, clinical, employment-law or data-protection advice, and contains no confidential client information. Maturity scores are illustrative. The permissible scope of location data collection and its retention periods differ by jurisdiction and must be checked separately before development starts.