Adding more field-based autonomy to the app

Generally, the way that service management software works is that you have an office-based staff which handles the apportioning of the jobs, and the field workers go out and handle those jobs.

In some of our clients’ cases, they like to do it all out on-location. This involves bringing a laptop, because the CRM part of our system can be too large and complicated to work with on a phone.

Last week, we added the ability to put stock items directly into form subtables, so you could say where exactly the stock was used, instead of attaching it generally to the job itself.

This week, we did the same for the schedule of rates.

We think this is leading in a “bottom up” way towards being able to quote and order a job completely from the field on a phone. We just need to make sure this all links into the financial database parts of the system properly, and then we’ll be happy to call that a complete feature.

A step beyond that would then to be able to send an invoice directly from the app and have the client pay it via a payment system such as Paypal or Stripe. One of our juniors is currently looking into that at the moment, but I would not expect it to become an actual thing until early next year.

This is all leading towards being able to administer a large part of the system as a paperless office solution from the field itself, so the workflow management system handles as much as possible automatically, there is very little to do manually, and that little can be handled on your tablet or phone.

We already have at least one company where all jobs and customers are created by a team lead who is out in the field himself. He creates the jobs and customers on the field worker software in his phone, then he reassigns the jobs to specific members of his team.

It’s not a big step to prefix all of that with quote generation, where the quote can create an invoice through Paypal/Stripe, and a job is then created from the quote, either manually (where you get the go-ahead and want to just start working), or after payment (one of our clients would like to get paid before doing the work).

It’s all interesting work. We enjoy throwing new features in, then seeing how our users find ways to make use of them. The aim is to make FieldMotion into simple workflow software that has as much automated away as possible so you only need to use a minimal interface (like on a phone).

This ability to flexibly add new small features that may not have been part of the “grand plan” years go, without needing to rebuild from scratch, is part of the reason FieldMotion is the best workflow management software. When adding new bits and pieces, we always try to think of how this might need to change in the future. For example, we mention PayPal and Stripe, to make sure that when we write that bit, we don’t just hard-code a single solution in and make it difficult to stretch it later. We intentionally try to make the code accommodate much more than it currently can, so we can easily add new features later on that we haven’t thought of already.

In a way, it’s a living version of Donald Knuth’s famous saying “premature optimisation is the root of all evil”. If you write your software as if the plan the bosses came up with years ago is the absolute correct and only way the software should run, then you risk making it impossible to change later when it becomes obvious there are new features needed.

We originally planned the system so that jobs are created in the office, and the app is just for filling in the forms. But, we wrote the code such that this was not set in stone.

In fact, this flexible approach is the very reason FieldMotion exists at all in the first place. When I was hired to make the first version of the system, there were 2 or 3 specific forms for mobile devices that needed to be filled by the mobile workers. I could have just hard-coded those forms and then gone onto my next job. Instead, I made it possible to customise and create your own forms, and FieldMotion was born. We are now the best field service management software in the UK, and working on being the best in the world.

FieldMotion: the book of the system

I’ve been tasked with writing a book about this field service management system thing that we built. Most of the books I’ve written have been code-related and general in nature. Writing a specific “how to” of a single system will be a bit more challenging. Especially as the system we have is really so large that condensing it all into one book will probably make the book wither much too long to read, or much too dense to read.

So, I think the best thing to do is to write a general overview of the various parts within the system, and how to use them from a basic point of view. I will intentionally avoid detailing the use of the more complex parts of the workflow management software, and will return to those either in later chapters, or in follow-up books.

Why write a book?

I’m a big fan of written tutorials. I would much rather read instructions on paper than watch a video. Printed instructions and explanations can get a lot more in-depth than videos. Also, it’s easier to highlight lines in a book, or refer back to earlier pages.

Videos tend to have accents as well. Even within the single English language, there is enough disparity in accents that it can be hard for a person in the US to understand someone with a Scottish accent (for example). Written text does not have accents.

It’s also easier to translate a book than a video. With a book, it’s a simple matter of having the text translated by a technical writer. With video, though, the entire thing must be re-done.

I will be publishing the book in this blog as I write it.

When I wrote my other technical books, I stuck to a general prescribed format – about 13-14 chapters per book, each book should be 15-20 pages long, and all concepts should be presented with visual diagrams if possible. I’ll do the same here.

Proposed chapter list:

  1. Introduction to FieldMotion
  2. General Usage
  3. Customers
  4. Jobs
  5. Assets
  6. Stock
  7. Using OnCompletes to setup WorkFlow
  8. Financial Reports
  9. Dynamic Scheduling
  10. Recurring Jobs
  11. Outsourcing Jobs
  12. Linking to Xero
  13. Using FieldMotion with Zapier

