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.