Job & Staff Scheduling with FieldElite Mobile Service Management Software

Field Service Management (FSM) software systems are designed to enable you to manage your mobile workforce from a central point- and do away with the paperwork involved with the process. They connect your technicians on the ground (via app on their phones), to the staff at the head office- who have an interactive dashboard accessed through their browsers. The office team will have access to all the jobs that are to be handled by the company, simplifying the management process and taking away the risks that come with manual data entry. Here, we will walk you through a quick process of scheduling a job for your personnel with FieldElite.

Say you are a HVAC contractor, licensed, bonded and insured. You’ve made quite a name for yourself in the industry, and have a wide range of clients- in both residential and commercial establishments. Consequently, you also have a large workforce to attend to the different situations- from installing to repair and maintenance. One of your clients- let’s call them ABC Computer Supplies, has an issue with their HVAC unit- perhaps a pipe is leaking. It needs to be fixed, and ABC have booked an appointment.? Your goal here is to get one of your personnel to handle the task as soon as possible, and this field service scheduling software comes in handy.

There are two approaches that you can take:

1. Job Scheduling

From your Dashboard, on the left-hand side you will see the menu option. Clicking on Jobs, will take you to all jobs carried out by your company.

FieldElite

The filters will allow you to view different categories of jobs:

  • Complaint– This means that there was an issue with on ground during the task delivery, and the client lodged a complaint.
  • On hold– Here, different aspects can cause a job to be paused- like when spare parts or equipment required for repair jobs have been ordered, and one needs to wait for them to be shipped in from a different location.
  • Pending– This is basically your in-tray, a list of jobs that are to be carried out.
  • In Progress– The technicians are on the ground, attending to the client’s needs, and you’re getting routine updates from them.
  • Incomplete– Though the job had been assigned to the required technician, it was not completed in the set amount of time, thus requiring an additional visit to the site. Given that the FSM solution increases the first-time fix rate, cases of ?incomplete tasks? are reduced.
  • Complete– The task is successfully done and the customer has appended their e-signature, and now it can be invoiced.
  • Cancelled Invoice– The head office determines that a particular invoice shouldn’t be paid, and thus cancels it.

Our focus here is the pending tasks, so use this filter. ABC’s HVAC job will be among these. Clicking on its Job ID will open up the details of the task, with such an Update Job window:

FieldElite Job

This section contains all the information of the job- both past and present, which you can update in real-time. Any changes will be recorded by the system and can be viewed on the “Audit” tab.

As you can see here, the HVAC repair job is both “pending” and “urgent”. No one really likes sitting in an office that feels like an oven. Being the headquarters, it’s likely handles lots of foot traffic, and the damaged HVAC unit will make the working conditions really difficult. It’s best not to keep the client waiting, right?

So, head on over to the Supervisor and Workers section (on the same “Details” tab), and select the personnel suited for the task.

FieldElite Job Details

Set the time that the task will take for your technician, and once satisfied with the details of the job, click on Update. Voila! You’re done.

FieldElite Job Update

Immediately this happens, the worker received a notification on their app, telling them that they have been assigned the job.

From the app, the technician will be able to view the specifics of the HVAC job, including notes and attachments that you can add directly from your own dashboard, such as schematics of the building and reports from other technicians who installed the air conditioning system for the facility. You also get to add products that will be required for the task- like the pipe and panel mounted socket shown here. As the system also includes an inventory of the products used, their quantity and costs, you will be able to keep an accurate record of the supplies as they as are used.

As such, the field workers will not have to keep coming back to the central office to get documents and reports of new tasks, or walk around with bulky files. When they are carrying out the job, they will also be able to keep the staff at the office updated about its progress, through the chat feature on the mobile app, taking photos and adding notes as required.

2. Staff Scheduling

With this approach, the perspective is basically: ?So I have a couple of jobs- which of my employees has time to handle them?? The FSM allows you to optimise your productivity- by ensuring that you get the most out of the staff work hours, and avoid cases of jobs going into overtime.

Follow these steps:

  1. Select ?Scheduler? from the left-hand side of the window. You will have a view of the workers of your company and how their day is planned out, and a summary of the unassigned jobs.

Here, you can tell whose busy, and who can have a new task assigned to them at the click of a button- which is far more effective than keeping on jotting down points in your diary or going through files of documents.

If the job has yet to be added to the system- like for the cases of new clients, simply click on the ?Add Job? button and key in its details.

2. Scroll down, you will see a list of unassigned jobs.

unassigned jobs

