1,000,000 jobs completed

A milestone moment.

A few weeks ago, we were doing a little analysis on our historic data and noticed that the number of jobs completed by our field service management software customers was getting close to a million. After a little work, we came up with a quadratic equation which closely modeled our growth. It predicted that we would hit 1,000,000 jobs completed over the weekend.

Well, this morning I checked and we were at 1,000,202!

It’s very difficult to find the exact job that was the one millionth, as they are spread out over all of our databases (we keep our customer databases separate to ensure there is no chance the data can “leak”).

Another nice thing we noticed based on the analysis is that our growth is accelerating. Unlike one of our competitors who has been advertising the exact same number of “completed jobs last month” since early last year, our numbers are growing.

Slow but steady wins the race.

The market for field service business management software is huge. It’s estimated by some that the industry was worth 1.76 billion USD in 2016 and will be worth 3.61 billion in 2021, 4.45 billion in 2022. Others are a little more conservative and suggest 4.1 billion in 2025. No matter who you believe, though, they all say the market is huge.

We have been working our way into this industry for the past 5 years, and are steadily getting more and more of the pie, simply because we work based on what the majority of our clients need, we try to keep it as simple as possible, and we started out right from the beginning with the most common issues in mind.

Our apps work whether you are online or offline, for example, syncing in the background automatically when data is available. There is no need for the user to know how that works – as far as they’re concerned, it just works. Other FSM companies have apps that only work when you are online (and how useful is that when your work is in an area that has no network coverage?). Yet more have a “synchronise” button that you need to press to upload your work and download new work (which the users forget to press).

On the CRM (customer relationship management software) side, we have a core set of features that we try to keep from growing. Yes, we do add some things when they are obviously useful, but we mostly try to not add everything we can think of, because that just ends up complicating the product. Paperless office software solutions, after all, are about getting away from complications – not making more of them.

We anticipate the next million to complete within a year, and the next after that in only a few months. The future is interesting. Talk to us about yours.

FieldMotion as a customer relationship management system

This week, we were concentrating on adding new tools to the CRM (customer relationship management) part of our system.

We recently added that when a customer is changed from one “type” of customer to another, an email could be sent out to that customer. You get to define the email of course – we wouldn’t just send a random email out!

This is useful in cases where all customers need to receive a “welcome pack” email, for example, which includes links to video tutorials, etc.

We got that working well a short while ago. This week, we’re making sure that the history of sent emails is recorded next to each customer, so you can say for definite “this email was sent to you on 2017-xxx at xx AM”.

The fact that FieldMotion can be used as a CRM is something we don’t usually advertise, because it’s mainly designed to simply be the best field service software. However, since we actually use it internally for our own sales, and have experience with other CRMs pre-FieldMotion, we know that it’s up there with the best of the rest.

One of our sales guys was chatting with a potential client recently who had been tasked with procuring a field services tool for the company – the company had already looked into getting a bespoke application built and had balked at the massive number involved (hundreds of thousands). During the course of the chat, our salesperson mentioned that we use FieldMotion internally for pretty much everything we do, even customer relationships, and he suddenly perked up “oh? that’s another off my todo list!”

All field service management software companies should take into account that all companies need to manage their customers. It’s not like they magically appear and stay around – you need to have a method of setting reminders (callbacks) for yourself to keep in touch with them – you need to have a list of notes and files in one handy place where you can read or update them at a moment’s notice. Service job management software needs to record what you did for the customer before, what they said, anything related to them.

If you’d like to learn more about the CRM part of our paperless office software solutions, please ask for a demo.

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.

purchase ordering system

This week, we’re polishing the purchase ordering part of our field service management software. This is a system which allows you to create purchase orders, mark off the items as they come in, and automatically update the stock levels of the destinations as you mark them off. This helps our clients take yet another step towards having a truly paperless office system.

