As a designer on the UX team, I am currently working on improving the overall mobile experience on the new FSA phone app for iPhone and Android by creating more targeted screens for technicians out in the field. For this post, I am specifically seeking feedback around reporting technician activity on any given work order.
With the upcoming release of FSA iPhone/Android, we are introducing a notion of capturing technician activity under "Your Activity". I'd like to share the concept design with you to better understand how well this might support your technicians' current workflow:
In addition to your thoughts on this concept, I'd love to know:
- Do your technicians currently report their status within the FSA app? If so, how?
- How well does reporting technician activity fit into your business needs?
- How well does this interaction fit into your technicians' workflow?
Again, I'd love to get your thoughts on this as the mobile team continues to work hard to shape a better experience for technicians.
We currently use a custom picklist field called 'order status' to track these status changes. The primary tech is the only one who can change this field. The field value is set by a series of SFMs.
We have encountered limitations in this as far as more than 2 trips to the site by the primary cannot be accounted for, nor can secondary techs indicate order status. Also, the sync on the FSA does not always catch the order status change which does lead to issues with any functionality built behind the changing of the order status (e.g. SFM availability, approval processes, work flows).
I would recommend building in the ability to track more than 1 techs activity status as well as to account for multiple trips (if a part is needed for return or its a multi-day project - primary or secondary) under one WO.
Thanks for your input, Adam Homoly .
Could you tell me more about the scenario of technicians having to take multiple trips?
- Does this happen often?
- Does the primary technician need visibility into the secondary technician's activity?
- How are multiple trips accounted for today? Or how could it ideally be accounted for? (e.g., put on hold, onsite until work order can be marked as complete, etc.)
Could you tell me more about the scenario of technicians having to take multiple trips?
- Does this happen often? - Yes, especially for installs or larger projects or when an ordered part comes in as DOA from the supplier.
- Does the primary technician need visibility into the secondary technician's activity? - Yes, as well as the dispatcher and service manager.
- How are multiple trips accounted for today? There is a SFM used by the primary to place the WO in 'Requires Revisit' status with a pick list to indicate the reason for the revisit (secondary's are unable to influence the order status, which can lead to issues - especially if the primary techs work is complete but the secondary needs to return). Once the criteria has been met to return to the site, the dispatcher has to reassign it to a primary in order for the WO to be furthered processed. Once the work is complete, the primary uses another SFM to change the WO to 'WO Complete' status and the WO enters an approval process.
Or how could it ideally be accounted for? (e.g., put on hold, onsite until work order can be marked as complete, etc.)
We basically have the same set-up as Adam reported, some of the naming conventions are different but process appears to be the same.
As for showing Multi tech's that are dispatched on a single WO, we had to create custom Apex code/triggers for this. It's fine that you can show it in the DC, though on the WO and emailing the proper alerts to all parties is severely lacking and should be a SMAX OOTB solution.
Yes, our field service reps (FSR) do report all status via Work Order ‘Field Status’ field. This is critical for our service flow
In our implementation of ServiceMax we use Work Order ‘Field Status’ and FSR sets it first to ‘Accepted’
If for any reason FSR can’t take the call, then ‘Field Status’ is set it to ‘Rejected’
When FSR is ready to travel to customer site, the ‘Field Status’ is set to ‘Travel’
Once at customer site the ‘Field Status’ is set to ‘On-Site/On-Call’
If FSR needs to go back next day to customer site, they set ‘Field Status’ to ‘Further Action’ and then selects from list of ‘Further Action Reason’
Above is done either on iPhone ServiceMax Winter’18 App or on FSA running on window-based laptop computer.
Service Process Integrator
BD Life Sciences
Thanks for sharing, Aleem Khawaja.
It's very helpful to know that FSRs are able to set the 'Field Status' as 'Rejected'. Is there any follow-up/reasons FSR needs to provide for rejecting a call?
Is there a status for when the work order is complete? And if the FSR needs to return to the customer site, does the 'Field Status' remain as 'Further Action' until it is marked as complete?
It's very helpful to know that FSRs are able to set the 'Field Status' as 'Rejected'. Is there any follow-up/reasons FSR needs to provide for rejecting a call? >>> Yes, if FSR Reject a WO, they need to provide a Reason For Rejection
Is there a status for when the work order is complete? >> Yes, WO’s “Field Status” is set to ‘Closed’
And if the FSR needs to return to the customer site, does the 'Field Status' remain as 'Further Action' until it is marked as complete? >> Yes
How does the above flow allow a technician to add another labor line of lets' say activity "QA" from 5:00PM - 6:00PM after entering the repair line? Thanks.
Hi Steve Mintz,
Thanks for your question. This is something I haven't designed for yet so I'd love to get more background from you to better understand the scenario. However, at first thought, the above flow would suggest that a technician would add a Labor line of QA 5:00PM - 6:00PM to capture that work being done. And this would be done outside of the above flow. Alternatively, if "QA" is an activity that is often used, it would be configured to be part of the Your Activity menu.
I'm working with a prospective customer that has their technicians log labor to a number of activities that might have different rates. So a technician day might include a number of activities:
Hello Judy Wu. Thank you for sharing your mock-ups. This is really helpful to see where things are moving.
Firstly, I like the use of white-space- it makes things easy to see the information even on small screens. I also like the large easily distinguishable 'Accept' button. Our engineers are accepting work orders often while they are on the move (walking, loading, even driving). I like how the Accept button is easy to click with a thumb while holding the phone in one hand. I imagine similarly, that there would be a Reject button as well, and possibly a Schedule button for instances where the engineer is responsible for scheduling the exact time with the end customer?
These are all SFMs which we are currently using on the Salesforce1 app while we wait for the FSA iPhone app to be released. Additionally, I'd like to see a conflict management feature which warns the engineer about accepting a work order if he/she has a directly adjacent or overlapping event at the same day/time. Engineers are on the go and may not necessarily be checking their calendars before they click accept especially if the work order is a few days off, or if appointments are adjacent times, but technically impossible to get to in time because of traffic conditions. Can we build in a warning to the engineer that there is a potential conflict? Alternatively, can we have a small icon link to directly open the calendar to check availability?
p.s. Accept has an extra 'c' in the button mockup
Hi Michael Majerus,
Thanks for your feedback and for catching that extra 'c'. And also thank you for your patience while FSA iPhone is underway. It will be worth the wait!
It's very helpful to hear the environment your engineers are in when interacting with the app. Knowing that engineers are usually on-the-go is definitely driving more explicit actions and controls from our end.
So, to put a little perspective around the screens above, the screen previous to this one is the Calendar. An engineer should then see a conflict in the Calendar before coming to the screen above to 'Accept' or 'Reject' it. However, I do see value in exposing conflicting event information on this screen. Please stay tuned as this screen will go through more refinement with your feedback.
Hi Judy Wu, we have a field called Order Status with values of
- In Transit
- Arrived Started
We use SFMs to allow the Technicians to Change Status.
Functionality like this should have the ability to add our own statuses as well as to select which of the pre configured statuses we wish to incorporate into our workflow. For example we may not want to allow the Technicians to reject Work Orders.
This will be key functionality for most ServiceMax customers and your mock ups look good.
Regarding the flow between statuses it would be necessary to be able to set custom criteria to enable each step, maybe a standard criteria included which could be modified if needed or just used out the box if not. For example you can't go in transit after you are already onsite.
Another piece of functionality would be to be able to adjust the times you wanted to record each of these status changes if you have to back date the updates. Possibly with one click to set yourself as travelling but a hold on the button to display a more detailed screen where you could put a note or change the time being logged etc, configurable depending on what fields each customer wants.
We create a Work Detail to track our labour and another to track our travel. Is it in scope to have this auto created and updated as a result of these status changes. It would be great to move to out of the box functionality for this.
So starting travel creates the travel work detail and sets the start time. Then arriving at the customer sets an end time on that work detail and creates a new one for labour and sets the start time. Then marking the job as complete sets the end time on the work detail.
Allowing this to be configurable to account for items like wrench time, training time, testing time, diagnosis time etc would be great. These would be statuses you could include or we could add ourselves. But we would be able to configure an auto creation and/or update of existing work detail for each status change we required this on.
More than happy to discuss this further with you if needed.
I think a design time session in the future would be great for this change.
Hi Richard Lewis,
Thanks for taking the time to share your feedback! You bring up a lot of great points. The only thing I can speak to as of now is that the activities will be configurable so that, for example, if your business does not support rejecting a work order that option will not be there. Additionally, while the above concept is designed to help track labor and travel, it won't be the only way to add/edit labor and travel lines.
Please stay tuned as we use your suggestions to refine this experience!
It would be helpful if we could also display the acknowledgement SLA for a work order on the screen. It would be good to indicate to the tech how far they are from breaching the SLA to "Accept" or "Reject" a work order assigned to them.
Hi Judy, I share much of the same feedback as Richard. I really like the idea of being able to track what the engineer has done as this gives them visibility of where they are in the process. I particularly agree with Richard on Travel and labor time which is a real issue for us in terms of preventing overlapping labor and I am hoping this will be solved by capturing the time stamps as Richard alluded to above so we can drive the start and end times of labor.
Hi, in the project I'm working on we have a requirement where the FSRs report each and every activity they do.
The data reported (and stored on the server) contains not just the start/end date of the activity ("Travel for WO-12345 from 12:00 to 12:45"), but also the geo-localization of the activity ("started at (x,y), ended at (z,w)"). So the mangers know exactly how long and where the FSRs where while performing some specific activity. The activities are time-stamped and geo-localized.
Moreover, this kind of activity-reporting from mobile can be done for productive activities (linked to a WO) and for non-productive acitivities (lunch time, break time...) The goal is to have a full visibility on what, where and when our FRSs are doing, so we can take better decissions and pay productivity bonus.
Thank you for sharing! It's helpful to know the kind of activities FSRs need to report in the requirements you're working with. Is the type of activity-reporting you described something FSRs are able to do today in the ServiceMax mobile app?
Hey Judy, the functionality described exists today in their legacy services system, not in ServiceMax. Actually we need to see how the timesptamp+geolocalization of activities reported by FSR can be done in ServieMax, this is why the solution you are working on sounds interesting for me...
HI Judy Wu, we have discussed a lot of great changes on this thread. Will they be made available for the FSA iPad app as well?
I really like the ability for any engineer to to quickly set a simple status of where there are in the job flow, e.g travelling to site, on-site, travelling home, office etc, but it would have to be extremely easy for the to set, if we were to get buy in from the users.
Our business model, doesn't really support a WO being accepted or rejected, but a WO received acknowledgement would be useful.
As mentioned, using the change in status to create WO lines, for travel for instance is a great idea, but i would worry about the accuracy of the date, when having to rely on user having to set the statues manually, so the ability to edit the data afterwards would be a must for us.
totally agree with Russell, we use a kind of workflow in our current app that guides the Tech through the steps, but a "click one button" could improve efficiency as long as any fields that could be defaulted are defaulted for them.
If this can be designed the same way as our SFM's are currently set-up ( I assume this can be done) for MFL, where "one click" on the Accept Work Order SFM, sets by default the current date/time as well as the Order Status. In this example, the Accept Work Order button, the FSE clicks and it sets the Order Status to Arrived (on-site) along with the current date/time stamp.
In turn, this sets our custom Actual Arrival Time field with the current date/time that was set per the above action. We then can use this field as part of our SLA's.
Hello Judy Wu
I really like the concept of being able to track the status changes during the lifecycle of a work order and then to possibly set up some conditions in the dispatch console so those work orders will change in colour according to the status.
It seem that this will be dependent upon the technician clicking on a button to change the status though, am I correct in this thinking? Nothing wrong with that but personally I would like to see that this then not only changes the status but also uses the time stamp for creating the Work Detail, which them reduces the amount of inputting needed by the technician.
Technician clicks on a buttons
"Start Travel" at 07:00
"End Travel" at 08:30
"Start Work" at 08:30
"Finish Work" at 15:00
"Start Travel" at 15:00
"End Travel" at 16:30
This would then not only give instant feedback about the Work Order status, but will also be capturing all of the Work Details, without the technician needing to scroll times and dates backwards and forwards.
Travel - 1.5 Hours
Work - 6.5 Hours
Travel - 1.5 Hours
I'm not sure if this thinking is in line with what you already have in development is it?