recent Field Service Management news

A global marking and printing specialist, Markem-Imaje, has increased their lead generation by 60% and decreased on-site customer service appointment times by 20% by adopting field service management software.

Predictive maintenance involves using artificial intelligence to crunch the numbers on already-examined assets in order to predict future work needed. The medical equipment manufacturer Medivators uses predictive maintenance in its service management software to order checkups on equipment before it is predicted to fail, reducing service events by 78%.

Augmented Reality is making its way into field service management. mCloud Corp, an asset management company, integrates augmented reality glasses with its field service engineer software to help the engineers work on assets they may be unfamiliar with. The glasses include cameras which allow remote experts on the assets to provide advice if needed.

using the FieldMotion API for your own project

We sometimes have customers who ask if they can link to FieldMotion so their internal systems can be updated automatically. If it’s something very common, then we might already have that built into our Zapier plugin, but if they’re looking for a more indepth connection, we ask them to use our API.

An API (Application Programmer Interface) is a way for one program to speak to another program. Every large company has one. Google, Facebook, Amazon, EBay. If a field service management software company doesn’t have an API, you need to think twice – one of the points of using an online service is that it is more efficient than using pen and paper, but if efficiency is important, then surely it’s important that you can get your online service to speak directly to your accounts or other internal services?

Two of the more common uses for the API with our own field service engineer software clients are to connect to accounts such as Sage, or Opera. It’s impossible for FieldMotion, or any other cloud-based workflow software, to speak directly to those account packages because they are not online. You cannot speak to them over the Internet. This is why accounting software such as Xero is so popular today, because you can access Xero online, and therefore you can easily link to it without needing custom-written code. We link directly to Xero, for example, but we don’t link directly to Sage.

But, if you did want to link directly to something (Sage, etc) that is not online, then here’s how you do it.

Firstly, you need to hire a programmer, or contract a programming company to do the work for you. They need to create a program that runs on the same computer as the offline service you want to link to.

There are many ways that the program itself can be built, but probably the simplest is to simply create a periodic synchroniser. Every half an hour (for example), it will check the Sage database to see if there is something new to upload to FieldMotion, and it will also check FieldMotion to see if there is anything new to download from that to Sage.

Of course, the devil is in the details, but we’re here to help. If you decide you want to go this route and want to link your accounts packages with FieldMotion, please contact us and we’ll help you, by either talking with your programmer, or by putting you in contact with others that have already done this, so you can benefit from their work.

APIs are incredibly important. If you are working with workflow management software, one of your main purposes is to try and automate away anything that might normally need to be done manually.

field service software for fire and security

Fire and security inspections are hard work. Everyone we’ve dealt with had the same problem – they would do the inspection, which might take only a few hours, but then the tedious work happens – hours and hours of documentation. Of all the field service management industries we’ve addressed, fire and security inspections appear to have the longest reports.

One of our clients told us that he would regularly be up almost to midnight writing documentation for an inspection he finished around noon.

We worked closely with that client to determine exactly how his reports are put together, and worked up a field service management system solution for him. He now finishes his inspection the same as usual, and by the time he gets back to the office, the report is already generated and ready for him to adjust if needed (for personal touches) and send off to the customer.

Inspections generally involve photographs, lots of report sections depending on what’s found at the inspected area, and finally the customer’s signatures.

If the inspector were to fill out a form that had every possible question on it, then the form would be even worse than just writing it by hand. Instead, we use skip logic so that if a question needs further information (for example, if compressed gas cylinders are on-site, there would be a section questioning how they are stored), we show that section, but if there is no need for the questions, they simply don’t appear.

This way, the inspector fills out a form which contains exactly the questions needed answering, saving time.

After completion of the form, we can set up automated workflow management triggers based on the answers. For example, if the answers suggested that safety was inadequate, then a further inspection may be needed in a few weeks to determine if any progress has been made to address the problems identified.

Scaling up in field service management software

Every now and then, we have a client ask us whether it’s possible that we could just install our field service management software in their datacentre (or even their office). At one time, about five years ago, we might have been able to say “Yes” to that, but the system is now so large that it’s impossible to stick it all on one machine easily (if at all!).

