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 ...

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.

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:

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".