Improved reports for risk assessment industry users

This week, we concentrated on improving the creation and output of reports for risk assessment software.

These reports tend to be 60 or more pages long (the PAS 79 2016 report, for example), and so can normally take hours of tedious work for the engineer to fill out. By using FieldMotion, you cut that down to just the click of a button.

We overcame two difficulties this week – the first is that some service management software reports may require a mixture of landscape and portrait pages, and the second is that there can be a lot of repeated sections in reports, where the details may change, but the layout stays the same (header, title, questions, etc).

We already were able to provide mixed landscape/portrait pages when creating reports in PDF format, because the way we created those pages was more like painting than writing – each element on every page was precisely formatted and positioned. But with the newer risk-assessment type forms, we needed a more flexible format, so created a method of report-generation that produces Word-style documents, which are flexible and can be as long as they need to be.

The problem with generating Word-style documents (could be OpenOffice, Word, WPS, or any other similar format), is that they’re not really designed to be created by a server, so we need to generate them in HTML format, and then convert to Word by using third-party conversion software, such as libreoffice, phpdocx, and other conversion methods. There is always a loss in the translation.

In a way, it’s like trying to write a book in German by first writing it in French and then using an online translator such as Google Translate to convert from the French to the German. There will always be a loss in either meaning or nuance.

This week, we found a way of improving the existing Word document conversions so that they retained our instructions to switch to Landscape or Portrait at specific points.

The next big breakthrough this week was in how we are now able to easily create large repeatable sections in custom-formatted ways, in a way that’s much easier for our end users than the previous method we had.

It’s hard to describe in text when I mean by this, but I’ll do my best.

In risk assessment reports, there will be parts of the report where you must itemise each risk, such as fire hazards, doors, combustibles, gas canisters, and must provide some information about each of these, including how the company mitigates risk for them, any expiry dates, etc.

The same is true of other similar industries, such as pest control, where there will be bait boxes inspected, etc., and reports drawn up about them.

This kind of item investigation is predictable – you know that if you have ten fire extinguishers, then there will be ten sections in the report which look similar.

Before this week, we had no way of providing an easy way to enter this into the risk assessment or pest control software such that there could be an arbitrary number of items investigated and reported. Field management software is filled out on mobile devices, which by their nature do not have keyboards or other methods of easy mass-data-input, so anything we could do to improve this was needed.

This week, we came up with a method of drawing up a layout of how the data should be shown, and then telling the report “output the data using that format”, applying the rule to specific tables filled in on the app.

This allows us to have arbitrarily large numbers of items entered into the form and printed to the report in an easily-formatted way.

It was a good week for our workflow management system – two big advances that reduce the work needed by both the end-user, and by the implementation team that generates the report templates

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.

Customer Relationship Management

At its heart, all companies need to manage customer relations.

For the smallest of companies, this can be as simple as meeting a customer in the shops and waving hello, or calling up someone you haven’t spoken to in a while to tell them of someone that might need their services (and to remind them you exist and hint that they give you more work).

For larger companies, the customers necessarily become more remote – you may deal with so many customers that you are not able to remember the names of most of them and you need customer relationship management software to keep on top of things.

As the company grows, it becomes important to manage your customer relations – to make sure that your sales and public relation teams are always reaching out to make sure everything is going well, to get feedback on any pain points that might have arisen, and to point out new features in your product that they may not yet be aware of. In short, you need to remind them that you exist, just like with smaller companies.

To help with this, FieldMotion has customer relationship management built right into the core. We use it ourselves to manage all of our own customers, and are constantly working to improve this.

Your sales team can use the Customers section of our core (which we call the CRM, by the way!) to set reminders of who to call, write notes about your customers and any phone calls, upload files related to the customers, create jobs related to those customers, etc. Think of it as sales rep management software.

We find the “callback” feature to be particularly useful when building up a pipeline of work or sales.

Smaller companies are usually unaware of the potential of building up a “pipeline” of work so I should explain.

When you call up a potential lead for the first time, they are probably unaware of you and just want to get off the phone. This is natural. You might have been given their number by someone that knows the CEO, or maybe an employee of the company passed on the details, or maybe it’s even just a cold-call. Either way, the first phone call is usually a dud.

For inexperienced sales people, this is the end of the line. They got rejected, they give up on that number and go onto the next.

However, if you ask “Can I call back in two weeks? Give you a chance to look us up?” (example – your wording will vary), then they are likely to say “Yes”. You then set a callback for yourself for two weeks from today, and a note about the call.

Two weeks later, you call them back and are able to say “Hi, we were talking two weeks ago, on the 17th, and I was wondering if we could go a bit further today”. You’ve established a small link with the company and are now able to talk a little about what you do.