After completion, we hope to give out electronic copies of the book for free to people that ask us for a demo of our job scheduling software, and will give a free printed copy to all new customers.

stages of release in FieldMotion

I wanted to talk about how why FieldMotion’s software process makes us one of the most robust and reliable field service management software companies on the market.

Startup companies race to complete features and ship them as soon as possible. We don’t do that, because we are aware that new features are never right. There is always a period of tweaking after a release to match what we built, to how people are actually using it.

How we work is that the development team will have a list of big projects to do, which they’ll work on for a few months. Each of the projects appear to naturally come to a close near six months into development, so we’ll tidy up all the new projects and announce them all as a new release.

The current release candidate will be our tenth official release since we started about 5 years ago, and will have three major products in it: a stronger Dynamic Scheduler (route optimisation for multiple vehicles, departments, etc), strong Xero integration (both Public and Private API versions), and a new Purchase Orders system.

We’ve already planned out the bones of what’s coming for the next six months after this, and we think it will be our biggest and most important release; not because of new products in it (we’re thinking Quickbooks, and multiple languages, for a start), but because we’re mostly dedicating our development resources into making sure the system is scalable (we want millions of people using it), fast even with all those users, never goes down for any reason, and is so simple to use that you’ll wonder why we bother making tutorial videos!

We’re already at the stage where most parts of the system are redundant, so if a server or two (or even a full datacentre – hello Digital Ocean San Francisco I’m looking at you…) goes offline for a while, we can reroute people to different areas that are still up and running. In most cases, there won’t even be a pause (like when SF went offline, and there wasn’t even moment where anyone noticed but our development team), but sometimes we will have short period where parts of the system are offline.

In our own case, how it usually happens is that we’ll see an issue, we’ll solve it in a quick way that’s not perfect but gets the job done for now, and then we’ll solve it in a more permanent way that takes longer but is more robust.

Yesterday, for example, we had an issue where people logging into one particular server in our network were experiencing a large delay in their requests. We looked at this, couldn’t see the immediate cause, and figured the best thing to do at that moment was to increase memory and CPU (we multiplied the number of CPUs by 4, and the amount of RAM by 16 – hey, go big or go home!) to see if that fixed the immediate issue. It did, forcing people using that server (some customer relationship management software users, no mobile workers) to log in again, which was a price that had to be paid at that time to get the problem solved. The more permanent solution in this case is that over the next six month development period, we will be tearing that server type apart into separate “microarchitecture” pieces that can be managed separately, and making sure that each of those new pieces can be turned on/off without affecting people that are logged in. Obviously, this will take time to plan and build, so the quick solution (throw more memory and CPU at it!) was the right answer in the mean time.

Yesterday’s issue took that particular server offline for three minutes (I was timing it) while we upgraded it. Three minutes is better than how long Google Drive was out last week, or how long the entire country of Japan was offline for on August 25th (thanks again, Google), or how Melbourne’s train network was shut-down for hours on July 13th.

We’re at that stage in a company’s life where we’re pretty happy that we have the product we need, and that there is no need to keep on adding more and more and more shiny stuff to it, which is why we’re happy now to spend the next 6 months or more just making sure it is the absolute strongest, fastest, most reliable, and best all-round cloud field service management software.

Field Service Scheduling Software

Scheduling is a big part of field service.

When a boiler is inspected, you may want to schedule a maintenance visit in six months or a year. If you are doing a health checkup on a patient and all is well, you might schedule the next checkup for a year from the visit, or for a month from the visit if something seems a little off. Or if you’re using FieldMotion as sales rep management software and your potential customer is busy for now “until after the 15th”, you can arrange to come back on the 16th.

In FieldMotion, you can set the date of jobs in a few different ways.

There is always, of course, the method whereby you create a job, and then set the date manually. For example, you create a job and set that it will happen on the 27th of August.

Then there are workflow-based follow-ups, where upon completion of a job, you can set one or more followups based on rules such as “7 days afterwards”, etc, and the workflow management system automatically books a job in for you.

Or if you know you need to do something on a periodic basis, you can set up a recurring appointment in several ways. For example, you might want to go out on the 6th of every month, or every Tuesday and Wednesday, or every 13 days, or on specific days every year.

Recurring jobs are tricky to manage in service management software. When you specify a definite single date for a job, there is one single entry in the database and that’s easy to manage, but with recurrences, it’s a lot more difficult. If you say “I want to go out there every Friday”, exactly how many jobs must be placed into the database? If you don’t put in an expiry date, then the answer is “infinite”, which is not easy even for the best field service software.

