CONFIDENTIAL PROJECT · FIELD SERVICE SAAS

Field Service Management Platform — GPS, Scheduling & Mobile Workforce

Multi-tenant field-service software connecting customers, service companies and mobile workers through dispatch, GPS tracking, digital work orders, payments and mobile apps.

Originally built for lawn care and snow removal; the architecture can support many on-demand and field-service industries. Laravel + Ionic/Capacitor. Client name omitted.

LaravelIonicCapacitorMulti-tenantGPS dispatchACH payouts
Build a Field-Service Platform Watch demos AI Voice path
Industry
Lawn · snow · field services (adaptable)
Type
Marketplace SaaS + company portal + hybrid mobile
Roles
Platform admin · provider · worker · customer
Stack
Laravel · MySQL · Ionic · Capacitor · Authorize.net
Proof
8 web · 5 mobile · 9:44 + 5:34 demos
FIELD SERVICE · MARKETPLACE SAAS

Customers → companies → workers → GPS → dispatch → jobs → payments → ratings.

Who this is for. Teams building multi-tenant field-service, workforce or on-demand marketplace products—not only lawn/snow operators.

What you get. Evidence of Laravel + Ionic/Capacitor: provider portals, ACH/commission, insurance gates, radius dispatch, near-real-time GPS, digital work orders and two working demos. Lawn & snow are the original vertical—not the limit of the architecture.

Searches this page answers: field service management software · GPS dispatch · mobile workforce · multi-tenant marketplace · digital work orders · provider payouts · custom FSM development

Homeowners needed on-demand lawn and snow work; service companies needed dispatch, payouts and compliance without retyping orders. A brochure site plus a separate app team would duplicate radius matching, commissions and ACH every sprint. The reusable story today: distributed customers + distributed workforce + digital booking → dispatch → GPS → field execution → payment → communication.

Who this platform is for

On-demand / marketplace operators

Platform owner + many provider companies + mobile customers.

Multi-location service businesses

Workers, jobs, GPS and digital work orders under one API.

Vertical SaaS founders

Reuse dispatch/payments primitives for HVAC, cleaning, telecom techs, etc.

Teams adding AI Voice later

API-first booking/dispatch ready for voice agents as an extension.

Original use case: lawn & snow

The delivered product connected homeowners who need mowing or snow removal with local service companies and field workers. Treat that as the case-study vertical; the architecture is field-service + marketplace primitives.

The field-service problem

At scale, operations need digital booking, eligibility rules, geo dispatch, worker location, photo-proven completion, card capture, provider payouts and ratings—with one API truth so admin, company desk and mobile never diverge on pricing or eligibility.

Constraints

Delivery stayed inside the client’s stack and tenancy boundaries. Client name omitted; screenshots and demos are from a private install. AI Voice / AI dispatch below are labeled future extensions, not shipped features of this build.

Field service management + marketplace

FSM manages

  • Workers
  • Jobs / work orders
  • Schedules
  • Dispatch
  • Locations / GPS
  • Service execution

Marketplace manages

  • Customers
  • Provider companies
  • Commissions
  • Payments / ACH
  • Onboarding & insurance
  • Ratings

This architecture combines both—more than a catalog marketplace or a single-company FSM.

Four-sided ecosystem

PLATFORM
                       │
       ┌───────────────┼───────────────┐
       ▼               ▼               ▼
   Customers       Companies       Workers
       └───────────────┼───────────────┘
                       ▼
                    JOBS → Dispatch · Payment · Rating · GPS

Working-system demos

Ionic/Capacitor mobile · 9:44

Mobile watch page →

Multi-tenant backend · 5:34

Backend watch page →
Field service platform shared login for operators and provider companies

Sentinel roles route to admin dashboard or company provider desk.

Field service platform admin dashboard with provider registrations and customer charts

KPIs: new providers, workers/customers below 4★, income charts (default last six months).

Multi-tenant field service architecture

SaaS Platform → Company A / B / C
  → Workers · Customers · Jobs · Insurance · Payouts
  Shared platform rules; tenant-isolated data
  • Providers see only their workers, transactions and insurance docs
  • Company-specific service catalog (lawn/snow toggles in original vertical)
  • Role-scoped routes and provider usertype on mutating APIs
Field service admin companies list with activation status
Provider company profile with business address EIN and contacts

Provider compliance management

Company → Profile · EIN · Insurance · Payment · Services
  → Verification → Active Provider → Dispatch

Insurance proof upload required before workers receive requests; ACH details for weekly Monday (ET) payouts net of commission.