3. Next, click on the edit button under ?Actions?. This will take you to the same ?Update Job? window described in the first approach, in order to assign the preferred worker to the role.

This real-time dispatching avoids cases of your desk getting cluttered with paper sheets, and prevents duplicate entries as each job has its own ID and task details- from the scheduling to the invoicing. In this case, your HVAC technician will have access to the information needed right at the palm of their hand, to ensure that the task at ABC?s head office goes seamlessly. The optimised schedule will enable the task to be carried out faster- restoring normalcy to your client’s facility.? In case the client’s location is on the route that one of your technicians takes while heading home, you can take advantage of this by giving them the task towards the end of their working day- thus clearing more of your backlog, sorting out your client, and easing your technician?s worries about getting home late.

As you can see, the field service scheduling software enables you to easily and efficiently handle your workflow, avoid the mess that is associated with manual documentation and cases of your employees getting conflicting schedules and overlaps- which would strain them and dampen their morale. Streamlining your workflow and standardising operations ultimately results in increased customer satisfaction.

Check our similar posts

8 Best Practices To Reduce Technical Debt

When past actions in software development return to haunt you…

Is your business being bogged down by technical debt? Let’s look at measures that you can take to reduce it and scale your operations without the weight pulling you back. 

 

Work with a flexible architecture.

Right from the word go, you want to use architecture whose design is malleable, especially with the rapid rate of software evolution witnessed today. Going with an architecture that keeps calling for too much refactoring, or whose design won’t accommodate future changes will leave you with costly technical debt. Use scalable architecture that allows you to modify or add new features in future releases. While on this, complex features required in the final product should be discussed at the planning stage, that way simplified solutions that will be easier to implement can be identified, as this will lead to less technical debt in the long run. 

 

The Deal with Refactoring 

This is basically cleaning up the code structure without changing its behaviour. With the updates, patches, and new functionalities that are added to the systems and applications, each change comes with the threat of more technical debt. Additionally, organisations are increasingly moving their IT infrastructure from on-premises facilities to colocation data centres and deploying them on the cloud. In such scenarios, some workarounds are often needed to enable the systems to function in the new environments, which they hadn’t been initially developed to accommodate. Here, you will need to take some time to refactor the existing system regularly, streamlining the code and optimizing its performance – and this will be key to pay down the tech debt. When working with a flexible architecture from the start, the amount of work that goes into this will be reduced, meaning there’ll be less tech debt involved. 

 

Run discovery tests

Discovery testing essentially takes place even before a line of code is written for the system or application. This takes place at the product definition stage, where human insight software is used to understand the needs of the customer and is particularly helpful in setting priorities for the development work that will be carried out. It gives your business the opportunity to minimize the technical debt by allowing customers to give you a roadmap of the most pertinent features desired from the product. 

 

Routine code review

Getting a fresh look at the product or application from different sets of eyes in the development team will improve the quality of the code, thus reducing technical debt. There’s a catch though – this should be planned in a convenient way that doesn’t end up becoming a burden for the developers. Here are suggestions:

● Break down pull requests

Instead of having complex pull requests where numerous changes in the code are introduced at a go, have this broken down into smaller manageable pull requests, each with a brief title and description about it. This will be easier for the code reviewer to analyse. 

● Define preferred coding practices

Documenting the preferred coding style will result in cleaner code, meaning the developers will focus their effort on reviewing the code itself, not losing time on code format debates.

 

Test automation

Relying only on scheduled manual testing opens you up to the risk of technical debt accruing rapidly, and not having sufficient resources to deal with the accumulated problems when they are identified. Automated testing on the other hand enables issues to be uncovered quicker, and with more precision. For instance, you can have automated unit tests that look at the functioning of the individual components of a system, or regression testing where the focus is on whether the code changes that have been implemented have affected related components of the system. However, establishing and maintaining automated testing will require quite some effort – making it more feasible for the long-term projects.

 

Keep a repository that tracks changes made

Do you have a record of changes made in the software? Keeping one in a repository that is accessible by the development team will make it easy to pin-point problems at their source. For instance, when software is being migrated to a new environment, or legacy software is in the process of being modernised, you will want to have an accurate record of changes that are being introduced, that way if there is an undesired impact on the system this it will be easier to zero-down on the cause.

 

Bring non-technical stakeholders on board

Does this conversation sound familiar?

Development Team: “We need to refactor the messy code quickly”

Product Team: “We have no idea what you are saying”

