Table of Contents
Serviceable Addresses: Overview and Usage
Updated
by Mitchell Paul-Soumis
Serviceable Addresses in Sonar allow you to add and track addresses or locations to which you can deliver some service, regardless of the delivery method. Additionally, when a Serviceable Address is added to your Sonar instance, and information or inventory is assigned to it, this information is stored and tracked in perpetuity. The Serviceable Address function allows a new customer to be set up quickly and easily at pre-qualified locations or previously occupied physical locations.
This functionality provides more control over previous account management methods in two main ways:
- Serviceable Addresses maintain the IP Assignments, Inventory history, elevation, and any other device or location-specific traits. This simplifies the process of changing customers when one moves out and another moves in.
- This approach is superior to renaming old accounts to preserve this information, as it protects against the risk of new users accessing old transaction history for their location.
Adding a New Serviceable Address
New Serviceable Addresses in Sonar can be added in one of two ways:
- During the creation process for a new customer account
- From the Settings > Accounts > Serviceable Addresses page
Creating a Serviceable Address from either location opens up the "Create Serviceable Address" modal, which allows you to add a new address, or location, to your instance:
Using Serviceable Addresses
Serviceable Addresses are a critical function in Sonar, as inventory assigned to a customer's home for provisioning is stored and tracked at the account level. Fundamentally, this means that each Serviceable Address is unique, and must always remain unique, even while the accounts which use this address aren't necessarily unique. In this section, we'll be taking a look at a few example scenarios at how to use accounts and serviceable addresses together.
Example 1: A resident moves out
In this example, a current customer of a WISP will be moving out of their home. This customer has had an access point installed at the address to receive service, and trees removed. As a result, the WISP knows that this address remains a location to which services can be offered. Ordinarily, the account would simply be made inactive, and when a new customer signs up at the address, inventory would need to be migrated. In Sonar, this same scenario is simplified, as when a new customer moves in, the equipment and IP assignment history is tied to the address, and will all be migrated automatically.
Example 2: In a shared home, the service contract is being picked up by another
In this example, a home is being shared by several roommates, and the contract for their data service will be getting picked up by a new resident once the current contract expires. In many cases, you would need to change the name of the account, the primary account owner, the contact information, and possibly even custom fields on the account. However, this may result in the new account owner inadvertently being granted access to billing information that belonged to the previous contract owner. By leveraging serviceable addresses, you retain the IP information and device assignments while creating an entirely new account without any legacy billing information or network access credentials.
Example 3: Multiple Accounts sharing a serviceable address
In Sonar, we allow you to import past customer information into your instance, and in some cases this may result in two accounts that would share a serviceable address. Unfortunately, the versatility and robustness of the Serviceable Address function means that you can't have two accounts with the same serviceable address, however, there are some alternatives:
- If this address is split up into different units or residences, or if each service is tied to a separate individual, then the best course of action is to create a unique address for both, with some value added to the "Line 2" field to differentiate them.
- If this address should in fact share services, such as a primary service and a backup service, then both services would be on the same account, either as one larger service that triggers pair bonding on the provisioning side, or as a primary data service with a backup recurring service