Provider ACH payment vault with bank and billing address
Provider service configuration for lawn and snow offerings
Company desk listing mobile customers tied to the provider tenant

Near-real-time GPS workforce tracking

GPS-based field worker location tracking with ~five-minute pings—not continuous real-time streaming. Admin map shows last-reported GPS (≤15 min); history feeds matching and ops.

Worker Mobile App → GPS (~every 5 min) → Laravel API
  → Location Store → Worker Map · Dispatch · History · Ops

Collect location for defined operational purposes with mobile permissions, access controls and retention—not marketed as employee surveillance.

Field service admin Google map of workers and service coverage
Field service admin workers grid with ratings jobs and company assignment

Geo-based field service dispatch

Customer Request → Service Type → Location → Radius Filter
  → Eligible Workers → Push → First Accept Wins → Job Assignment
  (no double booking)
  • Configurable mile radius in platform settings
  • Company capability / service toggles
  • Push notifications to nearby crews
  • First-accept wins with duplicate prevention in Laravel

Skills-based dispatch — future evolution

JOB → Skill · Location · Availability · Workload · SLA
  → Match Score → Best Worker (manager override retained)

Labeled future—current delivery is radius + eligibility + first-accept.

Digital work orders & job lifecycle

Request → Dispatch → Accept → Navigate → Arrival
  → Before Photo → Start / Timer → After Photo → Complete
  → Payment → Bilateral Rating

Before photo starts the timer; after photo completes the job, triggers card charge and ratings—tied to one order row.

Customer self-service (mobile)

  • Sign-up with locations and card vault
  • Pick service per address (lawn/snow in original vertical)
  • Pricing questionnaire on first order
  • Track in-process jobs and past orders
Field service Ionic mobile app flow: sign in locations orders history
Customer mobile sign in screen
Customer mobile sign up with email phone password
Customer mobile locations with snow and lawn buttons and in-process order
Customer mobile past orders with amounts and card last four

Workers use the same mobile stack with crew login: push, accept/decline, navigation, before/after photos and ratings—described in requirements; not all crew screens are shown above.

Marketplace payments & provider payouts

Customer Payment → Gateway (Authorize.net)
  → Platform Transaction → Commission → Provider Balance → Weekly ACH
  • Card capture at checkout; completed payments cannot be silently edited/deleted in admin
  • Platform commission deducted before ACH transfer to providers
  • Commission/ACH batching aligned to US Eastern weekly payout window

API-first — one API, multiple channels

JSON API → Admin Web · Company Portal · Mobile (Customer + Worker)
  Future channels: AI Voice · WhatsApp · Partner APIs
flowchart LR
  ADM[Platform admin]
  CO[Service company]
  WRK[Field workers]
  API[Laravel JSON API]
  ION[Ionic UI]
  CAP[Capacitor iOS/Android]
  ADM --> CO
  CO --> WRK
  ION --> CAP
  CAP --> API
  CO --> API
  ADM --> API
Admin, company desk and mobile share marketplace rules on one API.

One field-service architecture, many industries

  • Home services — lawn, snow, cleaning, plumbing, HVAC, electrical
  • Healthcare visits — home care / caregiver dispatch patterns (see also Care Home case)
  • Telecom / IT — technician install, maintenance, onsite support
  • Property / security / equipment — inspections, repairs, warranty visits

AI Voice + field service — future extension

Not claimed as shipped in this project. Potential evolution using the same Field Service API:

Customer → AI Voice Agent → Intent / Booking API
  → Dispatch Engine → Field Worker → Job Completion → Notify customer
  (human escalation for exceptions)
  • Before — book, quote, schedule
  • During — status / ETA
  • After — confirm, rating, invoice, recurring offer

Links AI Voice, AI Automation and AI & Data.

AI dispatch / worker assist — future

  • Recommend worker (skills + distance + availability) with manager approval
  • Conflict / delay risk flags; route optimization as an extension
  • Worker: job summary, voice-to-note, documentation assist
  • Recurring services (weekly lawn, seasonal maintenance) via schedule generator

Scaling the field-service platform

Load Balancer → API instances → Database · Cache · Background Jobs
  → Dispatch · Notifications · Payments
  • Horizontal API scaling; location-event ingestion from mobile
  • Queue workers for push, matching and ACH batching
  • Geospatial/radius queries and rate limiting at the API
  • Push + background location policies for worker matching at scale

See SaaS · Cloud DevOps.

Location & workforce privacy

  • Location for operational matching/dispatch—with mobile permissions
  • Role-based access and tenant isolation
  • Retention and access logging as operational policy
  • Not continuous employee surveillance marketing

Related: Security & Reliability.

Business requirements (delivered)

One platform owner, many provider companies, field workers and mobile customers — lawn/snow SKUs, GPS dispatch inside configurable radius, insurance and ACH before jobs flow, card capture at checkout, bilateral ratings after photo proof.

Engineering challenges

  • Multi-tenant isolation — providers see only their workers, transactions and insurance docs
  • Geo dispatch — five-minute GPS pings, radius filter, first-accept wins without double booking
  • Job lifecycle — before/after photos, timer, charge and ratings on one order row
  • Single API truth — admin, company desk and mobile must not diverge

The solution

Delivered the full stack: platform KPI dashboard, company onboarding (ACH, insurance, lawn/snow toggles), worker CRUD, customer registry, worker map, and hybrid mobile apps for homeowners and crews on the same REST API.

My role

  • Solution architecture — marketplace + multi-tenancy + dispatch + payments
  • Backend — Laravel, REST API, job lifecycle, business rules
  • Mobile — Ionic/Capacitor customer + worker patterns
  • Geospatial — GPS pings, radius dispatch, worker map
  • Marketplace — commissions, Authorize.net, ACH, ratings
Marketplace architectureMulti-tenant authLaravel APIGeo dispatchIonic / CapacitorPayments / ACHDigital work ordersAdmin UX

Technology stack

LaravelMySQLJosh / BootstrapIonicCapacitorAuthorize.netREST APIGPS

Production considerations

  • Role-scoped routes and provider usertype on every mutating API
  • Immutable paid transactions after card capture
  • Push + background location policies for matching at scale
  • Commission and ACH batching on US Eastern weekly payout window

Outcomes

  • One API for admin, company desk and mobile — lawn and snow on the same marketplace rules
  • Dispatch, payouts and compliance checks enforced in Laravel, not in the apps alone
  • Working demos: 9:44 mobile and 5:34 backend walkthroughs
FAQ

Field service management & marketplace questions

FSM, GPS dispatch and multi-tenant marketplace—not consulting/PBX FAQ leftovers.

Field service management (FSM) software coordinates customers, jobs, field workers, schedules, dispatch, location, digital work orders, payments and mobile execution—so service businesses run operations digitally instead of spreadsheets and phone trees.

Yes. This platform uses near-real-time GPS: mobile workers report location about every five minutes; the admin map shows last-reported positions (≤15 min freshness in ops) for matching and history—not continuous surveillance.

Customer request → service type + location → configurable mile-radius filter → eligible workers get push alerts → first accept wins → assignment without double booking. Rules live in Laravel so admin, company desk and mobile stay aligned.

Yes. Multi-tenant marketplace: one platform owner, many provider companies, each with isolated workers, customers, insurance docs, services and transactions.

Yes. Provider portals include worker CRUD (email/password doubles as mobile crew login), service toggles, ACH payout details and read-only tenant transaction history.

Yes. Ionic/Capacitor customer apps: sign-up, saved locations, service selection (lawn/snow in the original vertical), pricing questionnaire, in-process jobs and past orders against the same JSON API.

Yes. Same hybrid stack with worker login: push for nearby requests, accept/decline, directions, call/SMS, before/after photos, timer and ratings.

Yes. A job ties customer, location, service, worker, status, before/after photos, timer, payment and rating to one order row—the digital work order lifecycle.

Yes. Authorize.net card vault at checkout; platform commission deducted; weekly ACH (US Eastern Monday window in this build) pays providers. Paid transactions are immutable in admin.

As a future extension: voice booking, status/ETA, reschedule and post-job follow-up calling the same Field Service API—with human escalation. This case study does not claim AI Voice was shipped in the original delivery.

Yes architecturally. Lawn and snow were the original SKUs; the primitives (companies, workers, customers, jobs, GPS, dispatch, payments, photos, ratings) adapt to HVAC, plumbing, cleaning, telecom techs, home care visits and more.

Yes—it already is multi-tenant marketplace SaaS with commissions and provider onboarding. See SaaS development for deeper productization.

No. Unrelated FAQ content was removed. This page is field-service marketplace + GPS dispatch only. For telephony marketplaces see other case studies.

Tenancy rules (platform vs companies), mobile stack preference, payout model, service catalog and whether you need AI Voice later. Screenshots beat a long RFP. Email hello@unifiedpbx.in.

Building field-service or marketplace SaaS?

Share tenancy rules, mobile stack and payout model—and whether AI Voice booking/status comes later. The first reply maps admin, API, dispatch and app boundaries.

Build a Field-Service Platform