Field Service Dispatch and Work Order Suite

The problem

A service ticket and a dispatched job are not the same object, and most Zoho deployments try to make one do the work of both. A ticket in Zoho Desk knows a customer and a complaint. It does not know which technician holds the right certification, who is already committed at 2pm on Thursday, who is twenty minutes away rather than two hours, which van has the part on board, or what the customer signed for on site. So dispatch happens in a shared calendar or a spreadsheet, the technician phones in what they used, someone re-keys it into Zoho Inventory a few days later if they remember, and the invoice goes out with the labour hours guessed and the parts under-recovered.

The cost is not just admin. It is unbilled parts, unbilled overtime, second visits because the wrong person was sent, and no defensible record when a customer disputes what was done.

This suite is built to order. ECOSIRE scopes it against your service catalogue, your skills matrix and your Zoho org, then builds and installs it — there is no ready-made package to download.

What ECOSIRE builds

Work orders as first-class records

Work Orders live either as a custom module in Zoho CRM or as a Zoho Creator application, depending on where your service data already sits — we decide that in scoping, not by default. A Work Order carries the customer, the asset or installation being serviced, the service type, required skills, SLA target, scheduled window, assigned technician, status, and links back to the originating Zoho Desk ticket. Deluge validation enforces the status transitions you actually use rather than a generic lifecycle.

Desk remains the customer-facing conversation. A custom function on the Desk ticket creates the Work Order with contact, asset and description carried across; when the Work Order completes, the ticket is updated and, if you want it, resolved automatically.

Scheduling on skill, availability and proximity

The dispatch board is a Sigma widget rendering unassigned work orders against a technician timeline. Assignment is assisted by a Deluge scoring function that ranks candidate technicians on three inputs: whether they hold the skills and certifications the service type requires, whether they have a free slot of sufficient duration accounting for existing jobs and any leave drawn from Zoho People, and how far their previous job or home base is from the site — computed from stored coordinates or by calling a geocoding endpoint you supply credentials for. The dispatcher sees the ranking and the reason for it, and can override any of it. We do not build a black box that assigns jobs nobody can explain.

SLA breach risk is calculated against the Desk ticket's SLA and surfaced on the board so at-risk jobs sort to the top.

Mobile job sheets

Technicians work in a Zoho Creator mobile application: today's assigned jobs, travel start and arrival stamps, a checklist driven by the service type, fault and resolution notes, photographs into file fields, parts consumed, labour time, and a customer signature capture field. Offline capture matters on plant rooms and basements, so forms are designed for the Creator mobile offline behaviour and reconciled on reconnect, with conflict handling defined during scoping.

Parts, stock and the invoice

Parts consumed on a job draw against the technician's van as a warehouse location in Zoho Inventory. Confirming consumption posts an inventory adjustment or transfer through the Zoho Inventory REST API, so van stock is a real balance rather than an assumption, and a reorder alert can fire when a van drops below its defined minimum.

On work order completion a Deluge function assembles the billable position — labour at the contracted rate or included under a service contract, parts at the customer's price list, travel and callout charges — and creates the invoice in Zoho Books through the Invoices API with the correct tax rates and GST/VAT treatment for the Books organization. Contract-covered work produces a zero-value job record instead of an invoice, so coverage is still evidenced.

Contracts, assets and preventive maintenance

Assets are tracked with install date, warranty end and service history. Service contracts define coverage, included visits and response times. A scheduled Deluge function generates preventive maintenance work orders ahead of their due date so planned work enters the same dispatch board as reactive work and competes for the same capacity honestly.

Who it is for

HVAC, electrical, lift, medical equipment, IT infrastructure and industrial maintenance firms running roughly five to a hundred field technicians, already on Zoho Desk or Zoho CRM, who need dispatch and parts consumption to reach accounting without re-keying. It fits organisations where the technician's skill set genuinely constrains who can attend; if any technician can do any job, the scheduling layer is more machinery than you need.

How delivery works

Scoping call. We map your service types to required skills, review your SLA definitions, your Inventory warehouse structure including whether vans are already modelled, your price lists and your contract terms.

Fixed quote. A written scope listing every module, function, widget and integration, with timeline and fixed price. Work begins only on your approval.

Build. Two to four weeks for a typical scope. Built in a development environment against test data — never against your live Desk queue or live stock balances.

Install in test, then production. We deploy to your test environment, run a full week of real jobs in parallel with your current process, and compare the invoices the system would have raised against the ones you actually raised. Production migration follows your sign-off on that comparison, including roles, profiles and OAuth connections.

Support. A defined support window after go-live for defects and configuration tuning, with documentation and technician training included.