Field operations software built for the Philippine dispatch reality.

We replace. We build. We optimize.

Every line of code we write is yours at cutover. No license. No annual increase. No lock-in.

How much does field operations software cost in the Philippines?

Subscription FSM runs ₱3K–8K per technician per month. An Orkids build is a one-time fee for your entire field team — typically 20–30% of a three-year subscription, no per-seat fee, and the code is yours.

At 20 technicians on Salesforce Field Service, a three-year subscription clears ₱5M before a single customization. An Orkids build covers the same headcount for a fraction of that, with Philippine-specific dispatch rules and BIR compliance built in, and you own it outright. Optional operations support is ₱50K–250K per month with no minimum term. The exact build cost depends on complexity — number of dispatch rules, integration count, offline coverage requirements, and whether you need preventive maintenance scheduling. All of that is confirmed on the first call, not after a month of discovery.

Can field ops software work offline in areas with poor mobile coverage?

Yes. The technician's app queues job data offline and syncs automatically when connectivity returns — no data is lost, and the job card is still signed by the customer in the field.

Philippine field work happens in basements, remote barangays, and industrial facilities where signal drops to EDGE or zero. The offline queue handles job acceptance, status updates, parts usage, customer signatures, and GPS stamps. When the device reconnects — on the drive back, at the depot, or when the technician steps outside — everything uploads in sequence. The dispatcher sees the batch of updates, not a gap in the record. Offline capability is a core requirement, not an optional add-on, because a field system that requires connectivity in the Philippines is a system that fails routinely in the places where your team actually works.

Does field ops software integrate with BIR e-invoicing?

Yes. The completed job card triggers an invoice that transmits to the BIR EIS under RR 11-2025 within the required window — no manual rekey into a separate billing system.

The typical Philippine service company runs a three-step billing process: the technician closes a job, someone at the office manually creates the official receipt in a separate system, then a third person emails it to the client. Three people, two to five days, and an error rate that grows with volume. When the job card closes in the field, the system generates the official receipt, applies the correct BIR OR series, and transmits the structured invoice to EIS. The client receives the digital OR the same day the technician departs the site. The BIR sales journal updates automatically — no end-of-month data entry.

How does automatic dispatch routing work?

The system assigns the nearest available technician with the required skill set to each new job, updating routes in real time as jobs are completed or emergencies are added.

The dispatch logic ingests real-time GPS positions of all active technicians, each technician's certified skill tags — for example, 'elevator hydraulic,' 'HVAC commercial,' 'medical equipment class B' — and the SLA window on the incoming job. When a new request arrives, the algorithm scores all eligible technicians by travel time, current workload, and SLA priority, then surfaces the top recommendation. The dispatcher accepts or overrides it in one action. Override data trains future recommendations: if the dispatcher consistently reassigns a certain job type to a specific technician, the model learns that preference and leads with it. The goal is to reduce a four-minute dispatch decision to four seconds, not to remove the dispatcher from the loop.

Can the system handle multiple service teams across different regions?

Yes. Teams in Luzon, Visayas, and Mindanao each have their own dispatch queues, but management sees a single consolidated view across all regions in real time.

Regional dispatch is the common structure for Philippine service companies — Metro Manila runs one team, Cebu runs another, Davao runs a third, each with its own supervisor and routing logic. The system supports separate dispatch controllers per region while feeding all job data into a single operations dashboard. A CFO or operations head in Manila sees open jobs, overdue jobs, and technician utilization across all regions without calling regional coordinators. Regional teams do not see each other's queues by default. Escalation paths can cross regions when a specialized skill is only available in another area, and cross-region job transfers are logged with the reason so billing and SLA tracking remain accurate.

What happens when a technician cannot complete a job?

The technician logs a partial completion with the reason, the job is automatically rescheduled, and the customer receives a notification with the new slot — no dispatcher re-entry required.

Partial completions are common in Philippine field service: a required part is not in the van, the site contact is unavailable, a related system must be shut down by the client before work can proceed. The technician selects the reason from a configured list, logs what was completed, and marks the job as 'requires follow-up.' The system creates a linked follow-up work order, notifies the customer automatically, and returns the job to the dispatch queue with the technician preference noted. If the reason is a missing part, the system creates a purchase request to the inventory module so the part is sourced before the next visit. The dispatcher touches nothing — the workflow runs on the reason code the technician selected.

