Join us for a month-long contest with heaps of swag to win!Learn More ›
So my company has been playing around with the idea of mobile scheduling and eventually payments. It is a home health care company and schedule right now is all done via paper and payment via paper also. They have a software engineer who does there payroll system developing an app that would basically verify the home care aid was at the clients based on their location.
While there are iPads in the offices with some of the office staff it has been talked about bringing iPads or another tablet into the field. It may be the right time, as we are concerned with payment security (if we add that feature) and employees view on having our scheduling app (requiring location) on their own, personal, device. While we have had discussions about it, our main problem is employee turn over, the nature of the business. There are also problems that come along with deploying iPads in the field, cellular data a big one.
To the point: How is cellular data management? If we do go the route of piloting tablets in the field at HQ I think this is going to be a hurtle. I am personally (if you live in the US) a huge Verizon fan, but I think something like T-Mobile or Sprint for this program might work as well (from a cost standpoint). If we go with unlimited we will probably allow aids to load their own content or I will make apps available in SM, if not I think it is going to be pretty restricted.
I am not really concerned with the device management part, as I have that down pat.
Thanks for any input,
I was just looking into scheduling software for another company. Check out this cloud app:
I bet if you take a look around you'll be able to find a pre-made cloud app that does most of what you want ...
Systems Manager can generate alerts based on cellular data usage. I have that deployed and it seems to work fine.
Personally, I wouldn't use "personal" devices for business for field use. Knowing that you are an Apple man, I would look at something like the iPad Mini 4G. And I would pretty much set it up to run just your one app, and then you wont have any issues with data usage. It is a business asset, and staff should not be using it for personal reasons. You don't see McDonalds let staff cook their own dinner in their kitchen do you? You don't see Toyota letting staff build their own car do you?
The other approach I see companies using is is to pay staff an allowance. They then supply their own device and data plan. You just then give them the app. In this scenario you don't care what they do with the device any more. However you have to make it clear there are consequences if they put themselves in a position where they can not do their job.
@PhilipDAth Thanks for the insights! Our goal isn't to be jerks with restrictions, being a home health care company it is basically sitting with clients and helping them when needed. Most of our nightly aids will do the reading, so allowing them access to iBooks and other business apps (not entertainment - i.e. Netflix) would not be an issue.
We briefly talked about it today, but it is an idea we have always been cautious with because of the turn over in aids. If we go this route I believe we will pilot between 10 - 15 different devices, including androids.
We have gone to the router of designing the software ourselves because it would incorporate directly into our payroll and scheduling software. Payments won't be apart of the first app, it is only going to be check-in/out for aids and doing that via geolocation.
I have developed mobile applications for use by clinical staff and regularly work with high speed streaming telemetry. As a matter of course, I now assume that connectivity will be intermittent and that the portable device should synch with the remote servers when the link becomes active, that is asynchronously. So the changes will be replicated. Systems which are dependent on uninterrupted and continuous connectivity are rarely successful. Even in a controlled environment such as a hospital there is no guarantee that connectivity will be continuous.