2018 plans

It’s been about 6 weeks since my last post. In that time, we concentrated mostly on identifying and closing as many bugs and other issues that we could, to bring 2017 to a satisfying end. We deliberately avoided adding new features, so that we could make sure the year ended with a tidy and clean field service job management software.

We got the entire team to point out everything they found to us, no matter how small. Near the end, it was almost like the Red Queen race in Through The Looking-Glass – we were fixing issues at the rate that we were finding them, to the point that I would also work on them at home and on the bus, just so I could keep ahead of the influx and get a sense of progress.

“Well, in our country,” said Alice, still panting a little, “you’d generally get to somewhere else—if you run very fast for a long time, as we’ve been doing.”
“A slow sort of country!” said the Queen. “Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!”
Through The Looking-glass, by Lewis Carroll

We persevered, though, and finished the year with only the most obscure and unimportant bugs left to work on in the field service management software this year. I just checked and we completed 125 issues in December. That’s an incredible number of issues to complete in such a short time.

The most obscure of these was what we call a “sigma 6” issue – something that normally only one in a million developers might ever encounter. When we figured out the cause of the issue (a database lock that happened when a client tried to import thousands of jobs at once, and when that appeared to be slow, tried to do it again) and then solved the issue, there was a real sense of elation. Serious! We love solving problems.

One of my friends in Google says that because of the sheer volume of users that they have, they encounter these kinds of issue every day. He recalled one incident where a cosmic ray flipped a bit in a running process and caused a huge database to delete itself instead of simply adding a row as requested! The anecdote is on page 13 in this transcript. Luckily, we’ve never had anything like that happen, and it’s incredibly unlikely it ever will happen. As John said, how do you protect against cosmic rays?

I get bored at Christmas, so it’s generally the time when I get some work done on FieldMotion that I was too busy to work on during the rest of the year. So over this Christmas, I sat down and wrote a multilingual framework for the job management software. What that means? It means my personal account in FieldMotion is now in Irish, where anyone else viewing the system sees it in English.

Once I’m happy that I’ve gotten all the nooks and crannies that I can see, it’s a simple matter to extract the list of translation strings and pass them to a linguist to give me back German, French, Spanish, or whatever.

This is exciting for us, as it means not only that we can offer FieldMotion’s field service software in many different languages, but also that we can provide country-specific dialects (American English vs British English, for example), and even company-specific wording. As an example, one of our clients, a car-wash company, insisted that they wanted the word “Wash” used instead of “Job”, because they were afraid it might confuse their employees. We can provide that level of configurability now.

This coming year looks really exciting to us. Translations is just one of the things. We have a large internal document full of plans for the service management software solutions, which we’ll announce as they get close to completion. Contact us for more details!

New features

Wow – it’s been two weeks since my last blog! Shows how busy we are here in FM Central. Well, I suppose it’s time for a catchup on the last two weeks, then.

Up until recently, we recorded the features and bugs of our field service management software in an internal database, marking then done as we went. This was not ideal, of course, as that database is really only useful to developers. So, we’ve started also recording new features specifically in their own page on our internal Wiki.

The most recent developments are:

New API functions to allow creation of multiple jobs simultaneously. One of our UK field service software API users was complaining that it took too long to import jobs into the system (we limit API connections to 1 per second, to avoid accidental network-flooding DDOS attacks), so we wrote a function to let them upload a lot of jobs at the same time. It was perfect timing, really, as I was about to do it anyway as part of our new imports system.

The new imports system is completed. You can now import various things, like customers, assets, etc, with whatever file format you use (XLS, CSV, ODS – common spreadsheet formats), and go through a mapping wizard to link the data into our system. It will then upload the data in batches, with a nice progressbar showing you how much is done, how much is left to do, and a count-down which is probably more accurate than the Windows download time calculations 😉

Once the import is finished, it will then tell you if any failed to import, and will give you a downloadable file containing those broken entries.

A little addition to the field service software app. If you’re working on an asset such as a boiler, and you want to have a table of all the contained assets (de-aerators, pumps, traps, etc), you can do that now. You can set up your service job management software so that if you select the asset, all its sub-assets will be displayed in a table under it. You can even have their custom values pre-fill into the table, ready for you to adjust as necessary.

Also in the app, you can now have a field copy another field, so that if you change the first, then the second will automatically fill with the new value. This is useful where you might have a long form where some values are needed in various places in it.

We previously only allowed PDF reports to be sent at the end of a job, as one of the points of job management software reports is that the customer should not be able to just open them and edit them. PDF reports were limited, though, because of how they work, so a lot of our recent reports have been in Doc format. We can now send those reports, by automatically converting from Doc to PDF just before the email is sent.

