The Little Field Service Management System that Could

Last week, I had a call from one of the bosses, who had just been talking to a potential client who had built up a large spreadsheet of 42 field service management systems active in the UK, and whittled the list right down based on features and demos to just us and SalesForce through a few rounds of elimination.

We both agreed that this was great, for a few important reasons

  • If someone makes the effort to compile a large spreadsheet, then they are well-informed on the generally published information about the products and therefore their opinion bears weight.
  • Any product on that list which is in the top two is obviously better than at least half of the 40 products, and probably better than nearly every other one as well.
  • I can’t think of a single instance where we’ve been up against SalesForce in a proposal and lost to them.
  • Therefore we’re brilliant!

Obviously that’s anecdotal. One data point does not a research paper make.

But, we’ve recently been agreeing more and more that we’ve reached a satisfying list of features that cover the needs of 95% of all people we talk to. The other 5% are either looking for completely bespoke work, or are just totally unsuitable for what we do.

So, by working solidly and carefully for five years (I think I can, I know I can!), we’ve finally reached the pinnacle of the excellence hill, where we are now consolidating the system around those points and making sure we definitely cover that 95% comfortably.

That’s why it was decided weeks ago that the next round of development (first half of next year) is completely around making sure that the system is rock solid and easy to use.

For ease of use, we are working towards an eventual SAAS model where clients sign themselves up to our field service engineer software and walk-through an onboarding “wizard” of sorts that teaches them everything they need to know. We have videos of all parts of the system. We’re writing a book about the system that will be split-tested to make sure it is extremely easy to read. We’re also considering a community forum where clients can ask questions and be answered either by ourselves, or by other experts (like how Stack Overflow works).

For rock-solidness, we have a load of techie tricks we’re working on which I’d love to tell you all about but (shhh!) they’re secret. Basically, we’re trying to get to the point that the system grows automatically as needed, that our development process allows us to push new developments into production as soon as possible (continuous integration), and that every single line of code that’s written and every issue pointed out by any client is tested automatically before being allowed anywhere near a production server.

From what we hear from our clients, we are the best field services management software on the market. This is from clients that have used other FSMs. We want to increase that lead and be the best that we can.

New import system coming, replacing Flash

We have imports in a number of places throughout the system, building each one separately. Some are better than others. The Jobs page, for example, has a nice importer which will let you upload a sheet of jobs in any reasonable format and let you “map” your own layout to our internal layout. You can even record that mapping so that you can use it again next time you need to do an import.

I was asked to replicated that method throughout the site, and thought about it for a bit before diving in, so I have a few other ideas about it that will improve it further.

File uploads in Web 2.0 systems have traditionally been done using Flash uploaders such as Uploadify, because up until recently, there was no good way to handle file uploads that didn’t look clunky and Web 1.0. However, Flash is a deprecated technology and will be removed completely by Adobe in 2020.

Some of the other paperless office software solutions are going to be hit really badly by this, as I hear that at least one of the larger workflow management system companies is built entirely on a Flash infrastructure. They’re going to have to rebuild completely within the next two years!

Google Chrome are hinting heavily at that as well, by the way that they disable Flash by default, to the point that when any of our clients say that they can’t upload a file into our system, one of our things to check is “Have you enabled Flash?”. It happens so often that we even made a video showing how to do it!

So, Flash has got to go.

Thankfully, the new HTML5 file uploaders are much better at handling uploads gracefully!

Along with replacing flash as the uploader technology, we’re also thinking about the actual flow of an import.

When a file is imported into the Customers part of the customer relationship management software, for example, we will run the import and then tell you how many were imported. If your spreadsheet contained 2000 customers and we report that 1999 of them imported, what happened to the other one? Why did that not import? Well… because of how imports are currently done, it’s very hard to pass error messages back to the browser, so no – we literally can’t tell you what happened to that one, so you need to now go through your file and see for yourself what didn’t upload. Ick! We are really sorry about that shoddiness (which is implicit in the technology, so hard to get around), and hopefully the new importer makes up for it.

How we’re fixing that in the new importer is that when you upload a file, we then send the contained data back to the browser, which then uploads the data again, but one at a time so it can keep tabs on the progress, and keep records of what errors popped up. After the import has finished, the browser then knows what rows failed to import, and offers you a download of those failed rows. Much neater!

