Job Dispatch Software with Client Portal for Teams

Job Dispatch Software with Client Portal for Service Teams (2026 Guide)

Service team operations have two distinct audiences with different needs: the technician and dispatcher who manage the work, and the client who commissioned it. Job dispatch software historically served the internal operations side well — scheduling, routing, status tracking — and left the client side to phone calls and waiting.

The addition of a client portal changes this. When clients can see job status in real time, receive updates at key milestones, and access completion confirmation and invoices without calling, the client experience improves and the operations team's phone volume drops. The challenge is designing the two sides — dispatch and client portal — as an integrated system, not two separate tools bolted together.

Why Dispatch and Client Transparency Should Be Designed Together

The most common failure in service operations is the status gap: the technician knows they're running 45 minutes late; the dispatcher knows; the client doesn't know and calls the operations team. That phone call consumes staff time and damages the client relationship.

If the dispatch system and the client portal are integrated, a single status event (technician taps "Running Late" on the mobile app) triggers a client notification automatically — no phone call needed. The dispatcher doesn't need to add a manual step. The client receives an update and doesn't need to call.

The integration goes both ways: client-side events (rescheduling request via portal, approval of a job scope change, invoice payment) should appear immediately in the dispatch system so the operations team has current information without checking a separate system.

The Dispatch Layer

Route-aware job assignment

The dispatch board should display all technicians and all scheduled jobs for the day in a single view. For route-aware assignment:

• Jobs should display the client address alongside the job details
• The board should make geographic proximity visible (either map view or zone labels)
• Reassignment should be drag-and-drop, with the system flagging any travel time impact

For service teams with defined service zones, zone assignment is the baseline: new jobs are automatically assigned to the technician responsible for the relevant zone, and the dispatcher handles exceptions.

Real-time technician visibility

The dispatcher needs to know, at any moment: where is each technician, what job are they on, and when will they be available. Status updates from the technician's mobile device should appear in the dispatch board immediately. The dispatcher should be able to see:

• Available: No current assignment; can receive a new job
• En route: Travelling to the current job
• On site: At the client location
• Blocked: Issue at the current job; may need support or reassignment
• Completed: Job done; returning to available or en route to next

Blocked status is the most important signal: it tells the dispatcher that a job is not progressing as expected and allows them to intervene — send support, contact the client, reassign subsequent jobs if the delay is significant.

Same-day emergency handling

For service teams, same-day emergencies (a priority client, an urgent fault) are common. The dispatch board must support:

• Adding a new job mid-day and inserting it into the schedule
• Identifying which technician can respond fastest (based on current location and current job status)
• Pushing the updated schedule to the technician's mobile app immediately

If emergency job handling requires phone calls between the dispatcher and technician, the dispatch system is not providing the value it should.

The Client Portal Layer

Status visibility

Clients should be able to see, without calling:

• The date and time of their scheduled job
• The name and photo of the technician assigned
• Real-time job status (scheduled, en route with ETA, on site, completed)
• Any updates or delays notified by the technician or dispatcher

This alone eliminates the majority of "where is my technician?" calls.

Approval workflow for scope changes

When a technician discovers that the job requires additional work beyond the original scope (additional materials, additional time), the client needs to approve before work proceeds. The client portal should support:

• Technician submits a scope change request from the mobile app (description of additional work, estimated cost)
• Client receives a notification and approves or declines via the portal
• If approved, the scope change is added to the job record and invoice
• If declined, the technician is notified and can discuss with the dispatcher

This workflow — scope change request → client approval → job proceeding — is cleaner and faster than a phone call, and creates an auditable approval record.

Completion confirmation and document access

When the job is completed:

• The client receives a notification that the job is done
• The completion summary (work done, photos, technician notes) is available in the portal
• The invoice is generated and accessible for payment
• Any warranty or service documentation is attached to the job record in the portal

The client has everything they need in one place, without the operations team needing to email or call.

Platform Comparison

Feature	Tregovia	Jobber	ServiceTitan	Operata
Dispatch board with status tracking	Yes	Yes	Yes	Yes
Zone-based auto-assignment	Yes	No	Yes	No
Client portal with job status	Yes	Limited	Yes	No
Scope change approval via portal	Yes	No	Yes	No
Proof-of-work (photo + signature)	Yes	Yes	Yes	Yes
Invoice trigger from job completion	Yes	Yes	Yes	Yes
Privacy controls	Review	Canada	US	Verify
Flat-rate pricing	Yes	Per user	Per user	Per user