Our new Purchase Ordering system is nearing completion. Looking through the list of features, I see we can now automatically break Requisitions apart into separate Purchase Orders, and any POs associated with Contracts will be displayed on the Contracts pages.

A nice new field service scheduling software trick which will help speed up very large companies – previously, in order to create a job, you would need to select the customer, the job form(s), the department (if any), and the user. We’ve done some work speeding that up. You can now associate customers and forms with departments, so if you select a customer, its department is automatically selected, which then filters down the list of forms and users available to select. If there is only one form available, or one user, then they are automatically selected. We also added a “select by default” option to forms so if they’re available after filtering for department, then they will be automatically preselected. This way you can cut down the creation of a job right down to just “select customer. click Create”, in some cases.

More field service management app magic – we added comparison operators (less than, equal to, greater than, etc) to the Calculations module. You can use these to do some nice tricks. I demonstrated how to use just the new ‘<‘ operator, for example, to fill a field with the word “Yes” if today’s date is between two other dates. Contact us for a demo and we’ll show you this trick and much more.

new manual site

Last month, we proposed writing a book to explain how to use FieldMotion, but realised that a much more useful reference would be similar to WikiPedia, where every subject has its own article which we can expand as we need to, with links branching off to related subjects.

In the late 90s, a company I worked with used an internal documentation system called “WikiWikiWeb”, which was written in Perl – a hard-to-read programming language which I’m glad to never have to touch again! The WikiWikiWeb software had been created only a year or two beforehand by a programmer, Ward Cunningham, who based his ideas on Hypercards, which was invented on the Mac. Wikipedia is an example of a WikiWikiWeb implementation.

The idea of a collaborative encyclopaedia or internal documentation store that has links off to other related subjects is useful, because people don’t think in straight lines. I’m sure you’ve found yourself on Wikipedia many times, intending to read about stress concentration in vertical structures and finding yourself clicking on interesting bylines until you have to stop yourself at 3am when you realise you’re studying the usage of Bulgarian wedding songs in Japanese anime soundtracks. Or is that just me?

Up until recently, we were using Google Drive for sharing documents internally, but they’re really not very useful for that purpose. I have friends in Google who refuse to use it themselves because it’s really not fit for purpose. You upload a useful file that you think people should be able to reference easily. But how to share it? You need to individually share it out to people, but that’s not the end of it – how do you organise the files? The address is different for each person so there’s no easy way to make a link that can be embedded in a web-page, and even if you did, you now have two systems to take care of – Google Drive and the system you use to organise the files.

By using a Wiki, you create a central repository of knowledge which any member of staff can update at will, and it acts as its own reference. Each “document” in a wiki is a plain text file that can contain links off to other articles of interest.

In FieldMotion, we have two wikis – we have an internal Wiki which is for writing about internal processes, and an external one which we intend to be read by customers and will contain information about all aspects of how to use FieldMotion. Very soon, if you ask us a question, we will either point to a wiki page, or we will create a wiki page and then point to it 🙂

The wiki (which I’ll link to as soon as we’re ready with it) will serve as an answer to any questions that come in, but it will also be a source of new knowledge.

In our internal wiki, we keep a list of new features, so that our own workers are aware of all the new things that FieldMotion can do. We will do something similar on the new public wiki so that all our customers are aware of the features of the system.

selecting all assets in the app

When filling out a form in the app, it’s sometimes needed to select all assets that belong to a parent asset. Or even all of the customer’s assets.

Example one:
You are asked to inspect every fire extinguisher belonging to XYZ Ltd. So you create a job in your FieldMotion fire risk assessment software, assign it to the customer, and set the form (maybe a PAS-79) so it selects its assets only from that customer’s. Thanks to a handy little trick we have, you can do a two-click “insert all assets” which will select all of the customer’s assets and put them in different columns of your form’s table, saving you time and making sure you have details on all of them.

Example two:
You’re asked to go out to a customer and check one of their boilers. You’ve worked with this boiler before and have a list of all the parts in it recorded as assets owned by the boiler (which is also an asset). So you create a job in your FieldMotion boiler service software, assign it to the customer, and select the boiler from a field in the form. Later on in the form, there is a table of the sub-parts that need to be inspected. You have set that to pick from the asset selected earlier in the form. You “insert all assets”, which inserts all assets that are recorded as being in that selected asset.

In both cases, the field service system has already saved you maybe half an hour.

The second example is possible as of today, as we just added that method of sourcing assets.

If either of these scenarios fits your business and you want to see how else our workflow software can save you time, ask for a demo and we’ll show you what is field management all about.

import system rewritten

