In companies that sell machinery and equipment, service work usually starts on the telephone and ends in a notebook. We build the whole chain in a single system — from the service request to technician assignment, from the mobile work order to the parts used and the customer's signature — and track warranty cover and SLA times automatically.
In a company that sells machinery, the sale does not end when the product is delivered to the customer; the long relationship starts with service. Yet in most firms service work runs off the record. The customer telephones the service manager, the manager sends out one of the technicians, the technician writes what they saw on site in their own notebook and reports the part they used to the warehouse verbally in the evening. The system looks as though it works, because jobs somehow get closed. But the answers to who went when, how many times the same fault has appeared on a given machine, and whether a part is to be charged to warranty or to the customer, are held together nowhere. That information only starts being looked for when a problem grows — and usually in the middle of an argument that has already gone too far.
The bill for this fragmentation comes from three places. The first is warranty: a job that should be out of cover is done free of charge because there is no record; or, conversely, a job under warranty is invoiced to the customer and the relationship is damaged. The second is parts. Because the parts carried in the service van do not appear in warehouse stock, the count never balances and the same part is bought a second time. The third is time. When a technician's day is filled with two jobs at opposite ends of the city instead of two jobs close together, the time lost appears in nobody's report. Each of these three items looks small on its own; by the end of the year they grow large enough to leave the question of whether the service unit really makes a profit or a loss unanswered.
Field service management (FSM) runs this chain end to end on a single record. An incoming request becomes a service record; the record is attached not to the customer but to the specific machine at the customer's site. The machine's serial number, installation date, warranty end and past service jobs sit alongside that record. When the assignment is made, the technician's skills, their region and their workload for the day are visible together. The technician receives the job on their own phone; they enter the work done, the parts used and the time spent there on site, and take the customer's signature on the screen. The moment the job is closed, parts come off stock, warranty cover is determined and the items to be invoiced are ready. On the office side, where the open jobs stand, which technician is on which job and which request is about to run out of time are all monitored from a single screen.
The place where this work stumbles in the field is almost always the same: the internet. Service may be delivered in a factory basement, on a construction site or at an out-of-town plant with no coverage. If the mobile application cannot work offline, the technician has to enter the record again in the evening — and within a few weeks stops using the system altogether. That is why we build the mobile side offline-first: the work order sits on the device, entries are made on the device, and everything is synced when the connection returns. Against that, let us be honest: field service software reduces wasted travel, but it does not solve traffic, a customer keeping you waiting at the gate, or a wrong diagnosis. What the system gives is not a shortcut but visibility. And visibility is not a gain in itself; it makes what the service unit really costs measurable for the first time, and from then on decisions rest on data.
Manufacturers that provide commissioning, periodic maintenance and breakdown service for the machines they sell. In these firms service is a line of business independent of sales; when no history is kept per machine, warranty arguments grow and the opportunity to sell spare parts stays invisible. Commissioning reports, maintenance schedules and fault records accumulate on the same machine card.
Companies working under periodic maintenance contracts, in areas such as lifts, refrigeration, generators, air conditioning or fire systems. Most of the work arrives from the calendar; being able to prove afterwards that the visit covered by the contract was made on time is a requirement in its own right. The system turns calendar visits into work orders automatically and flags work that falls outside the contract separately.
Firms that promise their customers to be on site within a given time — that is, firms working under a service level agreement (SLA). Whether the commitment has been met can only be measured by recording separately the moment the request was opened and the moment the technician arrived on site. Without those two timestamps what you get is not a report but a guess; and the annual review rests on the same guess.
Businesses sending technicians across a wide geography with a handful of planners. The real gain here is that the office stops telephoning technicians all day to ask how a job is going, and that where the open jobs stand becomes visible from a single screen. The planner's work shifts from managing telephone traffic to reviewing the day's plan; and what the customer is told stops being a guess.
A request arriving by telephone, e-mail, WhatsApp or the customer portal becomes a single record. The record is attached not to the customer but to the machine at the customer's site; the serial number, installation date and past service jobs appear on the same screen. Request type and urgency are separated from the outset, so breakdowns and planned maintenance do not get mixed in the same queue. If there is an unclosed record on the same machine, a warning is given and one fault is not split into two work orders.
When an assignment is made, the technician's skills, their region and their workload for the day are visible together. Jobs in the same region are grouped by day, and a visit order is suggested by distance. The suggestion is not binding; the planner can change the order by hand, because there are always conditions in the field that the system does not know about. When an urgent call comes in, which jobs the plan will push back is visible on the same screen, and after assignment a notification goes to both the technician and the customer.
The technician receives the work order on a phone or tablet. The work done, measurement values, parts used, time spent and photographs are recorded on the device; entries can be made with no internet connection and are synced when the connection returns. Checklists vary by job type; the technician is not left alone with an empty notes field. The application also shows that machine's past service jobs and its technical documentation, so the field does not have to telephone the office.
Every service van is held as a separate stock location. A part leaving the warehouse for a van moves into van stock, and a part used on site is deducted from the work order. Minimum levels are monitored per van for critical parts. The count therefore balances, and buying the same part a second time is prevented. Parts going out to and returning from vans can be counted, any difference is reported and its source can be traced.
Every machine's warranty end date and, where there is one, its maintenance contract are held in the system. As the work order is closed, which item is warranty, which is contract and which is chargeable is determined by rule and recorded with its justification. Arguments about cover therefore move out of memory and onto the record. The total cost of work carried out under warranty is also reported; that figure shows what a given model costs after the sale.
At the end of the job the work carried out and the parts used are shown to the customer on the screen, and the signature is captured on the device. The service report is generated automatically and sent to the customer by e-mail. Waiting for a wet-signed sheet of paper to reach the office is one of the most common reasons invoicing is delayed and collection is pushed back. The signature and the report stay attached to the work order; the content of the report can be defined separately for commissioning, periodic maintenance and breakdowns.
The moment the request was opened, the moment it was assigned, arrival on site and closure are held separately; the committed response and resolution times are measured against them. First-time fix rate, recurring faults and service cost per machine are reported. The reports are set up to be read first by machine and by customer; the aim is not to appraise individuals but to find the recurring problem.
We start the work by following the existing service flow step by step: how the request arrives, who assigns it, what the technician writes, how the part is deducted, how the invoice is raised. At this stage we identify the steps that stay off the record and who is holding which piece of information in their head. Discovery usually takes one to two weeks, and at the end of it the scope is narrowed down together.
The machine records the service will be attached to are created: serial number, model, installation date, warranty end and any contract. In most firms this data is scattered and takes time to pull together; but the rest of the system rests on this foundation, and if it is skipped no report means anything. The data is transferred from the existing ERP and delivery records as far as possible, and the remainder is completed by hand.
The mobile application is first trialled with a limited number of technicians on real jobs. The length of the checklists, the number of mandatory fields and the offline behaviour are tuned during this period. In the field, any screen that takes longer than a minute is a reason for the technician to abandon the system. This pilot period usually lasts four to eight weeks, and the real design decisions are made here.
Van stock, part deductions, warranty cover rules and the handover to invoicing go live. Integration with the accounting or ERP side is built at this step; which item is charged under which conditions is clarified in writing. Labour, travel and price lists are also defined; this is what shortens the time it takes for a service job to turn into an invoice.
The whole team moves onto the system; SLA and service reports are opened up. In the early period the fields that are left incomplete and the screens that are not actually used are reviewed together and simplified. Who uses which screen in which situation is left in writing, and the reports are read together in the first months. Updates continue under maintenance and support, and the source code is handed over to you.
Usability here is a matter of design, not a matter of training. We build the application around the technician's daily work: their list opens at the start of the day, they enter a job, fill in a few fields, take the signature and close it. Selection fields and checklists are used instead of free text. Even so, let us be realistic; getting used to it takes a few weeks, and during that period the office must not run the old method in parallel. If two systems stay open at the same time, the field will always choose the easy one — the paper.
The mobile side is built offline-first. Work orders assigned to the technician, machine history and the parts list are downloaded to the device; entries, photographs and signatures made in the field are stored on the device and synced to the server when the connection returns. If the office has changed the same record as well, conflict rules come into play and the record is not silently overwritten. Against that, operations that need the server — such as a real-time stock check — cannot be carried out while offline; those are verified after syncing.
Partly. Grouping jobs in the same region and suggesting a visit order by distance reduces wasted travel; you can measure that. But the system does not solve traffic, a customer keeping you waiting at the gate, a second trip caused by a wrong diagnosis, or the part not being in the van. What raises the first-time fix rate is usually not the routing algorithm but the technician seeing the machine's history and taking the right part along. We would advise treating proposals that present optimisation as an extravagant promise with caution.
No, that is outside the scope of this page. Field service management is concerned with running a service job from request through to invoice; monitoring the condition of a machine at the customer's site with sensors and generating a pre-failure warning is a separate job, described on the predictive maintenance page. If you want to manage the maintenance of the machines in your own plant, the right place is not field service either but the maintenance side. The two systems can be connected to each other; but they are not the same thing, and presenting them as a single module is misleading.
No. Systems such as Logo, Mikro, Netsis or Canias — the ERP and accounting packages widely used in Türkiye — stay where they are. The field service layer works alongside them: customer accounts and stock cards are read from the main system, and the invoiceable items and part movements coming out of the work order are transferred back to it. Our aim is not to move your accounting but to put on record the service data that is held in no system today, and to remove the manual data entry between the two sides.
Service history and warranty information per machine; a service record that runs from request to closure; mobile work orders that work offline, with digital signature; service van stock with part deductions; warranty and contract cover rules; reports on response times, first-time fix rate and service cost per machine. Everything, including the source code, the database and all the service data that accumulates, belongs to you.
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
We establish from one place which version of a technical drawing, CAD file, recipe or sample record is the valid one. PDM manages the file and its revisions; PLM extends that across the product's whole life, from idea to serial production, together with change approvals. Whether the drawing that reaches the shop floor is the right drawing stops being a matter for debate.
Details →We take buildings, floors, rooms and desks into a single inventory, and run lease and subscription contract dates, planned building maintenance and the inspection schedule for fire and safety equipment in the same system. The cost of running the facility thus becomes visible by building and by area.
Details →We build a human resources layer that brings employee records, documents, leave and absence, the organisation chart and employee self-service together in a single record. It does not replace payroll; it prepares the data that goes to payroll accurately and traceably, and it connects to the timekeeping and PDKS (time and attendance) side through the same employee record.
Details →We build a system that runs the whole candidate process in a single flow, from drafting the job ad through to the offer and the handover to onboarding. Whichever channel applications arrive through, they collect in a searchable pool, assessments are written on a shared form, and retention periods and data destruction are put on record.
Details →We give every rack and bin in your warehouse an address and record every movement by barcode. From goods receipt to put-away, from pick routing to dispatch checks, the flow runs on handheld terminals; underneath the quantity figure in your ERP we add the physical location of the goods and who moved them, and when.
Details →We capture incoming, in-process and final inspection records on a tablet on the shop floor; when a non-conformance appears we quarantine the goods, start the corrective and preventive action (DÖF / CAPA) flow and follow it through to closure. Measurements, certificates and approvals accumulate by batch, so you go into an ISO 9001 audit with a file that is already prepared rather than one assembled retrospectively from binders.
Details →