Depending on how busy we get with other stuff, I expect this to be all completed some time next week, and available to clients who are on our “bleeding edge” paperless office solutions server. Those on the “stable” servers will need to wait until the next public release of FieldMotion, which I expect will be in only a few months, as we’re closing in on completing the major parts of it.

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.

workflow in customer relationship management software

This week is mostly about adding workflow to our customer relationship management software.

The “customer journey” describes how a customer changes from being a lead, through its various possible other labels. There is no real end-point to the journey – a signed customer might become a re-sign, etc, a canceled customer might eventually become a lead again.

In our system, you can define what customer types are possible “next steps” in the journey, ensuring that your managers don’t accidentally update a lead immediately to a re-sign, for example. Of course, each of these labels is completely customisable by yourself, so you can name them whatever you want, add as many as you want, etc.

When you set up a customer type, it is set by default that any customer with that type can be changed to any other afterwards. But, you can reset this so that customer with that type can only be moved onwards to set other ones. For example, a customer with “Signed” status should not movable to “Qualified” or “Lead”.

Another thing we’ve added is that when a customer is moved onto a specific customer type, a templated email can be automatically sent out to them. For example, if you have just signed someone up to your product, you might want to automatically send out a welcome email with a list of instructional documents and videos. Combining this week’s work with the email template work described last week, you can choose what emails should be sent, and design those up however you want.

In a way, this is like the workflow that happens in field service management software – when a customer reaches a point where you need to change how to label them, there are usually a restricted set of ways forward (which types they can be changed to), and a number of associated messages that need to be sent out.

New features in the Dynamic Scheduler

This week, we concentrated on development of one of our flagship features – the dynamic scheduler.

The dynamic scheduler is a field service scheduling software tool that lets you automatically assign jobs to your engineers. It tries to find the shortest route in order to finish the jobs, based on a number of criteria.

The field scheduling software can set your jobs so that they require that your engineers have specific skills. You can set work hours for the engineers so they are not assigned jobs in the middle of the night or weekend. You can “stick” some jobs so they must be done at specific times.

The work this week was on enhancing the job scheduling software so it has additional new features. You can now:

Set work-days and hours for your engineers. Previously, it was hard-coded that jobs would be assigned Monday-to-Friday, 9 to 5, and anything outside those hours would be heavily discouraged by the heuristic. You can now set “shifts” for your engineers, and specific work-days.

Set daily end-points for your jobs. Previously, the routes would be calculated from a “work-base” (for example, the engineer’s home) and radiate outwards from there, but there was no guarantee that the routes would lead the engineer back home at the end of the day. Because European law says that field-workers need to be paid for the hours it takes to get to/from work, this means some routes could end up with the company paying overtime as the engineer simply drives home from the last job of the day. The route planner now designs the routes so that routes end up every day at the work base. Basically, routes are loops now where they were previously strings.

The system would try its best to stop at 8 hours in a day. But if jobs are four hours each and there is 30 minutes travel between them, this could cause the planner to assign just one job per day. We have added in overtime rules to allow the planner to assign jobs that might stretch the daily work hours a bit.

We have also added a new feature to allow you to add any overdue jobs to the pool of jobs being scheduled. So you can say “I want to schedule jobs assigned between Tuesday and Friday, and put any overdue jobs into that mix as well”. With pest control scheduling software, you don’t want to have to wait too long for a job to be rescheduled, if it has already been put off once.

Some jobs require that a specific engineer do them. Maybe the customer likes the engineer, or they have specific knowledge of the job. You can now “stick” a user to a job so the scheduler doesn’t try assign the job to someone else. this is particularly useful in service industry scheduling software where the product being services is unique.

Iterative development

From our own point of view, and from the points of view of our customers, it is nice to be at a point in our service management software development where we are developing iteratively instead of coming out with new tricks every week.


image: clean, rinse, repeat

While I love it when we develop something new and exciting, it can be nerve-wracking for us for the following weeks, as we try to find out what these new shiny toys have done to our solid, stable, well-tested field service management engines.

New tricks never affect the existing workflow management system customers, because they are on servers that we do not edit except for the occasional bug-fix. The only customers that get to see the new shiny stuff are those that specifically asked for it, or those that asked for other new things such that we were forced to place them on our testing server while we worked on the next release.

FieldMotion is now so flexible that whenever we’re asked to develop anything new, it more than likely ends up that we already are able to do it, so my job is sometimes simply to listen to the request, and then point out how it can done already with the workflow management software.

