High Bill Complaint

Some organizations will set up a case to manage a high-bill complaint. The following diagram illustrates how such a case type might look:

Note the following about the High Bill Complaint case type:

• Notice that we set up the case type to require a person and an account, but premise is optional. This is because a bill can span multiple premises and knowing the premise isn't so important on cases of this type.
• We need to restrict high-bill complaints to specific user groups. This means we need to set up a specific application service for this case type (that has a separate "action" for each status).
• Cases of this type have 3 additional fields over their lifetime. Notice the following:
  • The Bill ID characteristic is set up to be optional. This is because we've assumed that sometimes a high-bill complaint case can be lodged when you can't find the bill in question and you still want to log the case.
  • Later in this section, you'll see that we've configured the Preliminary Investigation status to require a Bill ID before a case can enter this state.
  • Both the High Bill Complaint Cancel Reason and Reject Reason are optional. Later in this section, you'll see that we've configured the Canceled and Rejected statuses to require these fields, respectively.
• Cases of this type do not need a Responsible User when first created. Later in this section, you'll see how we've configured the Preliminary Investigation status to require a Responsible User before a case can enter this state.
• Cases of this type do not need Contact Information. This was a subjective decision and depends on your organization's philosophy.

The topics that follow describe each of the statuses in a high-bill complaint's lifecycle. We have assumed the following state transition rules: