Verifying Identity, Checking Credit and Requiring Deposits When Starting Service
The Start Service Request Type (request type) provides controls to help verify customers’ identity and/or check their credit. The start service process provided with the system can begin with or without a person being passed into the process. The process orchestrates the following:
- When there is no person passed into the process, the assumption is that this is a new customers, but the first step is to ensure they are not already in your system. This is done by performing a person search using, name, phone, e-mail or person identifiers. The search options are configured on the start service type. When a record is not found, the last search criteria are retained to minimize asking the customer for the same information again. If an existing person is found, the record can be selected and the process continues as if the process began with an existing customer. For this purpose, existing customers are simply those in your system before beginning the start service process. They may be long-standing customers with current service, or a person record added moments before beginning the start service process. For this reason, the start service process follows the same steps after choosing to add a new customer or selecting an existing one.
- Ensuring customers are who they say they are is often an important
step in starting service, especially for new customers. This is often
done by asking the customer for a unique identifier such as a government
issued ID like a driver’s license, or Social Security number. This
information is often verified with a third-party and is sometimes
combined with a credit check.
The start service process allows you to configure what identifier types your organization accepts when both new and existing customers are starting service. This may be a subset of all of the person identifier types defined in your system. Refer to Understanding Person Identifiers for more information. Note: This help topic pertains to the primary identifier; the start service process supports additional, non-primary identifier types separately.
When setting up the start service type and configuring the primary identifier types, you need to indicate their usage. The usage for most uniquely identifying identifiers is probably New & Existing. These are identifier types that you accept and can uniquely identify a person or business and are probably the primary ID type on the person record. If there is an identifier that was once accepted and is still considered valid for existing customers, but is not used for new customers, these can be set to Existing Only. Lastly, some identifier types such as a PIN or password are used when an identifier is required, but the customer is not willing or is unable to provide a high-quality unique ID. These identifier types should be set to New & Non-Identifying. This allow agents to input an ID when one is required, but the process knows that the record is not a unique identifier.
For existing customer, the start service process sets an indicator when an existing identifier is found from the list of identifiers valid for existing customers. Note: the identifier need not be the primary, although it is likely that it is. For new and existing customers, a different indicator is set when a new uniquely identifying identifier is provided during the start service process. ID types that are configured as non-identifying are not considered when setting the indicator. It is not possible for both indicators to be set since the user is not prompted to enter a new ID when a valid existing one is found. These indicators are passed into plug-in spots called during the start service process.
- Your business rules, might include asking customers for their
date of birth. This could be used when deciding whether or not to
perform a credit check or ID verification or if it does not factor
into the decision, it could be passed to the third party as part of
the credit check or ID verification process. If date of birth is not
part of the credit or ID process, it may be requested only if the
customer is eligible for service and may be used when determining
if a deposit is required. Since this could be considered sensitive
data, it is possible that is used during the start service process,
but not saved on the person record.
To support a wide range of business rules, the start service process provides options for capturing and saving date of birth. When the use of date of birth is enabled, there are options to determine when the date of birth field is shown. It can be show always. It can be show only if a credit check or ID verification is going to be performed. This means the presence of the date of birth cannot factor into the decision to perform a credit or ID check. Lastly it can be shown only if service can start. There is also an option to save the date of birth as a person characteristic. For existing persons, if the date of birth already exists, it is shown, but cannot be updated during the start service process. Note: the date of birth functionality is only available for persons and not businesses.
-
After the data entry is complete, the start service process calls the algorithm(s) plugged into the ID/Credit Check Should be Performed plug-in spot, passing the two ID indicators and the date of birth if enabled, to determine if an identity or credit check should be performed. This can be used to ensure the customer has provided the necessary information to pass to an external service to check credit or verify ID. This can also check the indicator that person has an existing ID and no further checking is needed. This is a multi plug-in spot so you can configure as many business rules as necessary. Each algorithm can indicate if the next algorithm should be called. The system is delivered with a sample algorithm that chooses to run a credit check based on the availability of a unique ID and a sample algorithm that bases the decision on the account history. Refer to the algorithm types for this plug-in spot for more details.
-
If a credit check should be performed, the user is prompted to perform the credit check or ID verification. The algorithm plugged into the ID/Credit Check plug-in spot is then called. The user is shown if the credit check passed or failed, but the process relies on subsequent plug-in spots to determine use the results of the credit check or ID verification.
- After checking the credit or verifying ID, the next step is ensuring the criteria has been met
for staring service and, if so, identifying if the person or business has existing accounts that
eligible for service. This is done by calling the algorithm(s) plugged into the Start Service
Eligibility plug-in spot. These algorithms receive ID indicators, date of birth if enabled, and
the output from the ID/credit check plug-in spot, which can be used to determine if service can
start. Algorithms in this plug-in spot are also responsible for returning the eligible accounts
if there are any. For example, accounts previously used for bankruptcy or those dormant too long
might not be eligible for new service based on your business rules. This is a multi plug-in spot
so you can configure as many business rules as necessary. Each algorithm can indicate if the
next algorithm should be called. When there are existing accounts that are eligible for service,
a control on the start service request type indicates if new accounts are also allowed. You
would set the control if a new account can be created even when there are existing eligible
accounts. Algorithms in this plug-in spot also support returning a list of ineligible accounts
that are shown on the start service process to show information about all of the customer’s
accounts. If your business rules do not support using existing accounts for new service, your
algorithms would not return any eligible accounts. The system is delivered with a sample
algorithm that determines start eligibility and account eligibility. Refer to the algorithm type
for this plug-in spot for more details.Note:
If the CIS Division is configured to ensure the same CIS Division is used on related accounts, premises and service agreements (Restrict to Account CIS Division is set to Restricted), an account is eligible if its CIS Division is the same as the current CIS Division. Otherwise, the account is ineligible. The current CIS Division is determined based on the following hierarchy:
- Premise
- Customer Service Request Type
-
Your business rules may require a deposit before a customer starts service. If so, the deposit functionality should be enabled for the start service process and optionally for the transfer service process. There is a control on the customer service request type that allows you to define if a deposit is always required or if the determination is situational, in which case algorithms in the Determine Deposit Required plug-in spot are called. The following explains the plug-in spot.
Since deposits can be based on more than one factor, this is a a multi plug-in spot. When the plug-in spot is called, the deposit required indicator is not set and a generic message is set that a deposit is not required. The system then relies on the algorithms plugged into the plug-in spot to indicate that a deposit is required, or update the message with a specific reason that a deposit is not required.
When called from within the Start Service process flow, the ID indictors, date of birth if enabled, and the results of the ID verification or credit check are passed into this plug-in spot and can be used in determining if a deposit is required. Note: the transfer service process uses the same plug-in spot, but is not passed any date of birth, ID or credit information since transfer only applies to accounts with current service and the transfer process does not contain the identifier and credit check logic.
There are four sample algorithms provided to determine if a deposit is required. The following illustrates how these algorithms can be used to support both new and existing customers. When a specific condition requiring a deposit or exempting a customer from a deposit is met, the reason is output from the algorithm and displayed to the user in order to communicate with the customer. As mentioned, the system’s default assumption is not required and a default message would be shown to the user if none of the algorithms output a more specific message explaining why the deposit is or is not required. Refer to the algorithm type descriptions for more detail information about each.
-
C1DEPEXBAGE illustrates how an algorithm is used to waive a deposit when a condition is met, which in this case is the customer’s age. This sample indicates that other algorithms in the plug-in spot should not be performed when the condition is met. If your business rules waive deposits when a condition is met and no further checking is required, you’d plug-in the algorithm(s) that check for this first. These algorithms should tell the system not to perform the additional algorithms in this plug-in spot.
-
C1REQDEPAID uses the results from the ID or credit check to determine if a deposit is required. This algorithm has logic for both new and existing customers. It uses inputs including an indicator if an ID or credit check was run and, if run, the results of the ID or credit check. Based on the results, this algorithm can require a deposit. This algorithm tells the system not to perform the subsequent algorithms in this plug-in spot when a deposit is required.
-
C1REQDEPBACR is intended for existing customers and uses the account’s internal credit rating to determine if a deposit is required. It’s possible that you’d not verify ID nor run an external credit check for existing customers, so the preceding algorithm would not have required a deposit, leaving downstream algorithms such as this one to make the determination. If the customer’s internal credit rate is too low, a deposit is required, and this algorithm tells the system not to perform the subsequent algorithms in this plug-in spot.
-
C1DEPEXMPBAH is the last sample and is based on account history. If the customer has recent or current service, the algorithm indicates that is deposit is not required and updates the message explaining that a deposit is not required. If there is no recent account history, the algorithm indicates that a deposit is required. In this example, this is the last algorithm, but it could be performed before other algorithms. To accommodate calling it in any sequence, this algorithm tells the system not to perform the subsequent algorithms only when a deposit is required.
Note: If your business follows the model where a deposit is required unless there is a reason to waive it, then your algorithms will behave in the inverse from the delivered samples. Your first algorithm plugged into the plug-in spot must set the deposit required indicator and update the default message. Subsequent algorithms or subsequent steps in the first algorithm can then clear the deposit required indicator when conditions to waive the deposit are met. -
The delivered algorithms for these four plug-in spots work with each. You can design the algorithms in these four plug-in spots to work together or independently to implement your business’s rule for adding new customers or ensuring existing persons or businesses meet the requirements for verifying ID or credit, starting service, choosing an account, and checking if a deposit is required.