Service Problem KCI Flows

KCI updates will usually originate from the supplier API and be delivered by the gateway. However, to help ensure consistency between suppliers and to provide additional service problem state information, the gateway may also send some KCI updates. For example, a supplier may acknowledge the service problem synchronously as part of the create service problem API call - the gateway would then send the acknowledged KCI.

An overview of the service problem KCI flows is represented below.

Successful Service Problems

The service problem is acknowledged by the supplier once received and verified. The supplier will then accept the service problem and the problem will be transitioned to "IN_PROGRESS".

If the supplier needs any action from the tenant/customer (i.e. information needed or a new appointment is required), they will send an appropriate KCI and the service problem status will become "PENDING". The tenant must then reserve a new appointment and/or send an appropriate amendment request which the supplier will acknowledge via a KCI. If accepted and the action is resolved, the service problem will return to the previous state.

Once the service problem is fixed, the supplier will inform the tenant that the service problem is resolved via a KCI. The service problem will automatically move to "COMPLETED" if the tenant/customer does not approve the resolution. A KCI will be sent informing the tenant of imminent closure.

Close or Reopen Service Problem

Once the service problem has been resolved by the supplier, the tenant can accept or reject the resolution using the service-problem-resolutions API. If the tenant accepts, then the service problem will move to COMPLETED and a KCI will be sent. If the tenant rejects the resolution, then the service problem will move back to IN_PROGRESS and a KCI will be sent. If the tenant does nothing then and ADDITIONAL KCI will be sent warning that the service problem will close in 24 hrs. The service problem will then move to COMPLETED by the supplier and a KCI will be sent.

Failed or Cancelled Service Problem

There are various terminal flows that can occur resulting in a failed or cancelled service problem;

If the gateway cannot connect to the supplier API or receives an error communicating with the supplier API, the gateway will emit an appropriate "FAILED_TO_SEND" KCI to inform the tenant and the service problem will need to be resubmitted.

Once a service problem is sent to the supplier, the supplier API may respond synchronously to reject the service problem which the gateway will handle by sending the REJECTED KCI itself. Alternatively, the supplier could reject the service problem asynchronously by sending the REJECTED KCI which the gateway will forward.

Where the tenant requests to cancel the service problem, the service problem may transition to "PENDING_CANCELLATION" awaiting supplier confirmation. A further KCI will then be sent to accept or reject the cancellation. Where the cancellation is rejected, the service problem would transition back to the previous state.

A supplier may also send an unsolicited service problem cancellation providing a reason for the cancellation.