Search the Aria Knowledgebase for
User Documentation, APIs, SDKs, and more!



 

Home > Aria Crescendo Documentation > User Self-service Best Practices

User Self-service Best Practices

This article applies to:Aria Crescendo

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.

Notes:

 

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:

 

Note: The sample calls shown in the USS uses cases contain a few key fields needed to successfully complete the specified action. You may choose to pass in additional values based on your business requirements.

Examples: You may want to:

Please see the documentation for the API mentioned in each use case for detailed information about additional available fields.

 


Last modified

Tags

This page has no custom tags.

Classifications

This page has no classifications.