My goal with this upcoming series of posts is to go through the process of creating an AppSheet application to help streamline a small service business.
Bear with me through Part 1. It’s a bit long and wordy. The purpose, though, is to show you how to get down on paper (or screen) an idea of how your business processes will flow within your AppSheet app.
Start by figuring out your inefficiencies
We’ll create an imaginary HVAC service business, we can call it GTA HVAC Services. Let’s say it services the greater Toronto area in Canada, has 10 mobile technicians, each with their own company supplied service vehicle and parts inventory. Office staff would include a dispatcher/coordinator responsible for managing day-to-day of the field technicians and a shipper/receiver responsible for managing the overall company parts inventory.
GTA HVAC Services currently utilizes paper based work orders for all technicians. Any incoming calls to dispatch are written on a paper-based work order, physically given to the appropriate technician, filled out upon completion of a call and then physically given back to the dispatcher. GTA HVAC Services, from this point on known as GTA, has recognized several inefficiencies with this process.
- The dispatcher will often have to “chase” technicians to get work orders back in a timely fashion with good information.
- Getting mid-day work orders into the technician’s hands requires non-billable drive time back to the office.
- Different technicians will often call the same parts different names leading to confusion when allocating inventory to jobs and invoicing parts.
GTA has decided to use the AppSheet platform to create and test a work order application with the objective of improving these three inefficiencies.
Thinking about information/workflows in an AppSheet app
So what’s this look like? How do we get started? Let’s break it down into a few initial steps.
- Determine what information is important.
- Determine the type of information each employee needs to see.
- Determine what the work flow looks like for each employee.
OK, so let’s start with the first and second steps as they go hand in hand.
The dispatcher should ideally have an overview of everything that’s happening. All open and closed work orders, the location of each of the 10 mobile technicians, the parts inventory on each of their vehicles and shop parts inventory. To have a real time or even close to real time overview of these items would go a long to improving our big three inefficiencies.
The shipper/receiver should have a view of the current overall inventory, including how it’s dispersed between shop and different service vehicles. They should also have a view of any open purchase orders. A formalized, barcode based process would be important to improving this part of the business and allowing it to scale.
Each mobile technician should be able to see their open and closed work orders. GTA believes their main focus should be to execute on site work, other items within the application could become a distraction. Info input from the dispatcher is important. Customer address accuracy and a good description of the dispatched issue go along way to setting up the technician for success. A tie-in to the shipping/receiving barcode system would reduce errors allocated inventory.
So this gives us somewhere to start. Things grow and change over time of course, but we now have a simple outline for what type of information each employee type needs.
So the third step would be to figure out how the information we’ve identified as being important in steps one and two can flow efficiently.
I know the wisdom of our time says organizational hierarchies are passe. When thinking about workflows within AppSheet they can still be helpful. We can imagine our dispatcher and our shipper/receiver as the foundation of our “pyramid” and our ten technicians above them. Those at the base of the pyramid, when operating smoothly, setup those above to succeed. And, as you know, a weak crumbly base will bring the top of the pyramid crashing down. We don’t want that. So let’s just brainstorm a bit.
How can we ensure the base is strong?
The dispatcher needs an easy way to enter a work order in our application and an easy way to decide which technician to send the order to. This should take very little time or thought on the part of the dispatcher. If a job is to be scheduled requiring inventory parts or special order parts, the dispatcher should be able to tell from the application if the parts are available and where they are. A basic workflow then should have two prongs for the dispatcher. An “emergency” call workflow that allows the dispatcher to easily enter a work order and dispatch it to a chosen technician. There should be a reverse workflow that allows the technician to send the completed work order back to the dispatcher for close out and invoicing. There should also be a “scheduled, parts required” call workflow that allows the dispatcher to see when parts are available for an open ticket. Again, there should be a reverse workflow that allows the technician to send the completed work order back to the dispatcher for close out and invoicing.
Let’s move to our shipper/receiver. The position requires an easy way to enter purchase orders for both inventory and job specific orders. It also requires an easy way to receive the orders. Both of these processes have to be tightly integrated with dispatcher processes for visibility. The shipper/receiver also needs to have a near real-time view of parts inventory in any location. Ideally this would flow such that when a technician’s vehicle is low on a required part, the shipper/receiver is alerted so the parts can be pulled for pick up by the technician at the beginning of the next work day. We’ll leave it at this for now. If we can get this to work out, we’ll be way ahead.
Probably most important, is the technician’s workflow. As GTA bills out its technicians on a time and materials basis, this workflow must be optimized. It’s critical the work order arrives on the technicians device with the proper information. Customer addressing and contact information need to be proper. There needs to be a notification system in place so the work order isn’t missed. The work order needs to be intuitive and easy to fill out. It can’t be frustrating to use. Having access to information about the equipment on site and the ability to send equipment info back to head office would also be beneficial. This is more of an information requirement but ties into the flow in terms of how the technician prepares for the call. Once the billable time for a call has ended, a single button push or screen tap should enable the call to be closed and trigger a work order to be sent to the dispatcher.
Where do we go from here?
This is all a bit dense and messy but it’s important before starting to build your AppSheet app that you have an idea of where you are headed. Putting it all on paper is a good way to process your thoughts. It doesn’t have to be perfect, it just needs to be a clear starting point once complete. It will save you significant time as you build. And, as we all know, time is money.
We’ve fleshed out what we think we need at this point. Moving forward, the series will be more of a how-to structure. We’ll start with how to build a data framework for your application!