The reason has to do with “scalability“. As more clients are taken on board, the number of people using the system at any given moment increases. It’s a constantly increasing pressure on the system. If we have just one server running everything, then that server is under a constant barrage of requests from people.

Let’s say we need to upgrade that server. Let’s say, for example, that we think it needs more RAM to handle the amount of things it is doing at any one moment. In order to do this, we need to take the server offline, put the new RAM in, and put it back online.

There are two obvious issues here: if you take the server offline, then everyone that is trying to use the server is also taken offline, and if your field service management company needs constant and timely updates, then this must absolutely not happen. And, there is a limit to how much RAM you can add to a server anyway. You can’t just keep adding forever!

This kind of scaling, where you increase the resources (RAM, storage, CPU) on a server, is called “vertical scaling“, and it has limits. eg: the maximum RAM you can easily put in a server (depending on the server) is about 64GB. After that, what do you do?

Instead, we use an architecture called “horizontal scaling”. With this, if you have a server that is running out of resources, then add another server.

In the beginning, as I said, we were on a single server, while we were getting the fundamentals built and figuring out what needed to be done to stretch our wings. The first decision in stepping into horizontal scaling is the figure out what you can separate out from the monolithic block of code. What makes sense to have on its own somewhere else?

Field worker software is the same as all other software – it has a logic part and a data part. It’s very easy to move a database off one server and onto another, and some databases even have at least some form of horizontal scaling built in.

MySQL, for example, which we use for some of our data, can be spread out in a “master/slave” topology, where one or more databases act as the “master” databases (you write to them), and then a group of others act as “slave” databases (they copy data from the masters, and you read from these). This is a good step towards horizontal scaling, but not perfect, because there is still some human intervention needed at times in order to set up the servers and tune them so they share fairly. With MySQL, scaling is a combination of vertical and horizontal. To add more storage, you need to add storage to each server in the cluster (unless you have set up “sharding”), and to let the cluster handle more connections easier, you need to add more slave servers.

CockroachDB (CRDB) is another database system that we are looking at which has horizontal scaling built right into it from the beginning. With CRDB, if you find you need to scale, either storage-wise or speed-wise, you simply add another server to the cluster. It’s not compatible with MySQL, though, so you can’t simply drop one and use the other.

We also use MongoDB with our field service engineer software, which is a “NoSQL” database. We use that for storing files which need to be accessible on multiple servers. MongoDB handles horizontal scaling very well, using an architecture called a “replicated sharded cluster“. Basically, it splits large files apart into smaller chunks, and makes multiple copies (three is the recommended minimum) which it keeps in replica sets. The sharding and replicating is completely automatic once set up, and if something goes wrong reading any chunk, then the system automatically figures out where it can get a working copy. This works well. Recently, our hosting provider had an issue with power supplies in a datacentre and a load of servers went down, but because of how we spread our system across multiple datacentres (and countries), this had absolutely no effect on our clients at all. No-one noticed but the dev team who were monitoring everything.

After the database, the application itself is examined, and broken down conceptually into discrete units. The simplest example in a field service management system is that there is a part of the system which the mobile devices talk to, there is the customer relationship manager section, and there are the various report generators, emailers, etc. Each of these can be carefully separated from the main monolithic block and put onto its own server.

To separate out the mobile-facing part of the application, for example, we made a copy of the main application that we then called the “mobile server”, changed the mobile device code so it spoke to the mobile server and not the main server, we made sure that everything that gets sent to the mobile server (data, files) is available on the main server transparently and immediately, and then we simply removed all the code on the mobile server that wasn’t strictly about handling mobile app requests. When we repeated this on the main server (removing all the mobile app request handling code), we now had two separate servers, each performing distinct services, and each of them requiring less resources to stay fast and user-friendly.

There is the added bonus that when you break a monolith apart into its logical sectors, new developers don’t need to learn the entire system – they can just learn the part you put them on. In FieldMotion, our developers all have overlapping spheres of knowledge, so that if there is a question and I’m not around, then /someone/ will know the answer.

Another thing to be careful of is to make sure that when you break a system down to its parts, you are doing it in such a way that the new standalone services can be replicated. For example, we try to have at least three of everything, so if someone tries to access a server and it’s down or slow, then a backup server is ready to take up the slack. It’s not just databases that need redundancy. You need a few of everything.

