the best field service management software! and other news

While reading up on the news today in the field service industry, I found yet another example of a field services management company which is just one of many similar companies, claiming to be the “leading” company in the industry. They get away with this because “leading” doesn’t really mean anything measurable when used in that context. See for yourself. A search for “leading field service management” mentions at least 5 different companies on the first page alone. We can’t all be leaders! Personally, I believe FieldMotion deserves to be called the leading field service management because it simply is the best. Hands down. Of course, I’m biased, and “the best” is not measurable either without context, let’s be honest!

So back to the regular news, then.

An opinion piece by George Malim on Vanilla+ suggests that customer service providers in the telecoms industry are using service management software now to improve their response times to issues, which in turn helps them to improve their customer ratings and their income. In Malim’s words, “We estimate that a ten-minute reduction on each job would increase service capacity by 50,000 jobs a month and earn a potential £6m in additional revenue a year.”

Field service software is not just for the industrial sectors. Even retail sector companies are finding that they need field service management software, as shown by this article by Aneesh Reddy which talks about effective sales and brand-building. In it, he says “led by evolution, retailers are using software like field service management for before-time workforce scheduling. They are also using route optimization software for swift delivery”. Hey, we do all that!

Finally this week, the Computer Business Review was at the Knowledge 17 conference in Orlando, US, where they reported on recent developments in field service management systems and workflow management (they called it “routing work”). They found the recent addition of Dynamic Scheduling to one product to be very interesting. We demoed our own dynamic scheduler last year at a conference, so I was very interested to compare the two. Ours schedules based on the job time, location, skills required, and the engineer’s daily work hours.

managing assets with FieldMotion’s field service management software

Most of the clients that come to us are in service management of some sort or another. In the beginning, our largest clients were in housing management, where workers would be assigned to go check on customer complaints such as broken doors, faulty boilers, etc. Lately, though, we get a lot of companies that work on assets and need to manage those assets.

In a pure forms-based service management software, there is no real “memory” between jobs. You are assigned to something, you go do it, you fill in the form, you are done. But if you are assigned to go check an asset that you’ve already checked at some point before, it would be great if the details of that asset were already filled in, and you just needed to check them over.

We manage this in a number of ways. The first time you go out to a client, you might need to select the asset in your field service software, by either selecting it from a list, or by using the phone or tablet’s barcode scanner to select the asset. As soon as the asset is selected, its details are downloaded (if not already on the device), and filled into the required fields in the form.

If the visit is a follow up (for example, after completion, the workflow management logic creates another job for that customer/asset 6 months down the line), then the job’s form can already have the list of present assets filled in, including their details, so you just need to look them over. Managing workflow means less work!

This is useful for things such as F Gas registering, or keeping track of wear and tear on assets that may change over time.

Using the power of workflow software means that there is less overall management as well. Based on the values you record, FieldMotion can automatically create new jobs to be done. For example, if an automated mathematical calculation in the form says that a certain asset’s safety is too low, you can book maintenance or replacement.

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.