As an example, let’s say a user has asked for 15 of product A and 10 of product B. You create the purchase order, list the items you’re ordering, and then as the orders are delivered to you, you mark them fulfilled, which will automatically increase the stock-take of product A and B for the user.

If only a few of the items were delivered to you, you just mark in the amount of arrived, which leaves the order in the status “Part Delivered”.

You record the cost and price of the items, so there’s an option in the future of maybe expanding this into something a bit more accounty than it is at the moment.

To round this off, we’re adding in the ability to record what stock is with what customer; something we’ve been asked for a few times. This means that you can set your purchase order up with the customer as the end target, then mark off the products as they are delivered to the customer, meaning that you have a record of all deliveries and part-deliveries.

We hope to have that done by the end of the week. If you’re interested in beta-testing this (along with the rest of the system!), please contact us and ask for a demo.

file attachments in the app

Files in the app can be attached in various ways, depending on the needs of the job or even the needs of the industry.

A file can be attached to a customer, a specific job, an asset, or even the user of the app. This adds a sense of granularity, and lets you access the files in your field service management software in ways that make sense.

For example, if you attach a file to a customer, then create three jobs for that customer, when you go into the jobs on the app, you will find that you can access the customer’s files directly from each of the job. You can have job-specific files as well if they’re needed.

This is useful in field service industries where documentation is needed for customer assets, and that documentation is needed for all jobs done for that customer. For example, for boiler servicing software, a customer might have a specific model of boiler. Documentation for that boiler model, then, should be attached to the customer in the boiler service software so that every time a job is allocated to do for that customer, you have the files you need.

The app itself doesn’t read PDFs, etc, so you need to have a PDF reader (or whatever reader, depending on the file type) installed on your phone or tablet in order to use the files.

For assets, you might want to attach specification documents or manuals. For customers, you might attach invoices or other info. For jobs, you might have photographs or annotated images detailing the work to be done.

route optimization in field service management software

We’re polishing off an upgrade to our dynamic scheduler, which is a field service route optimization system that allocates engineers to jobs based on a number of criteria.

The technical details of how exactly it works are a bit of a trade secret, so I won’t get very much into detail about it, but I’ll give some broad hints – the field service optimization software works by assigning “costs” to decisions (does the engineer assigned have the right qualifications, does it bring the engineer into overtime, is it at the requested time, cost of the engineer’s hours, total hours worked, etc), and trying to minimise those costs.

In route optimization, field service is not really well covered in the market. Most route optimization systems are very simplistic. For example, they might assume that all engineers can do all jobs, or that we can simply assign a time to a job and the customer will be happy to work that into their schedule. You know how phone installation engineers keep turning up at your house when you’re not it? Yeah – bad optimization in their field service management software.

In my head as I’m building it, I keep imagining the job criteria as “pressures” – each of the criteria we are balancing acts as a kind of spring or elastic, trying to push and pull things this way or that to bring everything into place. Another way to imagine it is like how bubbles are created – they minimise their surface area efficiently, based on pressure from within.

From the user’s perspective, this must all be invisible – they should simply create a job and have it automatically assigned to the right person, or select a load of jobs, click “Schedule”, and have the field service job management software sort them into a reasonable solution.

Solving all of this so that it’s easy for the user is not a straight-forward thing for the developer. I mentioned “costs” – but what values should they be? Deciding exactly how “strong” the springs and elastics in the model should be is a difficult problem in itself! We’re considering writing a system after the current phase of development which will use neural networks to try figure out the right answer to this one. In the meantime, we have some pretty good values that give us results that look right.

The final parts we’re finishing off involve making sure that engineers get home after their day’s work at a reasonable hour (no routes that spend 8 hours meandering them 300km away from home and leave them stranded), and taking individual work hours and holidays into account. The field service engineer management software needs to take all of these into account, or the engineers will not be happy.

Our field service management software features are already impressive, but we think that after this phase is finished, it will leave the competition smoking 🙂

We have a number of clients already using this in their day-to-day work. If you’d like to join them, contact us for a demo.