how we got into field service management

FieldMotion started out (under a different name) as simply a way to record and upload forms on the phone. I was asked in 2012 or so to build a simple piece of software that could do this, and quoted a measly few hundred euro for the job. We laugh about that now, as the job grew and grew as its potential become obvious. What we have now, I couldn’t put a price on.

I was asked to make it so that we could have different kinds of forms in the app for different job types. If I stuck literally to the letter of the request, I would have simply hard-coded the requested forms and moved onto my next client. But, instead, I noted that if there are two different forms requested now, there might at some point be a third or fourth, so I might as well save some time now and just write up a form generator instead, to let the clients design their own forms.

When I showed this to Jerome (FieldMotion director who hired me for the job), it suddenly opened a load of new possibilities. He didn’t realise I could do something like that. He asked me “what else can you do?”. I said I could do pretty much anything at all – if you’ve seen it done online, I can do it.

We didn’t realise in the beginning how big the field service management industry is. We didn’t even realise that was what we were entering. We were simply responding to whatever the clients needed. The first client we had was actually a mobile phone sales company owned by Jerome’s brother, so we wrote some of the early customer relationship management code and stock code as if it were for phone sales.

But, I’ve always had the opinion that if you write anything at all, it must be written as generically as possible. Whatever you create must be good for your current customer, but should also be flexible enough that it doesn’t need much tweaking for the next customer. I learned that while building content management systems (CMS) in the early 00s. There’s no point writing three systems for three customers when you can write one system that can be configured for all three.

Another thing that helped us greatly was that I built the system as a “multi-tenanted architecture”. This means there was one software installation, and multiple clients using it. This is the same approach used by “cloud software” these days, and I’d been using the method since about 2005 or so with my CMS engines. I did a talk at Google in 2011 about my approach (slideshow is here).

Multi-tenanted systems allow you to easily update many clients at the same time. The older approach was to have one software installation per client. Like how with WordPress, the usual method of installation is to download and install for a specific client. But, if you have 200 clients and you find that you need to upgrade them all, which is better – one installation per client, or one overall installation that they all run through? Obviously, it’s best to have one large multi-tenanted installation. Speaking of WordPress, Donncha O Caoimh was writing the multi-tenanted version of WordPress around the same time was I was working on my own multi-tenanted CMS. We helped each other out at some points to get things up and running. I think we ended up basically using the same methods.

The next tricky part involved how to make it really really smooth for people to get information back from the app to the servers. When you write something for people that are not computer geeks, you need to get rid of anything that might be confusing. I try to keep things as simple as possible for people so that they don’t need to ask me questions and I don’t need to repeat the answers. There was a choice between making the app transparently push data to and from the server, or restrict it so that the user had to deliberately synchronise their apps in order to keep up to date.

From the software point of view, the simplest method was to require a manual sync. But it was much more important that the user doesn’t need to do anything other than simply fill in the forms. If they have to remember to check for signal and click an actual sync button every few hours, then two many people will simply forget and then blame us when their forms are not uploaded and sent to the customers. So, we try to keep it as absolutely simple as possible for the clients.

The method we chose was to have the app “poll” the server periodically, looking for any new information, or pushing any stuff that’s been updated on the app. It was very very complicated stuff, and I’m not going to write about it here other than to say that it took months to get it right, and I’m glad it’s all behind me 😉

I had written an app before all this for a windmill servicing company. They chose to use a manual synchronisation method instead. It meant that the engineers needed extra training specifically on how to use the app itself. We didn’t want to force anything extra on the clients in our new field services management system, though, so we took the time to make sure it was robust, seamless, and invisible to the user. As far as our clients are concerned – jobs just appear on their devices, they just fill them in. That’s all.

We built a customer relationship manager (CRM) very early on, because our main client at the time (Jerome’s brother’s company) was very big into sales. This turned out to be a very good thing, as we built some things into it (callbacks, notes, custom fields) that would not have occurred to us if we’d just listened to the smaller companies. As we expanded, we were able to show new clients the tricks we’d built, and a lot of those tricks were useful in helping them expand their own work. Callback reminders, for instance, are a very obvious thing in hindsight, but when you start up a company and get a client, it’s not always obvious to you that you should call that client back a few months after you’re done with their jobs, to see how they’re doing. And if you have hundreds of clients, it’s best to have some software remind you to make the call. Otherwise you’ll forget and miss out on some new work!