On one hand, you have the management or product team defining the product requirements, creating a project roadmap, and setting its milestones. On the other hand, there’s the software development/engineering that’s primarily focused on the product functionality, technical operations and clearing the backlog in code fixes. Poor communication between the two teams is actually a leading cause of technical debt.

For you to take concrete steps in managing your technical debt, the decision-makers in the organisation should understand its significance, and the necessity of reducing it. Explain to them how the debt occurred and why steps need to be taken to pay it down – but you can’t just bombard them with tech phrases and expect them to follow your thought process. 

So how do you go about it? Reframe the issues involved with the technical debt and explain the business value or impact of the code changes. Basically, the development team should approach it from a business point of view, and educate the management or production team about the cost of the technical debt. This can include aspects such as expenses in changing the code, salaries for the software engineers especially when the development team will need to be increased due to the workload piling up, as well as the revenue that is lost when the technical debt is allowed to spiral. 

The goal here is to show the management or production team how issues like failing to properly define the product requirements will slow down future software development, or how rushing the code will affect the next releases. That way, there will be better collaboration between the teams involved in the project. 

 

Allocate time and resources specifically for reducing technical debt

With management understanding that working with low-quality code is just like incurring financial debt and it will slow down product development, insist on setting time to deal with the debt. 

For instance, when it comes to the timing of application releases, meetings can be conducted to review short- and longer-term priorities. These meetings – where the development team and product team or management are brought together, the developers point out the software issues that should be resolved as a priority as they may create more technical debt. Management then ensures that budgets and plans are put in place to explicitly deal with those ongoing maintenance costs.

 

Retire old platforms

While most of the resources are going into developing new applications and improving the systems being used, the organisation should also focus on retiring the old applications, libraries, platforms, and the code modules. It’s recommended that you factor this into the application release plans, complete with the dates, processes and costs for the systems involved. 

 

Total overhaul

When the cost and effort of dealing with the technical debt far outweighs the benefits, then you may have to replace the entire system. At this tipping point, you’re not getting value from the technical debt, and it has become a painful issue that’s causing your organisation lots of difficulties. For instance, you may be dealing with legacy software where fixing it to support future developments has simply become too complicated. The patches available may only resolve specific issues with the system, and still leave you with lots of technical debt. Here, the best way out is to replace the system in its entirety. 

 

Final thoughts

Every software company has some level of tech debt. Just like financial debt, it is useful when properly managed, and a problem when ignored or allowed to spiral out of control. It’s a tradeoff between design/development actions and business goals. By taking measures to pay down your organization’s debt and address its interest as it accrues, you will avoid situations where short term solutions undermine your long-term goals. This is also key to enable your business to transition to using complex IT solutions easier, and even make the migration between data centres much smoother. These 8 measures will enable you to manage your technical debt better to prevent it from being the bottleneck that stifles your growth.

The Better Way of Applying Benford’s Law for Fraud Detection

Applying Benford’s Law on large collections of data is an effective way of detecting fraud. In this article, we?ll introduce you to Benford’s Law, talk about how auditors are employing it in fraud detection, and introduce you to a more effective way of integrating it into an IT solution.

Benford’s Law in a nutshell

Benford’s Law states that certain data sets – including certain accounting numbers – exhibit a non-uniform distribution of first digits. Simply put, if you gather all the first digits (e.g. 8 is the first digit of ?814 and 1 is the first digit of ?1768) of all the numbers that make up one of these data sets, the smallest digits will appear more frequently than the larger ones.

That is, according to Benford’s Law,

1 should comprise roughly 30.1% of all first digits;
2 should be 17.6%;
3 should be 12.5%;
4 should be 9.7%, and so on.

Notice that the 1s (ones) occur far more frequently than the rest. Those who are not familiar with Benford’s Law tend to assume that all digits should be distributed uniformly. So when fraudulent individuals tinker with accounting data, they may end up putting in more 9s or 8s than there actually should be.

Once an accounting data set is found to show a large deviation from this distribution, then auditors move in to make a closer inspection.

Benford’s Law spreadsheets and templates

Because Benford’s Law has been proven to be effective in discovering unnaturally-behaving data sets (such as those manipulated by fraudsters), many auditors have created simple software solutions that apply this law. Most of these solutions, owing to the fact that a large majority of accounting departments use spreadsheets, come in the form of spreadsheet templates.

You can easily find free downloadable spreadsheet templates that apply Benford’s Law as well as simple How-To articles that can help you to implement the law on your own existing spreadsheets. Just Google “Benford’s law template” or “Benford’s law spreadsheet”.

