How to build Android consumer electronics, part three
In the first two installments of our series on building excellent Android consumer electronics, we talked about why Android is a good choice for CE projects and how Esper can help you get there, so in the final (and shortest) installment, we’re on cleanup duty! Not really, but as you’re starting to put together a real product vision, there are a few things you need to consider downfield, like customer support, data intelligence, and choosing the right suppliers.
This post is part of a series:
Customer support is consumer support
Consumers: They’re not your employees, ready to work through the IT Help Desk. If they have a problem, they want it fixed — now. In a perfect world, you know about that problem before they do, and you fix it with a quick and quiet update they (hopefully) don’t even notice.
Sure, you can harness your APK with services like Crashlytics. But what about the Android OS? Esper provides a base set of telemetry spanning system resources and wireless and network connectivity you can monitor. We are also releasing support for SNS (Simple Notification Service), so you can implement webhook-like notifications for efficient systems operations against alerting conditions of your choice. And with Esper’s own Android-based OS, we offer a system telemetry service that lets you go to exactly what you want to monitor from our Android-powered OS, so you’ll know what’s going on before your customer base reacts. Identify issues before they become problems, patch them before customers make them even bigger problems, and get back to improving the product — this is how it should be!
With Esper’s API driven approach, you can build integrations into tools like Salesforce, and CSRs (Customer Support Representatives) can efficiently work with the specific device a support incident is related to. You can also scope what configuration change capabilities are made available to CSRs, as well as a limited but curated set of device telemetry. Remote control and bug reports are available through the Esper platform, improving the support experience and the break/fix cycle. Seamless remote control, screenshots, and bug report generation and delivery are built right in to the Esper platform and our OS.
And then there’s secure remote adb. With Esper’s Android-based OS, you can start an adb session on any device in your fleet — whether in the test lab or deployed to a customer in Nome, Alaska.
Gaining Intelligence to drive product innovation
Direct support is paramount, but gaining the intelligence necessary to support your customers before they know they need you means harnessing the power of device data to take action before they do. Your APK should leverage a telemetry stream to gain insight into product usage inside the app experience, but the Android system itself is a data black hole. Not so with our version of Android. If there are system events that are useful to track and populate into your data lake, you can pipe in and stream them from our OS. And if a telemetry set is missing, we can work with you to add it into our platform.
Fun at the factory
Building devices in China or Taiwan is interesting, to say the least. We’ve seen quite a few “interesting” things — validation tools that are set as device owner, using the same serial number for all the devices made on a run, funky model strings, dealing with the Great Firewall. This is all part of the checklist you should go through with perspective vendors before you sign on the dotted line.
Once you are settled with your supplier, though, we’re there to help get you through the trial and tribulation of the first article and the struggle to get to mass production. Once COVID settles down, we look forward to regularly going onsite for initial production. Right now, we’re doing this for customers that stage devices in the United States, and they love it. But given we’ve seen a lot, both going in and during the production process, we’re ready to help.
Golden rules for the golden ARR
If you are a CE company using Android driving recurring revenue, you have to have control of your Android image. Returning to my example in part one of the series, If Jawbone had to go through an ODM to make modifications to firmware, the Jambox product would have been subpar. (Noting that Jawbone would have never shipped such a thing, given their focus on excellent user experience.)
If your device maker holds the keys — your device’s Android firmware image — your ability to innovate is dramatically curtailed. You’ll be largely unable to work with third parties to enable Android OS level integrations and features, because your firmware under the complete control of the ODM. (And by the way: ODMs generally don’t have recurring revenue in mind, so business objectives are severely misaligned with the notion of a continuously improving and highly updateable product.)
I’ve seen too many products slip for this very reason. Device makers have their own agenda, mapping to their one-and-done business model. You need to get access to the Android source, and do so in your contract during the initial negotiations. If you don’t and sign, the answer may be a no, leading to a months-long schedule protraction — or a substantial fee your initial budget didn’t account for.
Finally, you need a management platform. Sure, you can do it yourself, but you’ll reach a point when your R&D investment in management is such that you find yourself skimping on product innovation. Instead, we propose you rely on Esper (shocking, I know) to provide your management platform, betting on us to be at the forefront of innovation so you can continue to lead in your use case and cement and increase the subscription monetization of your customer base.
We’ve gone through a lot here, but there’s much more. What you are doing is complicated, lucrative, and exciting. Contact us to see how we can help.