How are parts and van stock managed for field technicians?

Each technician's mobile inventory is tracked per job. Usage is logged when the job card closes, and replenishment requests are triggered automatically when stock falls below threshold.

Field technicians in the Philippines typically carry a van stock of high-frequency parts — filters, fuses, common seals, cabling sections. Without a system, van stock is replenished by memory and discrepancies are invisible until the annual physical count. The field-ops module tracks every part by serial number or batch, links consumption to a specific job card, and flags discrepancies between what was logged as used and what was originally issued at the depot. When a technician's van stock of a part drops below the configured minimum, the system generates a replenishment request automatically. The depot manager approves it in one action. Inventory accuracy shifts from an annual snapshot to a continuous rolling count that updates with every closed job.

Does the system handle preventive maintenance contracts?

Yes. Contracts with fixed maintenance intervals generate work orders automatically at the correct date — no one needs to remember when a client is due for a scheduled visit.

Preventive maintenance contracts are the backbone of Philippine utility, HVAC, elevator, and medical equipment service businesses. The system stores the contract terms: frequency, scope of work, assigned technician preference, customer site access instructions, and the SLA window for each visit type. Work orders are generated automatically at the correct interval, pre-assigned to the preferred technician, and placed in the dispatch calendar. The client receives an advance notification the number of days you specify. If the contract specifies a site visit window — for example, 'first Monday of the month between 9 AM and noon' — the scheduler respects that window. Missed preventive maintenance visits appear on a dedicated overdue queue that the operations manager reviews each morning.

Can customers track the technician en route?

Yes. When the technician departs for the job, the customer receives a link showing live position and estimated arrival time — no app download required.

The tracking link is sent via SMS or the customer's preferred channel and expires when the job is marked complete. It shows the technician's name and photo alongside an estimated arrival time based on current traffic conditions. For enterprise clients with their own portals, the position data is available via API. The expected operational outcome is a reduction in inbound 'where is your technician' calls — on a 20-technician team, those calls typically consume 60 to 90 minutes of dispatcher time per day. The tracking feature can be disabled for technicians serving sites where location sharing is restricted by the client's security policy, configured per technician role.

What compliance documents does the system produce?

Signed digital job cards, service history per asset, and BIR-compliant official receipts — all retrievable by job number, customer, or date range in under ten seconds.

Philippine service companies face three compliance scenarios: client billing disputes, BIR examinations, and LGU inspections of regulated equipment. Each requires a different document set. The client needs the signed job card and parts list. The BIR examiner needs the OR series, the job-level sales data, and the transmission confirmation to EIS. The LGU inspector needs the licensed technician's credentials and the service history for the regulated asset — elevator, boiler, medical device. All three document types are stored linked to the same job record and searchable without calling anyone or opening a filing cabinet. A billing dispute resolved in 10 seconds costs nothing; one that escalates to a credit memo because no one can find the paperwork costs the entire margin on that service contract.

How long does implementation take?

Two to three weeks from contract to a live system handling real dispatch jobs — not a demo environment, a live deployment your team uses every day.

Week one: we configure job types, skill tags, service regions, customer database, and billing rules. We connect the billing module to your existing accounting system and set up the BIR OR series. Week two: your dispatchers run a parallel dispatch — the old Viber-group method alongside the new system — so they can verify the system handles their edge cases before it goes live. We adjust based on what they find. Week three: the old method is off. The new system is the only way jobs are dispatched, tracked, and billed. Your team has direct access to the engineers who built it, not a support ticket queue. Implementation is included in the build price.

Is this a custom build or a configured version of a generic product?

Custom-built to your job types, skill taxonomy, dispatch rules, and billing structure — not a configured version of a generic FSM product.

The distinction matters operationally. A configured product has a fixed data model that your business must adapt to: you change how you describe jobs, how you organize technicians, and how you structure contracts to fit the product's categories. A custom build starts with your current process and encodes it directly. If your dispatch logic says 'all hydraulic elevator jobs in Makati go to Team B unless Team B has more than three open jobs, in which case they go to Team A after supervisor approval,' the system enforces that exact rule. If your billing has a contract type where the first call-out per month is included and additional calls are billed at a separate rate, the invoicing handles that automatically. The cost of this approach is a longer initial conversation. The benefit is zero operational compromise.