Sometimes, though, we are asked to do something that’s just slightly beyond what we can do at the moment. It’s never far away; just slightly.

For example, today I was asked if it was possible to do a certain thing with RFID tags. After thinking about it, I suggested a way we could do it that would involve adding maybe only 20-30 lines of code to the field service management app, and yet it opens up our possibilities to yet another broad channel of potential customers.

This kind of thing happens often enough that every six months, we have enough new little tricks that we can release a new version of FieldMotion’s field service engineer software, confident that there is enough newness in there to merit the release, and yet it is similar enough to the previous release that our current clients won’t be shocked at the difference.

Iterative development allows us to “tune” the workflow system to fit better with the customers, knowing for sure that the system already works very well for them, and we’re just adding enhancements, not adding whole new sections that need manuals.

I was explaining earlier today to a new developer that when we create a new widget or page for the field management software, we need to make sure it is as absolutely simple and obvious as possible. He was telling me how he liked the power that the CMS Joomla gives him when he creates a website. Yes, it gives you a lot of power, but it’s at the expense of usability. Every time I have to work with a website that uses Joomla as its engine, I have to learn all over again how it works. That is bad user experience.

When you use any part of FieldMotion’s workflow software, it is straightforward and obvious how it works, whether you’ve been using it every day since you got your account, or this is your first time ever seeing it.

In my old life as a web developer, I would say to clients that “If you need a manual, I’ve built it wrong”. I stick to that slogan and make sure that everything we produce in our system is clean and obvious.

This is also why I love iterative development – instead of developing more and more and more stuff that piles up on the field service software like turrets and walls on a fairy-tale castle, we carefully expand the system just enough to fit the new trick in, and then just as carefully make sure that it is seamless and easy to understand.

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.

How developers are developed in FieldMotion

No two projects are the same. A person coming moving from FaceBook to Google will be lost for the first month. A person moving from Uber to Yahoo would also be lost. The same is true for all tech companies.

When we hire a developer for our workflow management software, we follow a “boot camp” process which gives the developer a grounding in how the workflow system works, and how the code is laid out.

New developers spend a month working in the Implementation department, where they develop digital forms for clients and get to understand how the field management software works from the user’s perspective.

The first month is crucial. New employees are encouraged to spot inefficiencies in how the paperless mobile forms work, and to come up with plans on how they would improve the system if they had the chance. Their plans are added to our internal issues tracker, and worked on over time, either by other developers, or by the new developer.

The next month is spent in handling issues. This can be anything from fixing bugs, to reading logs to figure out what happened at specific times. This month teaches the new employee how the system is spread out, and how we arrange our code. Again, this is invaluable, as you cannot be a good developer if you don’t have a good understanding of the system.

Afterwards, the developer will “gravitate” towards one or more projects to specialise in. Some of our paperless office software solutions overlap (the field service management app and the mobile server, for example), but there’s plenty of room in the system for any developer to “own” a section that they can become expert in.

We encourage our developers to overlap in their knowledge, so that if Alice is out of the office today, Bob can take over if something comes up.

At FieldMotion, we design systems that help you plan your work, but as you can see, we do our best to plan our own internal workings just as rigorously. We intend to be the best workflow management software company in the world, and work constantly towards that goal.

image: we’ve found that pizza helps round them out

upcoming voting feature for clients

We’re trialling a system in-house at the moment which allows us to throw our ideas into a database and then vote on which ones get priority. This way our field service management software development work is not dominated by one or two voices, but is led by consensus need instead.

If this works out well, then we will be pushing it out to all of our workflow management software clients as well.

What will happen is that one client might have an idea of something that needs to be done for their job management software, will explain that in a post, and then apply a few of their votes to that idea. If other clients like the idea, they will also vote for it.

We will monitor the voting carefully, and every week (that’s the plan, anyway!), we will take the top few and get started on them.

This way, you get a stronger voice in what we do, and help to guide the field service software towards something that is even better for your own business than it already is.

In-house, we’re using this to help prioritise work that gets done, so we (the field management system development team) have very clear targets each week, so we don’t get mixed signals (everyone wants their own pet projects now, now, now, and we only have two hands each to work with 😉 ), and so that everyone feels a more collective ownership of things when they are completed.

We are really looking forward to seeing how this works out, and are excited to see what workflow software ideas you come up with yourself.

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.