Customer Contacts Are Used To Trigger Letters

In order to send a letter to a customer, a customer contact must be created for the customer. These types of customer contacts reference a customer contact type that, in turn, references a letter template. The letter template controls the type of information that is merged into the "form letter" and how the letter is physically produced. Refer to Printing Letters for more information about letter templates and how letters are physically produced.

Because these letters are being sent to a customer, the customer contact that triggers a letter must be person-based. See Person-Based Versus Premise-Based Customer Contacts for more information.

Customer contacts that trigger letters can be produced by any of the method described under How Customer Contacts Are Created. While a user can create this type of customer contact (e.g., if a customer requests a form to sign-up for automatic payment), the primary sources of customer contacts that trigger letters are via system events and algorithms. Besides algorithms, the following system events may generate customer contacts automatically:

• Collection events. When a customer falls in arrears, the system creates a collection process. A collection process is a series of events meant to encourage the customer to pay their outstanding debt. A classic collection event is one that creates a customer contact that, in turn, causes a letter to be sent to the customer requesting payment. These customer contacts are created with person and account populated. Refer to The Big Picture Of Collection Events for more information.
• Severance events. The last event in a collection process typically creates a severance process for each service agreement that's in arrears. A severance process is a series of events that leads to service being severed. A classic severance event is one that creates a customer contact that, in turn, causes a letter to be sent to the customer warning of impending cutoff (or telling them they've been cutoff and the terms necessary to reinstate service). These customer contacts are created with person and account populated. Premise is also populated if the service agreement being severed is associated with a premise. Refer to The Big Picture Of Severance Events for more information.
• Write-off events. After a customer has been final billed, a write-off process will be created. A write-off process is a series of events that leads to the debt being written off. A classic write-off event is one that creates a customer contact that, in turn, causes a letter to be sent to the customer informing them of that their debt has been referred to a collection agency. These customer contacts are created with person and account populated. Refer to The Big Picture Of Write Off Events for more information.
• Overdue events. Overdue processes can be used to collection on past due debt. An overdue process is a series of events that are used to collect on debt. Some overdue events may create a customer contact that, in turn, causes a letter to be sent to the customer. These customer contacts are created with person and account populated. Refer to The Big Picture Of Overdue Events for more information.

Your implementation team can introduce plug-in algorithms to create a customer contact when certain events take place. If the created customer contact references a letter template, a letter will be triggered. Because the number and type of plug-ins can be customized for your implementation, we cannot provide a concise list of all such algorithms.

Algorithms that are delivered with the product populate person, account, and/or premise based on the information available when the customer contact is created. For example, the field activity remark algorithm populates the premise and also the person and account if the field activity’s service point is linked to a service agreement. From the service agreement the account and account’s main person are obtained and used on the customer contact.