Reducing time-to-first-track with HyperTrack

We have rolled out the following enhancements to our APIs to make it easier and more flexible to integrate with HyperTrack. If you are already integrated with HyperTrack, everything will continue to work as usual. You can choose to use these enhancements if it fits your use case better or if it simplifies your current integration.

1. Destination is optional when creating a task: Our users wanted to track a task without a specific destination or with an open-ended destination to be added later. In some cases, users wanted to get the end customer to start tracking the task and add/confirm destinations on their own. This enhancement enables all of these use cases.
2. Trip is optional when starting a task: Based on the usage so far, we discovered that the most common use case for tracking is a trip with a single task. Starting and ending a task imposed an overhead on the user to start and stop a trip. This enhancement removes the overhead and simplifies the use of the API for the most common use case, yet allows tracking of trips with multiple tasks. Thus “making easy things easy and hard things possible”.
3. Trip can have unordered tasks: Many of our users wanted to assign multiple tasks to a trip in no particular order and subsequently decide the order when the trip was in progress. This order could be determined by the driver or the system, one-at-a-time or as a comprehensive route plan. Starting a trip with ordered tasks and then adding, removing, modifying tasks added an overhead on the user at the start of the trip and then at every change in plan. With this enhancement, users can now start a trip with unordered tasks and then start and end each task in any order while the trip is in progress. If users choose to provide an order of tasks, they would get ETAs for all subsequent tasks scheduled after the next one. “The more you give, the more you get”.
4. Starting a task returns the tracking URL: The tracking URL is now part of the task object. This means you do not need to make that extra API call to get the tracking URL.
5. Track a shift when the driver is idle (not performing a task): Many users requested the feature to track the driver while idle and not performing a task. Besides making assignment decisions based on the closest idle driver, our users wanted to see the polyline for where the driver had been when idle. Users can now switch on tracking when starting a shift. This will result in battery optimized tracking that would not be as real-time yet as accurate as tracking a task. Like tasks, polylines for shift tracking will be stored and displayed on the dashboard. Why? “Because shift happens”.
6. End customer can track multiple tasks in the same map view: Users requested the feature for the consumer SDK to track multiple tasks simultaneously. And then came Pokemon Go. Serendipity? We think not.

I hope you will find these enhancements useful. The feedback from our early users has been invaluable as we have been building HyperTrack. We will continue to enhance our APIs in order to provision the tracking features that our users want in order to monitor their workforce and power a great customer experience.

If you are considering HyperTrack, signup for the APIs and track your first task today.