Our first solution to this was that when you set up recurrences, the follow up jobs would only be created after the first jobs were completed. So if you set up to see every Friday, then you’ll actually only see this Friday’s job in your list until you complete it, and then next week’s appears.

This wasn’t good enough, though. Based on feedback, we changed our workflow management software so that recurrences are calculated out 30 days in advance. So if you have something that happens daily, you can see 30 jobs ahead of you. This added complexity to the job scheduling software, though – what happens if you change your mind and want the recurrence to be three days a week? We had to adjust it so when changes happen to the recurrence frequency, the recurrences are recalculated.

But then some people need to see months in advance. So we recently added that you can set up your recurrences to calculate anywhere between 30 and 1000 days in advance, depending on your needs. So, if you like an uncluttered calendar that only shows what you need to know now, you can set it to 30. And if you need the field service software to show exactly where everyone will be 9 months from now on a Tuesday, then you can also set that up.

Talk to us about how you schedule your work.

service management software is all field

We have been calling our software “field service management software” (FSM software) for a while, because that’s technically what it is, with “field” meaning that the engineer would be away from the office for most of the day, potentially completely offline, so the system needed to synchronise data from disconnected sources, and needs to have all the information it needs so the engineer doesn’t need to call the office to ask questions.

The word “field” differentiates what we do from the “traditional” way to do service management, which is to do it through pen and pencil, or from software where the engineer needs to have a full-time connection in order to fill in data.

Anyone that is still doing it the pencil and paper way is wasting time and money. There really is no excuse – why are you wasting time filling in data two or more times, travelling back and forth to the office, wasting the time of other people that need to fill in your data?

And anyone that uses a non-field service management software is wasting money, is losing out on the flexibility that a modern FSM system brings, and may be stuck in a dead-end dinosaur of a system that will be difficult to migrate from.

Up until smart-phones were ubiquitous, it was common to either have physical paper forms, or to use clunky PDAs that you then had to synchronise manually with the office database each day.

But these days, everyone has a smart-phone. Along with the power that this brings, it allows us, as developers, to have a common base to work on. We can trust that almost everyone out there in engineer-land has a phone with either Android or iOS on it, and we can write software that we know will work everywhere. If your job management system doesn’t work when you get to where you need to do the job, then you need to talk to us so we can hook you up with our own!

Before, we would need to find out what PDA the client intended to use, then write software specifically for that PDA. As someone that has had to do that well before field service management systems were a thing, let me tell you that this made every single new job a nightmare. Not only would every system cost a fortune because of the learning curve we had to go through to learn each PDA’s quirks and languages, but we then needed to support every single system we had ever written.

With the ubiquity of iOS and Android, and especially Cordova, which lets us write one single software that works on everything, that nightmare is gone. We write our systems now safe in the knowledge that what works in the office will work in the field, and if there are any devices out there that don’t work, they’re so rare that we mostly don’t need to worry about them. We still get them every now and then, but they’re actually more an interesting puzzle now than nightmare-inducing. We solve the differences, and that’s yet another class of devices that we won’t need to worry about anymore.

A company that is buying their first software these days will go immediately for field service software instead of just service management software solutions. The main difference is that field service is designed to work everywhere, not just within a specific building or location, but that’s how most people work – it’s rare to find a service team that is located just in one small isolated area.

Even in isolated locations such as factories or ships, there is still enough movement involved that the engineers need to be able to receive and send data from disconnected points. There is no guarantee that they will be working in a desktop- or laptop- friendly environment, so it makes sense even in the most confined working environments that the service management software should work on a mobile device such as a phone or tablet.

Another difference is scale – field service management software tends to be written for large numbers of clients and users. This means that the systems can be flexible and relatively cheap to deploy. The flip side is that when service management software is written specifically for a customer, it tends to be inflexible and very expensive. Because our system is designed to be used by literally thousands of customers, we always take care when adding features that those features are either configurable, optional, or that they work in a broad enough way that they work for everyone.

All of the best field service software is designed such that it can be easily upgraded, and all the best field service management software companies will be constantly pushing out new upgrades. We release a new version almost every 6 months or so, and there are always enough new things in there that every year we are actually amazed ourselves at how different this year’s system is from last year’s.

image: even boats need to be serviced

Why does FM software update so frequently?

One of our clients asked us why we release new versions of our workflow management software app and CRM so often.

image: the Waterfall Model is the general model of software development we follow to ensure that our clients experience only the most stable version of FieldMotion available (Maintenance in the model), unless they choose deliberately to use our testing (Verification in the model) server

