Best Practices for Controlling Devices Successfully with Your Smart Home Skill

When it comes to customers adopting your Alexa skill for daily use, reliability is vital. How much success a customer has with your skill can lead to a gain or reduction in customer engagement. One way to measure how your skill’s reliability is to monitor your control success via the Alexa Developer Portal. The Analytics tab has a section called Capability Directives; striving for a success rate >80% on all directives will provide the best customer experience. Below are six recommendations to improve your control success rate.

1. Update the skill’s supported Alexa interfaces to the latest version: By supporting the latest message version of each Alexa interface, your skill can leverage all the new features customer would come to expect from Alexa. As of this writing, most Alexa interfaces are on v3 but please verify with the current documentation https://developer.amazon.com/en-US/docs/alexa/device-apis/list-of-interfaces.html. The current Alexa interface version provides a new “properties” object which expand/limit the features Alexa can interact with your skill, as well as provide state reporting to customers.
   
   
2. Device Friendly Name Best Practices: The customers’ chosen friendly name for their devices is the key to success whenever customers are trying to control a devices using Alexa. Complex friendly names can lead to a higher control failure rate due to Alexa’s expectation of the device name vs. other device management portals. To ensure the best customer experience, we recommend the following:

a. Proactively update your device friendly name: Supporting proactive endpoint management and sending proactive updates with AddOrUpdateReport will update a device’s friendly name within Alexa. We suggest the following scenarios for maintaining an updated friendly name:

• Device name gets updated by an external management portal, send AddOrUpdateReport with the most recent friendly name
• Device name gets updated in iOS or Android app, send AddOrUpdateReport with the most recent friendly name
• Device gets deleted from an external portal or app, send DeleteReport so Alexa knows the device isn’t available anymore
• Here's the latest documentation on how to proactively update and manage your endpoints: https://developer.amazon.com/en-US/docs/alexa/smarthome/how-to-proactively-manage-endpoints.html
  
  

b. Defining Friendly Names: Review the friendly name being sent to Alexa as this is a key identifier when trying to control Alexa. Simply and easy to remember device names will lead to higher success and enagement of your skill:

• Do not include model number, year, or type within the friendly name
• Refrain from using duplicate words and special characters in the  friendly name
• Provide a valid friendly name if the customer doesn’t provide one and follow the rules above
• Here's the resource documentation for friendly name: https://developer.amazon.com/en-US/docs/alexa/device-apis/resources-and-assets.html

3. Be aware of device power mode limitations : Depending on the design of the device, there is often a limited power/energy saving mode which can limit connectivity of a device. If your devices have limited cloud connectivity due to dormant states, follow the suggestions below to handle Alexa requests and prevent future errors:

A. Enable dependencies upon Skill Enablement: Review all settings for your devices and see how each setting can affect each capability with Alexa. The most common settings that can impact Alexa reliability are power and network related.

- For AV devices that can’t maintain an active IoT connection and want to conserve energy by keeping devices in a low power state; adopting Alexa.WakeOnLANController allows for locally connected devices to receive a power on command without a direct cloud connection. This would allow for devices components to maintain a minimal power consumption state until the device is fully active. Documentation can be found in the following link: https://developer.amazon.com/en-US/docs/alexa/device-apis/alexa-wakeonlancontroller.html

B. Report Low Power Error for Supported devices: If your devices support batteries, ensure your devices are reporting the Low Power Error Response to notify customers of their device state. This provides customers with a proactive notification as well as a reminder.

C. Device Connectivity Updates: Proactively reporting the devices connectivity status with the interface Alexa.Endpointhealth can notify the customer when the device is having connectivity issues. This can be tied to the IoT heartbeat of the device. Reporting that the endpoint is unreachable can notify customers via Alexa or the Alexa App. For details, please see the latest documentation:https://developer.amazon.com/en-US/docs/alexa/device-apis/alexa-endpointhealth.html
 

4. Control Execution Suggestions for Alexa: Customers expect a prompt execution and feedback when they make requests to Alexa. Once Alexa sends a request to your Lamba, an 8 second timer starts which can result in a timeout if a response event hasn't been sent back to Alexa. Waiting a full 8 seconds can yield a poor customer experience if the Alexa request fails. Customers expect a response in <2 seconds to update them on the status of their request. Optimizing the control execution and response will provide the best CX to inform and update the customer. We recommend the following to speeding up the execution:

A. Initial Database Queries: Depending on the size of the customer base, querying each additional database can add additional latency to the request. A couple of tips would be to remove redundant databases queries and to run a query optimizer on your databases to speed up the execution; you may choose to use AWS Redshift optimizer: https://docs.aws.amazon.com/redshift/latest/dg/c-query-analysis-process.html

B. Limit Round Trips: Be aware of where each component is when customers are trying to execute a request with your skill as the latency caused by the distance between device, 3P cloud providers, and Alexa can increase exponentially and exceed the 8 second timeout. For Alexa requests that are more resource intensive, acknowledge the request from Alexa with a response, and send an updated change report once the device has successfully processed the request.

C. When to send a Response: Customers expect feedback from Alexa once a command has been placed. Depending on the device type, this can take more than 8 seconds. Once the skill has received a device control directive from the cloud or Alexa, send a response acknowledging that the command has been processed and is being executed by Alexa.
 

5. Successful Alexa Request: Providing a success response event once a device has executed the directive/request is key to providing customers with the status of their command. Customers expect to hear feedback from Alexa such as “OK” or “I can’t do that” as an acknowledgement that she processed their command. At a minimum, we recommend the following so Alexa can provide customers with an accurate response:

A. EndpointID: This is a required field so Alexa can verify a customer request has executed successfully for a particular device. Missing this within the response event can result inaccurate responses to customers.

B. Synchronous vs Asynchronous response: Verify if your directives are synchronous or asynchronous request, providing asynchronous responses without access token and endpoint information will not processed by Alexa. As a result customers wont receive a confirmation their Alexa request was completed or successful.

C. Context State Reporting: Providing valid state for each interface ensures Alexa has the valid context and information on the device to provide accurate responses. Refer to each individual interface documentation to provide a valid response and state: https://developer.amazon.com/en-US/docs/alexa/device-apis/list-of-interfaces.html
 

6. Failed Alexa Requests and Responses: When Alexa requests fail, providing accurate error responses can give customers insight into what error has occurred and possibly even how to resolve it. Failing to provide any error response could result in a poor customer experience as they would have to wait a full 8 seconds to discover that Alexa failed the customer’s request. Providing a quick response such as “Endpoint Unreachable” notifies the customer there is a connectivity issues with the device and they should investigate. In addition to educating the customer on the issue, providing the proper error response gives developers extra details which can be reviewed within Alexa Developer Console error logs. 

A. Smart Home specific error responses located in:https://developer.amazon.com/en-US/docs/alexa/device-apis/alexa-errorresponse.html

B. Entertainment team have specific error responses located in: https://developer.amazon.com/en-US/docs/alexa/device-apis/alexa-video-errorresponse.html

By utilizing these best practices, we can improve the customer experience greatly. Minimizing common friction points such as friendly name and device dependencies can significantly improve the reliability for customers utilizing your skill. Optimizing the execution of customer requests and providing accurate responses enhance engagement. With all this new knowledge, you can apply it to your existing solutions and see your skill engagement grow.