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.

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.