The next big things were skip logic and workflow. We’d been looking at some features of other FSMs (field service management software) and more general service management software for a while, trying to decide what tricks to expand into, but we didn’t want to simply copy any other particular system. We wanted to grow according to demand and be innovative ourselves. But as our customer base grew, it became obvious which new features we needed to add.

Skip logic is used in questionnaire-type forms to “skip” over blocks of questions that are not needed. For example, if you are filling in a vehicle-check form that asks whether there was damage to the passenger side cab door, and you answer “No”, then the skip logic code should hide the “Please describe the damage” question that might follow that.

Workflow is what happens when the job is finished – is there a new job to be created? Should emails be sent off anywhere? Workflow management involves setting up what to do next after you finish each job. We created an “onComplete” workflow software system that could manage logic flows and set up sequences of events. We expanded that so that after any job was finished, we could have other jobs (of any type, for any user) be created, and have the filled-in data from this one pass through to the new ones.

There is a lot in the system that I haven’t mentioned. I just wanted to give an idea of how we’ve kind of organically grew to where we are.

You can see from all of this that we’ve been growing in a customer-directed fashion. As the market dictates, basically. The strange thing is that even when we think we’ve got the full system and better stop developing and start tidying up, we seem to “accidentally” develop some new awesome part of the system, and suddenly the market expands again. Last year, the new awesome thing was our dynamic scheduler (a multi-vehicle routing system which is really easy to use). This year, I think we have a really amazing one that I’ve never seen done anywhere else at all. I’ll not get into detail yet, but we will very soon be able to give our clients lists of potential new customers, based on who they’ve managed to sell to in the past. It’s based on some artificial intelligence work I wrote for ourselves, that we realised would be easy to make usable by our own customers as well.

Every year brings something new! I’m always excited in this job.

Artificial Intelligence in Field Service Management Software

A recent news article discussed how ServiceMax is using AI in their own software, but didn’t go very much in-depth into what’s being done.

In FieldMotion, we use artificial intelligence in many areas, from the obvious ones such as real-time voice recognition in text entry fields, to less obvious areas such as optical character recognition when analysing uploaded forms. It’s surprising how much AI there is in service management software.

We are always looking for ways to reduce the amount of work that you need to do.

When creating forms, you can upload your own printed forms in PDF or image format, and the system will “read” the image, pulling out any text it finds to create fields for you, so you don’t have to type everything in.

When filling in your forms on your app, you can click the voice recognition button in your field service engineer software to simply speak into your phone or tablet. It will convert to text for you.

When positioning a field into your form reports, you can simply click on an empty space in the form and FieldMotion will figure out the right size the field should be in order to fit into where you clicked.

In the timeline view, if you have Dynamic Scheduling enabled, the system can automatically schedule hundreds of jobs for many people, taking into account travel time, costs, types of jobs and skills needed.

Behind the scenes, we’re always working on new tricks as well. I just finished one over the weekend for ourselves where we can enter a potential client’s website into an AI engine, and it will return a percentage “match” for our product based on whether other companies with similar websites use FieldMotion. When I described what I was doing to a cognitive neuroscientist friend, he said “If you wanted to take it further (way too far, probably), you could treat current customer website lexicons as a training set, and use machine learning to categorize the probability of other websites being a customer.” – it’s like he was reading my mind, as that’s exactly how I wrote it!

We’re also working on a sales prediction system where a sales-person can say that a quote is “hot” or “cold”, and the system will assign a percentage chance of successful sale based on the sales-person’s history of getting it right or wrong. This allows a more accurate budget forecast.

FieldMotion uses many different types of artificial intelligence and machine learning in its field service software, and we’re always looking for new ways to improve your work.

At its simplest, we offer workflow management and skip logic, but you can see that there’s a lot going on that you may not be aware of!

Talk to us and we’ll help you optimise your business.

Zapier integration coming to FieldMotion

