Designing Cut Process Templates and Event Types
While not required, many overdue processes will contain an overdue event that cuts (i.e., stops) service (in the hopes that stopping service will inspire the customer to pay). When such an event activates, it creates one or more cut process(es).
The system allows you to control if and how service is cut by setting up Cut Process Rule algorithms on your SA types. This allows different rules for different types of service agreements. In addition, because these rules are embodied in algorithms, a given SA type can have conditional logic that controls the type of cut process created. For example, you may have a different cut process if the customer has life support equipment, or if it's winter, or ...
If a service agreements of a given type should never be cut. If you have certain SA types that should never be cut, do NOT define an algorithm in the SA type's Cut Process Rule .
Determining your Cut Process Rules can be straightforward or complicated; it depends on how your organization works. Our case study assumes the following:
- For service agreements associated with metered service, we have
the following rules:
- Highest priority. If the customer has life support requirements, create "cut process in light of life support" process.
- Lowest priority. Otherwise, create a "metered service" cut process.
- For service agreements associated with charitable contributions, create an "expiration only" cut process.
Once you've determined if / how each SA type is cut, you need to design your cut process templates (you'll need one for each unique method of cutting a service agreement). The following table shows the cut process templates referenced above. Adjacent to each process are its events and an indication of when they are triggered.
Cut Process Template |
Event Number |
Cut Event Type |
Dependent On Event(s) |
Trigger Date Set To X Days After Completion Of Dependent Events |
Metered service |
10 |
Letter - 48 hour disconnect for non-payment warning |
N/A - first event |
0 |
20 |
Field activity - disconnect for non-payment |
10 |
2 |
|
30 |
'Service has been disconnected' letter |
20 |
0 |
|
40 |
Expire service agreement |
20 |
10 |
|
Cut process in light of life support |
10 |
Generate delinquent life support customer To Do entry (seeking approval for the cut) |
N/A - first event |
0 |
20 |
Letter - 72 hour disconnect for non-payment warning |
10 |
0 |
|
30 |
Generate impending life support cutoff To Do entry to C&C rep |
20 |
3 |
|
40 |
Field activity - cut for non-payment |
30 |
0 |
|
50 |
Service has been disconnected letter |
40 |
0 |
|
60 |
Expire service agreement |
40 |
10 |
|
Expiration only |
10 |
Expire service agreement |
N/A - first event |
At this point, you've designed the distinct cut process templates. Next, you'll need to design the algorithms that control the lifecycle of their cut processes:
- A template's Cancel Logic algorithm is executed to cancel a process. In addition to cancelling the event, these algorithms are also responsible for inserting log entry(s).
- A template's Information algorithm is invoked to construct the override "info string".
Next, extract each unique event type from the above table:
Cut Event Type |
Action |
48-hour warning letter |
Create a customer contact - 48-hour warning letter (letters are created via customer contacts) |
72-hour warning letter |
Create a customer contact - 72-hour warning letter |
Disconnect for non payment |
Create a cut for non-payment field activity |
Permission to start a cut process for a life support customer |
Create To Do seeking permission to send 72 hour letter |
Permission to create a cut field activity for a life support cutoff |
Create To Do seeking permission to issue a cut field activity |
Service has been disconnected letter |
Create a customer contact - service cut letter |
Expire service agreement |
Expire service agreement |
At this point, you know the distinct event types. Next, you'll need to design the algorithms that control the lifecycle of their events:
- The event type's Event Activation algorithm(s) are executed by
the Overdue / Cut Event Manager on its trigger date.
The following points describe the logic embodied in such an algorithm:
- The activity that happens on the trigger date (e.g., creation of a customer contact, To Do, etc.). Refer to Cut Events Can Do Many Things for the details.
- Whether the event is transitioned into the Waiting or Complete state when it's triggered. Refer to Some Events Can Wait for the details.
- How the log entry(s) associated with event activation will be constructed. The base-package algorithms allow you to control the verbiage in the log entry by defining the desired message number on the algorithm. This means that you may have to set up new messages. Refer to Activating Events Should Add A Log Entry for the details.
- The event type's Cancel Logic algorithm(s) are invoked when an
event is cancelled. The following points describe the logic
embodied in such an algorithm:
- If the event is allowed to be canceled. This logic may be necessary if some conditions prevent events of this type from canceling. For example, you may want to prevent an event from canceling when there are later dependent events that aren't canceled.
- Any ancillary actions that take place during cancellation.
- How the log entry(s) associated with event cancellation will be constructed.
- The event type's Monitor Waiting Event algorithm(s) are invoked to monitor a waiting event. These algorithms are responsible for transitioning a Waiting event to Complete if the object on which it's waiting is complete.
- The event type's Event Information algorithm is invoked to construct the override "info string".