We don’t really. Yes, there is always a lot of development going on with the field service management software, but this only filters down to the public once it’s been thoroughly tested. The only exception is when we fix an issue (such as today, we fixed an issue where exporting job data from the job management software, while applying a custom filter based on the customer name, ignored the filter), but the system is really so well-used now that there are no common issues left. Even if we fix 50 issues, you will probably never have noticed any of them before or after, because they’re all to do with using the system in a way that is uncommon.

FieldMotion is cloud-based field service software – we have maybe five different versions of it serving all of our clients. When we release a new “stable version” of the field management system (every six months or so), we start moving clients onto it from the older versions. Because we have many more field management software clients than we have internal developers, this means that the clients will sometimes do something we did not expect, and we then have to fix whatever allowed that to happen.

The stable versions are called “stable” because they are changed as little as possible. In the Waterfall Model of software development, these versions are called Maintenance versions because the only ongoing development they receive from the moment of release are maintenance updates. The only reason we change anything on the stable field service manager software servers would be to correct a bug. If a client insists that they need a new feature that we have not yet released on a stable field services management software server, then we move them to a testing server, because we do not develop new software on a stable field services management server. Of course, we only move them after first making sure that they are aware that the testing server is, by its very nature, not a stable server, and therefore they might experience glitches every now and then. This is their own choice to make. To wait for the new requested feature to be released within six months on a stable field service management systems server, or to jump the gun and move onto an unstable server that will have new features and tweaks almost every day.

With the app, we have “stable” points as well. Whenever we do anything new on the app, it’s added to a completely new repository version. Every repository version that we have has a specific purpose for its existence. For example, repo 73 was created to help speed up a form that a client’s field workers pointed out was slow. We spotted the issue, fixed it, and his mobile workers’ forms now load exactly 54 times quicker (yes, exactly). Everyone that upgrades to a new repository version gets the new enhancements that repository and all the preceding ones brings. This means that if you are on version 62 (optionally disable job ref editing on the app) and we upgrade you to 73 (speed up form-based calculations), then you also get the enhancements and fixes for everything in between.

We are always adding new fixes, features, and optimisations to our service software code, but we only ever upgrade people if it’s necessary (such as to fix a bug which we identify as possible affecting multiple people), or after we take a break at a certain repository version and decide to “rebase” everyone to it so we can have everyone on generally the same number again. Of course, we first put the app through yet another round of rigorous testing, but because later versions are by their nature more tested than earlier ones, we rarely, if ever (I really can’t think of a single case) come across an issue where we’ve broken something that previously worked.

To be honest, we probably update our stable servers much less than larger companies such as Microsoft do. I’m sure you are all familiar with Microsoft’s Windows telling you to please wait while it installs updates? Well, all software needs updates sometimes, but we try to make them in the background so you will never notice them.

So, to the client that thinks we release new versions all the time. No, we don’t. Yes, there are always new features being developed, and issues being addressed, but the only reason you would encounter all of those changes would be if you are a member of our development team, or if you are one of the few who are early-access testers for us.

What is Workflow Software?

According to Wikipedia, a workflow management system “provides an infrastructure for the set-up, performance and monitoring of a defined sequence of tasks”. The words themselves are usually enough to give a good idea of what it is, but there is an actual industry standard that defines what is or is not a workflow system.

image: when workflow is designed correctly, the result ticks along beautifully

Workflow software has been around long enough that there are actual international groups that define standards for what they do. For example, the Workflow Management Coalition was set up in 1993 by IBM, HP, Fujitsu and about 300 other software companies.

A workflow system is broken down into abstracted categories of system:

Routing System
This is the part that most people think of when they mean workflow – it defines the order in which jobs happen, and moves information from job to job as needed. In FieldMotion, we define these sequences using the onComplete logic system and through “sources” in the form fields.

Distribution System
In a fully automated system this takes the role of a manager, dividing work out among workers so that no-one is under-utilised. In FieldMotion, this is handled through the Dynamic Scheduler.

Coordination System
This makes sure that there are no clashes – that people are not asked to do two jobs at the same time, etc. Our dynamic scheduler handles this automatically, but we also make this visually obvious in our Timeline view of jobs, where you can easily see overlaps.

Agent System
The agents are the “workers” of the system. In a field service application, the agents are the engineers that are out doing the work.

Assistant System
In a system that has some artificial intelligence built in, the “assistant” is an AI system that will offer hints as to what should be done, based on insight from the other data in the system. FieldMotion’s Dynamic Scheduler is an assistant system, as it offers a suggested order of events based on information such as geographic location of the jobs, the category of work and the skills each worker has, the the hours the worker is active, etc.

The original definition of Workflow Management System was defined for fully automated systems, like manufacturing plants or software workflow, but since the advent of smart-phones, the definition has been spread to include field workers and Field Service Management Software.

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.

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.