USS Best Practices

​Overview

User self-service (USS) provides your customers with the tools to manage their accounts. In your user self-service (USS) application, your customers can take the actions listed below on their account. Your customer support representatives can also complete actions such as the following in your CRM (customer relationship management) application:

• update contact information;
• update payment information;
• update, switch, add, or cancel plans (products);
• place orders for inventory items;
• make a one-time payment;
• view statement, transaction, and order histories;
• reset a forgotten password.

Updates to your customers' accounts take place immediately and you are informed of the changes by your chosen event notifications.

Best Practices

The best practices to follow when designing your USS application are as follows:

• Ensure that the information your customers can see and actions they can take meet your business requirements.
  
  Examples:
    
  • If your services are offered only at the supplemental plan level and you have a master plan that is assigned to all new customers by default, then you should not show your master plan to customers.
  • If you do not offer inventory items for customers to order, you should not show an ordering section in your application.
  • Allow customers to select only the payment methods that your company accepts.

• Provide customers with the ability to perform the required actions for managing their accounts.
  
  Example: Provide a text box in which customers can enter the number of units of a plan to which they want to subscribe.
   
• After a customer logs in, use the validate_session_m API call at every page load to determine the validity of the session and the customer with which the session is associated.
• In every API call used to add, update, switch, or cancel plans, set the <do_write> field to false before displaying a confirmation page to the customer. This will prevent the plan change from going into effect before the customer confirms the requested change. After the customer confirms the request, you can call the applicable API again with the <do_write> field set to true.
• Establish company-wide rules that apply to your billing practices and when exceptions to those rules are allowed. That is because some arguments that you pass into APIs may override your company-wide rules (that you specified in your client parameters). In addition, it is important to be aware of what actions Aria will or will not take because of your company-wide rules.
  
  Examples:
  • The proration rule that you pass into an API will match or override your client parameters for proration.
  • A bill date reset rule that you pass into an API will match or override your client parameters for resetting bill dates.
  • Bill dates will or will not be reset when accounts or plans change from a non-billable to a billable status depending of your client parameters for resetting bill dates.
     
• Include a Terms and Conditions link from which customers can access information about the general terms or the agreement under which they may use your application.

Preconditions

To implement the USS use cases listed below, you must first take these actions:

1. Whitelist your IP addresses.
2. Obtain your client number and authorization key.

Use Cases

Click on any of the links below to see instructions for working with APIs to complete a few common USS uses cases:

• Update account information/take action on a single plan with separate API calls:
  • Update billing contact and payment information
  • Update an assigned plan and queue rate changes
  • Switch to a different master plan
  • Add a master plan on a future date
  • Add a supplemental plan on an anniversary date
  • Add a master plan retroactively
• Add multiple plans immediately with different billing intervals using the update_acct_plan_multi_m API call
  
  You can take actions on multiple plans at the same time by calling the update_acct_plan_multi_m API once instead of calling separate APIs to take action on one plan at a time. The structure of the update_acct_plan_multi_m API is described in this walkthrough.