I suggest you try out some of them yourself to get a feel on how they work.

The problem with Benford’s Law when used on spreadsheets

There’s actually another reason why I wanted you to try those spreadsheet templates and How-To’s yourself. I wanted you to see how susceptible these solutions are to trivial errors. Whenever you work on these spreadsheet templates – or your own spreadsheets for that matter – when implementing Benford’s Law, you can commit mistakes when copy-pasting values, specifying ranges, entering formulas, and so on.

Furthermore, some of the data might be located in different spreadsheets, which can likewise by found in different departments and have to be emailed for consolidation. The departments who own this data will have to extract the needed data from their own spreadsheets, transfer them to another spreadsheet, and send them to the person in-charge of consolidation.

These activities can introduce errors as well. That’s why we think that, while Benford’s Law can be an effective tool for detecting fraud, spreadsheet-based working environments can taint the entire fraud detection process.

There?s actually a better IT solution where you can use Benford’s Law.

Why a server-based solution works better

In order to apply Benford’s Law more effectively, you need to use it in an environment that implements better controls than what spreadsheets can offer. What we propose is a server-based system.

In a server-based system, your data is placed in a secure database. People who want to input data or access existing data will have to go through access controls such as login procedures. These systems also have features that log access history so that you can trace who accessed which and when.

If Benford’s Law is integrated into such a system, there would be no need for any error-prone copy-pasting activities because all the data is stored in one place. Thus, fraud detection initiatives can be much faster and more reliable.

You can get more information on this site regarding the disadvantages of spreadsheets. We can also tell you more about the advantages of server application solutions.

Why DevOps Matters: Things You Need to Know

DevOps creates an agile relationship between system development and operating departments, so the two collaborate in providing results that are technically effective, and work well for customers and users. This is an improvement over the traditional model where development delivers a complete design ? and then spends weeks and even months afterwards, fixing client side problems that should never have occurred.
Writing for Tech Radar Nigel Wilson explains why it is important to roll out innovation quickly to leverage advantage. This implies the need for a flexible organisation capable of thinking on its feet and forming matrix-based project teams to ensure that development is reliable and cost effective.
Skirmishes in Boardrooms
This cooperative approach runs counter to traditional silo thinking, where Operations does not understand Development, while Development treats the former as problem children. This is a natural outcome of team-centred psychology. It is also the reason why different functions pull up drawbridges at the entrance to their silos. This situation needs managing before it corrodes organization effectiveness. DevOps aims to cut through this spider web of conflict and produce faster results.

The Seeds of Collaboration

Social and personal relationships work best when the strengths of each party compensate the deficiencies of the other. In the case of development and operations, development lacks full understanding of the daily practicalities operating staff face. Conversely, operations lacks ? and should lack knowledge of the nuances of digital automation, for the very reason it is not their business.
DevOps straddles the gap between these silos by building bridges towards a co-operative way of thinking, in which matrix-teams work together to define a problem, translate it into needs and spec the system to resolve these. It is more a culture than a method. Behavioural change naturally leads to contiguous delivery and ongoing deployment. Needless to say only the very best need apply for the roles of client representative, functional tester and developer lead.

Is DevOps Worth the Pain of Change?

Breaking down silos encroaches on individual managers? turf. We should only automate to improve quality and save money. These savings often distil into organisational change. The matrix team may find itself in the middle of a catfight. Despite the pain associated with change resistance, DevOps more than pays its way in terms of benefits gained. We close by considering what these advantages are.

An Agile Matrix Structure ? Technical innovation is happening at a blistering rate. The IT industry can no longer afford to churn out inferior designs that take longer to fix than to create. We cannot afford to allow office politics to stand in the way of progress. Silos and team builds are custodians of routine and that does not sit well with development.

An Integrated Organization ? DevOps not only delivers operational systems faster through contiguous testing. It also creates an environment whereby cross-border teams work together towards achieving a shared objective. When development understands the challenges that operations faces ? and operations understands the technical limiters – a new perspective emerges of ?we are in this together?.

The Final Word ? With understanding of human dynamics pocketed, a DevOps project may be easier to commission than you first think. The traditional way of doing development – and the waterfall delivery at the end is akin to a two-phase production line, in which liaison is the weakest link and loss of quality inevitable.

DevOps avoids this risk by having parties work side-by-side. We need them both to produce the desired results. This is least until robotics takes over and there is no longer a human element in play.

Ready to work with Denizon?

Contact Us Today