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.