The process is slow, but each phone call brings you closer to a sale. Every company and product is different, so it’s hard to put a figure on it, but if you read what sales people say online about it, you find numbers such as ten phone calls to get a face-to-face meeting, and ten more calls to get a sale.

If you are constant about it, you find that eventually your callbacks work out and you are getting a constant stream of sales.

It’s important that even if the pipeline looks like it is full of deals that will close soon, you are consistently adding new potentials to it.

Imagine the scenario: let’s say you have 20 jobs to do in the coming month and you think you’ll be so busy making money that you can’t make any phone calls. Does this make you happy? Well, it shouldn’t. Because you have been unable to make any phone calls, the month afterwards will not have as many jobs to do. Your pipeline will have stalled, and it will take another few months to get it back up and running.

You need to be constantly working on all three parts of the deal – qualifying leads to convert them to potential sales, then working on potentials to bring them to the sale, and finally making the sale and doing to work.

Even after a sale, you’re not finished.

You now need to set callbacks to follow up on the work and make sure the customer is happy. Call a month later. Call six months after that. Whichever schedule makes sense to you.

Not only does this keep the customer happy that you are on top of their business and making sure everything is well, but it also keeps your company on the tip of their tongue. If they are asked for tips on who to go to for similar work, they will mention you – especially if you do good work and are constantly checking in with them.

All of the above is easy to do through FieldMotion, and it doesn’t matter what industry you are in.

While our core business is field service management, the CRM part of our system is powerful and flexible enough to cater to all businesses.

Give us a call about our CRM, and we’ll talk you through how we work.

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.

service management software is all field

We have been calling our software “field service management software” (FSM software) for a while, because that’s technically what it is, with “field” meaning that the engineer would be away from the office for most of the day, potentially completely offline, so the system needed to synchronise data from disconnected sources, and needs to have all the information it needs so the engineer doesn’t need to call the office to ask questions.

The word “field” differentiates what we do from the “traditional” way to do service management, which is to do it through pen and pencil, or from software where the engineer needs to have a full-time connection in order to fill in data.

Anyone that is still doing it the pencil and paper way is wasting time and money. There really is no excuse – why are you wasting time filling in data two or more times, travelling back and forth to the office, wasting the time of other people that need to fill in your data?

And anyone that uses a non-field service management software is wasting money, is losing out on the flexibility that a modern FSM system brings, and may be stuck in a dead-end dinosaur of a system that will be difficult to migrate from.

Up until smart-phones were ubiquitous, it was common to either have physical paper forms, or to use clunky PDAs that you then had to synchronise manually with the office database each day.

But these days, everyone has a smart-phone. Along with the power that this brings, it allows us, as developers, to have a common base to work on. We can trust that almost everyone out there in engineer-land has a phone with either Android or iOS on it, and we can write software that we know will work everywhere. If your job management system doesn’t work when you get to where you need to do the job, then you need to talk to us so we can hook you up with our own!

Before, we would need to find out what PDA the client intended to use, then write software specifically for that PDA. As someone that has had to do that well before field service management systems were a thing, let me tell you that this made every single new job a nightmare. Not only would every system cost a fortune because of the learning curve we had to go through to learn each PDA’s quirks and languages, but we then needed to support every single system we had ever written.

With the ubiquity of iOS and Android, and especially Cordova, which lets us write one single software that works on everything, that nightmare is gone. We write our systems now safe in the knowledge that what works in the office will work in the field, and if there are any devices out there that don’t work, they’re so rare that we mostly don’t need to worry about them. We still get them every now and then, but they’re actually more an interesting puzzle now than nightmare-inducing. We solve the differences, and that’s yet another class of devices that we won’t need to worry about anymore.

A company that is buying their first software these days will go immediately for field service software instead of just service management software solutions. The main difference is that field service is designed to work everywhere, not just within a specific building or location, but that’s how most people work – it’s rare to find a service team that is located just in one small isolated area.

Even in isolated locations such as factories or ships, there is still enough movement involved that the engineers need to be able to receive and send data from disconnected points. There is no guarantee that they will be working in a desktop- or laptop- friendly environment, so it makes sense even in the most confined working environments that the service management software should work on a mobile device such as a phone or tablet.

Another difference is scale – field service management software tends to be written for large numbers of clients and users. This means that the systems can be flexible and relatively cheap to deploy. The flip side is that when service management software is written specifically for a customer, it tends to be inflexible and very expensive. Because our system is designed to be used by literally thousands of customers, we always take care when adding features that those features are either configurable, optional, or that they work in a broad enough way that they work for everyone.

All of the best field service software is designed such that it can be easily upgraded, and all the best field service management software companies will be constantly pushing out new upgrades. We release a new version almost every 6 months or so, and there are always enough new things in there that every year we are actually amazed ourselves at how different this year’s system is from last year’s.

image: even boats need to be serviced

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