One of the questions we are asked a lot when talking with clients is, “Does your service management software integrate with […]”, followed by any number of different software products, such as Quickbooks, Opera, Sage, Xero, Google Calendar, etc.

Instead of spending decades and linking individually to each of these, we decided to use the ready-made API hub Zapier. With Zapier, you can connect any of more than 750 different applications together with almost no technical knowledge at all. It’s really very simple! More than 1,000,000 people use Zapier.

We’ve looked through their app-list a few times, and as far as we know, we’re the only field service management software using Zapier. There are some project management, task management, and paperless forms systems in there, such as Trello or Asana, but no other field service engineer software.

To start off with the integration, we’re doing some very simple workflow – when you create a job in FieldMotion, you can (for example) have that job show up in Google Calendar. Or you can have that when a job is finished, an email is sent including details from the job.

For now, our Zapier plugin is beta-only. If you’re interested in trying it out, please contact us and we’ll help get you set up.

Zapier is actually an ideal match for us, because it’s all about workflow management, as is our own product! We’re really excited to get this out there and see what we can do with it.

Workflow management

In the service industries, workflow management involves setting up a flow from job to job based on overall plans, or whatever was discovered during each step.

The simplest example might be a flow where one type of job is always followed by another. For example, when a pipe needs to be laid in the ground, the flow will involve planners getting permission from various authorities, followed by diggers creating a trench and shoring it, followed by the installation of the pipe, then the joining of the pipe to the existing network, filling in the trench, and then resurfacing.
Each of these steps might involve a different team. FieldMotion’s field service software lets you create a sequence of jobs by using forms that, on-complete, create follow-on jobs set to start either immediately, or you can even set a delay in cases where you may need to allow time for settling or drying, etc.

A more complex example might be one where the follow-up jobs might be different depending on the conditions found during the current job.
The pipe-laying sequence, for example, might also take account of what to do if the trench-diggers uncover pre-existing wires or pipes. Obviously, that would affect the sequence of jobs, so a new follow-up job (investigation) would need to be dynamically created based on the discovery.
FieldMotion lets you create workflow logic based on data recorded in the job. This is especially useful for cases where some decision-making is possible based on exact numbers entered. For example, in the case of medical checkups, you may want a doctor to be booked automatically if the checkup notes a too-low (or too-high) blood pressure.

Sometimes even the job itself might change mid-job based on what data is entered. Consider the case of a form you are filling which asks for the details of three objects that are on-site. You fill in object one, and object two, but there is no third. Well, the form might have a clause for this, where you answer “Is the third object available for inspection” with “no”, and this automatically replaces the followup questions with different questions asking why the object is not there, or maybe it just skips on ahead to the next section altogether.

We call that kind of workflow “skip logic”, but it’s really just a small version of the larger jobs-based system of managing workflow.

The point of all of this is to reduce the administration needed on-the-job. Your field workers don’t need to be trained how to decide what course of action to take next if the system knows how to do it itself. Field service engineer software such as FieldMotion can dynamically assign work as existing job orders are completed.

If you’d like to talk to FieldMotion (one of the largest UK service management software companies!) about how we can help you with your own field service workflow, please contact us. Here are some field service management software reviews of us (Capterra, Finances Online) that you might read to help you decide.

Job-scheduling in the field with FieldMotion

As companies get larger, the jobs become more specialised. The person who used to do accounting and data entry now has someone to do data entry so can concentrate on accounting. The field worker who had to make on-the-spot decisions as well as carry out the jobs, is now a manager in charge of a team of specialised electricians, plumbers and whatever else is needed.

As the teams grow, you find that more decisions are being made back at headquarters based on findings made by the workers in the field, because there are too many workers to let them just decide for themselves and potentially get in each others way.

Example 1: availability-based job scheduling

As an example, let’s say you’re working on a job that involves doing plumbing and electrics. The team of diggers has finished up and the work area is ready for whoever’s next. Maybe the electricians are busy already? Or maybe the plumbers need to be somewhere in 5 hours so need to be first here?

With smaller teams, the managers might meet up and decide, taking time. With larger teams, you might have a site manager whose job is to make these decisions.