An issue that comes up with our field management service software clients more and more often lately is that most of our file uploads and importers are written using Flash to enable the file upload. The reason for this is that up until recently, there was no other way to upload files without having to reload the entire page.

Because we try to be the best field service software and keep everything as easy and smooth as possible, forcing a reload of the page every time a file was uploaded was simply not on. The only alternative, though, was a Flash-based uploader. So, that’s what we did.

Now, though, web technology has advanced enough that we can upload files using just JavaScript. No flash. That’s very important because Flash reaches its end of life in 3 years. This is a problem for some service management software solutions I could name that rely heavily on Flash. Luckily, our own investment in the technology was minimal.

The first thing to be rewritten was the importer for Customers. I have yet to plug it into the Customers page properly (it needs to be passed by our testing department first), but it’s working well enough that I can describe what we improved.

Firstly, we had the issue that even though we provide example files illustrating how we need customer imports to be formatted, a lot of our field service management clients had trouble fitting everything into those formats, so we would end up doing it ourselves, or the clients would try anyway and potentially break some of their already imported customers.

To fix this, the import process now includes a mapper. You upload in whatever format your own exports are in (XLS/XLSX/CSV/ODS), and match your headings against our own.

Once that’s done, click Save and the system will ask you what to name your new map (if you hadn’t chosen a pre-existing map), so that next time you upload from a file in the same format, it will already know how to handle it.

After this, the system starts the import properly.

It starts by uploading one at a time, then two at a time, etc., until it figures out how many you can upload at a time so each batch of uploads finishes in 5 seconds. A five second interval is enough for the system to keep you apprised of what’s going on, with uptodate numbers of completed or failed imports, and a reasonably correct timer that will tell you how long you have to get that cup of tea. It can take a while to import customers, as we do a lot of checks to make sure you’re not uploading duplicates or obviously incorrect data (names in the lat/long fields, for example).

When the import is finished, any customers that failed to be imported will be grouped together and you can download a CSV from the result page, to see what was wrong with them and try again.

This system is currently in with our test team so they can do a thorough review of it before update the workflow management system and replace the old flash-based one.

It’s a huge improvement, though! If you’d like to see it in action (along with the rest of the best field service management software on the market), please ask us for a demo.

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.

Field Service Software in the UK and Ireland

While we have customers in many countries, the vast majority of our active users are in the UK and Ireland.

We have a screen which we use to measure lag from various areas, so we can figure out if reported issues are within FieldMotion (FM) or local networking issues. When it lights up a new location, I am sometimes reminded of a screen that was shown in the lobby of the Google buildings in Dublin that showed active search queries around the world and the location the query came from.

As I glance at the board, I see activity in London, Cardiff, Sheffield, Newcastle Liverpool, Bradford, Edinburgh, Derry, Dublin, Waterford, Kerry – and that’s just in the last few minutes. Field workers eventually filter down into every place you can think of. The workflow management system lets field workers work anywhere and report back easily. They simply receive their job orders on a mobile device and off they go. No need to go back to the office. Just fill in the forms on your phone or tablet, and it will do the rest. Doesn’t matter if it’s Android or iPhone.

Because we’re situated close to the Northern Ireland / Republic of Ireland border, we find it easy to relate to companies in both the UK and in Ireland. Personally, I actually live in the Republic itself, in Monaghan, and travel every day to Armagh and then Newry to get to work.

A light blinks on in Waterford. And another in Hull.

When I worked for a web development company about ten years ago, I used to enjoy recognising clients on almost every street. Nowadays, because FieldMotion is getting so large, I get to play that same game everywhere.

A few days ago I was getting off the bus in Monaghan when a van drove past with a Limerick company’s name on it. That was one of ours. I remember going on a five hour drive to their place of business (and back) a few years ago with one of our sales guys, who played the soundtrack of Frozen on repeat all the way there and back. It was …interesting. They already had a workflow system but it was complex and cranky. They were looking to replace that with a simple workflow software that worked better and let them do more. That was us.

I was in Dublin a few weeks ago and a large gas and electricity supplier was doing an ad campaign. Practically every bus-stop had an ad of theirs. One of ours.

We’re planning a new trick soon where our clients will be able to put QR codes on their vans which let other people scan the codes and hire them for jobs directly. This will make it easier to spot our field worker software clients everywhere.

A light blinks on in Preston. Wakefield. Antrim. Ennis.

It’s not just the large companies that we do. FM can be a workflow management system for small business as well as large. Any company with two or more users can benefit from our system.

A light goes on in Port Laoise.

We’re everywhere in the UK and Ireland. Join us.

FieldMotion the Mini-ERP