Verify current features and pricing at each vendor's website.

Setting Up in Tregovia

Tregovia's Appointments module (base plan), Time Tracking module (EUR 8/month), and client portal support the full dispatch + client portal workflow:

Dispatch board:

• All technicians and jobs in one view
• Real-time status updates from mobile app
• Drag-and-drop reassignment
• Zone-based assignment for routine jobs
• Same-day emergency job insertion

Technician mobile:

• Daily schedule on first screen
• Status updates (En Route / On Site / Blocked / Completed) in one tap
• Delay notification to client triggered from mobile (technician taps "Running Late" → client receives update)
• Scope change request form submitted from mobile → client approval via portal
• Photo and signature capture at completion

Client portal:

• Job status tracking (scheduled / en route / on site / completed)
• Technician identity visible (name, profile photo)
• Scope change approval / decline
• Completion confirmation with summary and photos
• Invoice viewing and payment

Proof-of-work: Before-and-after photos stored with job record. GPS coordinates at photo capture. Client signature on job completion. All stored against the job and accessible to client via portal.

Invoice integration: Job marked Complete → invoice draft generated → available in client portal → client pays via Stripe (with Online Payments module).

Privacy controls: Configure access roles, consent records, exports, deletion requests, and retention rules before publishing this workflow.

Pricing: Base plan EUR 47/month + Time Tracking EUR 8/month — flat rate, up to 2 staff / up to 100 clients (extra users EUR 10/month per 5 seats). 14-day free trial.

Measuring Dispatch and Portal Performance

KPI	Definition	Target
On-time arrival rate	% of jobs where technician arrives within scheduled window	>85%
Status update compliance	% of jobs where technician updates status at each event	>95%
Scope change approval turnaround	Average time from scope change request to client approval/decline	<2 hours
Client self-service rate	% of client contacts resolved via portal without a phone call	>70%
Completion-to-invoice time	Average time from job completed to invoice sent	<30 minutes
Portal activation rate	% of clients who access the portal at least once	>60%

FAQ

What improves client trust fastest in field service?

Predictable status visibility and completion evidence. Clients don't need a perfect service — they need a service they can plan around. When a client knows the technician is en route with a 20-minute ETA, they can make decisions about their day. When the technician completes the job and the client receives a clear completion summary with photos and a digital signature record, they feel confident the work was done correctly. The combination of proactive status updates and clear completion evidence is the highest-trust client experience in field service, regardless of the job complexity.

Should client portal updates be automated or staff-managed?

Automated for key status events, with staff override capability. The automation rule: when a status event occurs in the dispatch system (technician set to En Route, job marked Completed), the client notification fires automatically. No staff action required. Staff can manually send a message via the client portal for situations that don't fit the standard automation — a specific note about the job, a follow-up question, a delay that needs context. The default should be automated; the exception should be staff-managed.

What causes dispatch bottlenecks in small service teams?

Manual reassignment without queue prioritisation logic. When the dispatcher has to manually review the full schedule to find the best technician for an emergency job — checking each technician's current status, estimating travel times, mentally juggling the remaining day's schedule — the reassignment takes several minutes and the dispatcher cannot simultaneously handle incoming client calls. A dispatch system that surfaces available technicians ranked by estimated response time (based on current location and current job status) allows the dispatcher to make a good assignment decision in seconds.

How do service teams reduce the volume of "where is my technician?" calls?

By sending proactive status notifications before the client reaches the point of frustration. The client's decision to call is made when the scheduled arrival window has passed with no communication. If the technician status update at En Route fires a notification to the client with an ETA 30 minutes before the scheduled arrival window, the client has information before they need to seek it. If the technician is running late, a delayed notification ("Your technician is running approximately 30 minutes behind schedule — we apologise for the wait") sends before the client calls. Most "where is my technician?" calls are calls that should never have been necessary.

Which KPI indicates dispatch software is working correctly?

On-time arrival rate plus client self-service rate — measured together. On-time arrival rate tells you whether the scheduling and routing is effective; client self-service rate tells you whether the portal is providing enough transparency for clients to manage their experience without calling. A service team with a high on-time arrival rate but a low self-service rate has the dispatch side working but the client portal underperforming. A team with a high self-service rate but a low on-time arrival rate has clients who are informed about delays — but still being delayed. Both metrics need to be healthy for the system to be delivering its full value.