Escalation of Service Type

Between a job order being place and the valuation being completed, a job can be escalated. Two main circumstances trigger a Service Type Escalation:

  • An EVR Desktop requires a Drive-by or esclation to Residential Short Form, or
  • Similarly, upon the job being completed, reassessment of business rules may require the job to be reordered as a different service type. For example, now that the job has been completed, the LVR may be different due to a more accurate figure provided by the valuer.

Service type escalation implies that a service type is changed incrementally from a minor service (such as a Kerbside Inspection) to a major service (such as a Residential Short Form requiring full inspection).

escalate() Web Service

When a job is escalated, we send through a SOAP request to the escalate() operation (if implemented) on a Valuation Firm Web Service to notify the valuer. We expect to the Web Service to have the following semblance:

<message name="escalate">
    <part name="valuationMessage" type="xsd:string"/>
    <part name="reason" type="xsd:string"/>
    <part name="from_service_id" type="xsd:int"/>
    <part name="to_service_id" type="xsd:int"/>
    <part name="comments" type="xsd:string"/>
</message>

valuationMessage is a LIXI message, containing an updated valuation order (similar to what was sent in the initial request). The LIXI message will contain the new Service Type.

from_service_id and to_service_id are the Service Type Identifier. This is provided an alternative to parsing the LIXI message to determine the Service Type.

reason is string containing a humanised reason for escalation with a comment.

Escalation Reasons

A list of Reason IDs and their humanised strings is available.