We were talking to some people recently about how the system works, and one of them said something that got us thinking. He said “This is so much more than just a field service management system. I can’t quite put my finger on it, but there’s something else there”. I turns out the something else is that we’ve been gradually growing the system well beyond its original humble beginnings as the best FSM on the market, and are now pushing for world dominance in the ERP world (enterprise resource planning).

It wasn’t intentional, really. We just respond to market needs and give our customers what they want, but in the course of doing this, we went further and further into total business management than we originally intended.

A few years ago, we drew a concept map on a whiteboard to represent what we currently do and what we intended to cover over the next few years. A few of the ideas we scrubbed were things like purchase orders, inventory management, personnel management, but it turns out that these subjects have been growing in FieldMotion’s ecosphere despite us not intentionally planning them as major features. We simply add a little thing here or there because they make sense to do, and suddenly we have a whole new feature we can tout.

From a development perspective, we develop FieldMotion in two ways

  1. From a top-down way. Eg: we deliberately added Xero integration, both public and private API versions. For this, we start with the high-end concept “integrate with Xero”, then break that down into the tens of steps needed to accomplish this.
  2. From a bottom-up way. Eg: by fixing an issue that meant rewriting a workflow management system import script that was a little “off”, we grew an SFTP file importer that can import XLS/XLSX/CSV files and “map” them into objects we have in our database. The power this gave us meant that we suddenly had a new large feature where we were just supposed to fix a small annoyance.

The bottom-up way is what has brought us towards ERP. We didn’t deliberately strategise about entering the ERP sphere. It just happened.

In a very correct way, it’s like biological evolution. We started out trying to make better service management software, and accidentally created an enterprise resource planner. This is similar to how insects developed little nubs to dissipate heat, that grew through trial and error until eventually they discovered they could fly with them and they were no longer land-bound.

We thought we were right at the pinnacle of the hill of Field Service. We’re now discovering that we’re half-way up Mount ERP.

This is thrilling for me, because I can now look at every other ERP out there and start expanding our field worker software to do whatever they do, but cheaper and better! Talk to us to find out how.

First, though, let’s finish off the next few months of planned development – can’t go running off into the future yet!

What we’re working on this week

As usual, this stuff may take a few weeks to filter down into the production servers so you may not be playing with it until then, but I like to explain what we’re working on, to keep us excited and keep you apprised of upcoming stuff. If you want to give FieldMotion a try, plese ask for a demo.

The main features we’re working on this week:

  • Letting your customers pay their invoices through PayPal
  • Adding stock to sub-tables in forms
  • Purchase Orders
  • Imports overhaul

Some of our clients have expressed an interest in being able to send out invoices right from the field worker software and have the customers pay them as soon as possible. Maybe even before the worker leaves the location of the job. Or, we could add it into the OnComplete logic, so the workflow management system automatically sends out a PayPal invoice upon completion of certain kinds of jobs. For example, if you’re using FieldMotion as pest control software and you’re out on a simple elimination job, you may want to invoice before leaving the premise. other job types, you may want to tweak before signing off on – maybe there’s stuff like mileage or discounts to work out.

We shuddered at the thought of storing credit card details anywhere at all on our system, so that idea was totally vetoed. PayPal, though, works for everyone – if your customer prefers to pay through credit card, PayPal allows you to do so. One of our juniors is currently working on his personal copy of the CRM to make all of this happen. Once that’s working, we’ll then expand the scope out so it can be done from the app as well.

Up until now, when stock was used on the job, it was marked off against the job as a whole. But some clients prefer to be able to point at a sub-part of the job’s form and say “it was used there”. To do that, we’re adding stock to sub-tables.

It sounds easier than it is! Doing the app part may just take a few hours, but I also need to make sure it’s editable on the CRM, that it goes neatly into reports, than it updates stock values correctly, and that it is easy to use. Simple workflow software is hard to write. This may take days. We’ve had this in mind for months, but each time I wanted to get started on it, something else more pressing would rear its ugly head. But, we’re finally getting it done now.

The Purchase Orders project is taking a while to do, but I have a reliable and thorough developer working on it so I know when it’s done, it will be done well. Checking on the issue tracker, I see she’s currently working on the final big part (recording and distributing Goods In). The other issues left open are minor and really just a matter of tidying up. This looks promising.

On the Imports overhaul – I’ve finished the FTP-based customer import to the point that the client it was for is happy with it, and it’s working so well that we’re considering using it ourselves for all our own imports. I’ll talk to the head of implementation today about giving that a trial.

My plan is to have all our various threads come together into a completed tapestry before the end of the year. I think we’re on track. We should be able to spend December and November just cleaning up minor issues and bugs. A good year.

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.