Why not just let FieldMotion decide? If you manage your jobs through our FSM (field service management software), then it already knows that the plumbers are due somewhere else, or that the electricians are busy. There is no need for a meeting between the managers. Using the FieldMotion Dynamic Scheduler, you can automatically order your jobs in such a way that everyone has time to do their jobs, with no clashes in schedule, no teams due on the other side of the country five minutes after finishing this one.

Example 2: decision-based job scheduling

Or let’s say that the job you’re doing involves making decisions based on the findings you make in the field. For example, let’s say your company does health-checks on house-bound people, and the decisions you make after these checks depend on what you find while doing your inspections.

You could hire a person and train them up to make qualified decisions on whether to bring in a doctor or optician. Or you could hire a person who just fills in forms and those forms are then read by a person who is trained to make the decisions. Obviously, it is more economical to train (and pay) 10 form-fillers and 1 decision-maker, than to train 10 field-based decision-makers.

But why are you paying for a decision-maker in the first place? If the decisions are based on simple rules (such as “how high is the blood pressure”, or “has the patient fallen recently”), then you don’t need a paid decision-maker for that. Just add the rules to the “on-complete” section of the form that’s filled out in the field worker software, and FieldMotion will make the decision automatically and book a doctor or optician for you immediately, and a recall visit will be created in a few weeks or months depending on the patient’s age or health.

If all decisions are based on simple rules, then you don’t need to train someone up to waste their time doing it – just let a computer do it for you, leaving you more time to go visit more patients.

Customer Spotlight: Heyn Engineering Solutions

About our company

Heyn Engineering Solutions offers a comprehensive range of materials handling solutions to leading industrial, manufacturing and warehousing sectors in the UK and Ireland. A complete service is provided from assessment and design to the installation, testing, training and maintenance of all solutions.

Heyn are representatives in Ireland for a number of leading manufacturers including Demag Cranes & Components, SEW Eurodrive Drives & Geared Motors, Reid Lifting Equipment and Tractel Lifting & Moving Solutions. These relationships are built on a mutual reputation for high quality performance and service excellence.

Heyn Engineering Solutions has broadened its services from Cranes, Hoists & Drives

  • Lifting Equipment and Accessories
  • Tractel Safety Components
  • Machine Moving, Service and Maintenance
  • Equipment Examination and Inspection (LOLER and PUWER)
  • Ship Management and Repair
  • Heyn Engineering Solution have a team of highly skilled consultants and industry-qualified engineers who receive regular product and service training. All services are carried out in compliance with today’s quality standards, using field service management software to record all jobs in real-time.

    My position in the company

    Kevin Denvir is Director of Engineering for Heyn Handling Solutions. Responsible for high level management of the division and all staff and processes that sit within the Engineering division and provides overall direction to work towards the company’s strategic objectives.

    What are the problems that Fieldmotion was brought in to fix?

    Fieldmotion was implemented to replace work books being completed by engineers on site. Naturally it took some time to have these copies returned to the office, copies could get lost or writing was unclear. This increased time taken for parts ordering, diary management and then in turn impacted upon invoicing and debtor days.

    How has Fieldmotion affected your business since you started using it?

    Fieldmotion has helped to transform our processes in the Engineering division. It has provided a platform to co-ordinate our engineers and receive real-time feedback on each of their jobs. This has improved our processes for parts provision, engineering diary management, it has helped to speed up invoicing and improve on the number of days it takes for customers to pay. Overall, we have not looked back since starting to use Fieldmotion and have recently implemented the platform in other areas of the business.

    If you could put a number on it. How many hours/person/week have you saved by switching to Fieldmotion?

    Heyn Engineering have used Fieldmotion as the basis for job management and reporting on a recently awarded contract with NI Water. Since the start of this contract we believe Fieldmotion has saved us approximately 15 mins per item, equating to 300 hours per month on average.

    Do you think that Fieldmotion software will help your company take on more work?

    Fieldmotion has already allowed us to implement a recent large contract with NI Water smoothly and effectively and has been vital in allowing our administration staff working on this contract to provide reports within the timeframes outlined in the contract. I have no doubt that Fieldmotion will continue to become an integral part of Heyn Engineering processes and will help us to provided added value to our current customer base and also attract new business.