Offers are an important element in the handling of claims and legal cases. The fundamental process of making and receiving offers is generally consistent across different types of offers, with variations mainly in the content of the offer itself and the subsequent activities. Offers need to be managed closely as they can offer tactical opportunities to both sides, as well as provide the opportunity for earlier settlement and demonstrate cooperation.

This offers accelerator has been designed to enable capture and management of offers made and received, and has been built to enable further expansion and customisations based on case types and operational needs. It is intended to be used in conjunction with the relevant matter types, such as dispute case types.

The updated version of this accelerator has been designed to be jurisdiction agnostic; although there are some jurisdiction or case type specific offer types, these can be removed if not required, and additional offer types added with the benefit of inheriting configuration.

Content

The sample types of offers included in this accelerator are:

• Part 36
• Calderbank
• Without Prejudice (WOP) Offer
• Drop Hands
• Open Offer

Data capture on the offer will vary depending upon whether the offer is:

• Liability Only, in which case no financials are shown
• Monetary Only, in which case no liability details are shown
• Liability & Monetary, in which case both liability and monetary details are shown

Information captured will also vary by:

• Whether an offer is being made or received; this will change the overall phase plan and workflows
• Based on the associated matter work type; if it is a monetary offer this could change the heads of claim/loss that are shown (the budget)

The offers accelerator has been designed to encompass these variables together with the appropriate management of offers, including the expectations of responses, expiry and withdrawal of offers, and key date management to ensure compliance with relevant offer types, e.g. Part 36. The accelerator also encompasses a number of control measures, such as comparison of offer amounts to reserves/budgets, and mechanisms for approval of offers where appropriate.

User journeys

The intended approach is for users to make and receive offers in the context of a matter. The user interface will primarily be via the work type blade, for example:

Making an offer

Below are the intended steps the user will follow when making an offer:

• Create a new offer made record via a menu command
• Capture the offer details; type of offer (Part 36, WOP, etc), what the offer is for (liability, monetary, both), offer expiry date, and who the offer is being made to
• When all the details have been completed:
  • A letter/email can be generated (if required) via the offer blade to formalise the offer
  • If required, the letter/email could also be sent for approval (defined on the template document)
• Once the offer is made, the phase of the offer will be set to 'open' on the offer blade
• If appropriate, an expiry date can be recorded or calculated and a reminder task for the expiry due date can be created
• A document expectation task will be created to await a response to the offer
• On receiving a response, the user will be able to progress the phase (e.g. accepted, rejected)

Receiving an offer

Below are the intended steps the user will follow when an offer has been received:

• Create a new offer received record via a menu command
• Capture the offer details; type of offer (Part 36, WOP, etc), what the offer is for (liability, monetary, both), offer expiry date, and who the offer is being made to
• When all the details have been completed, the user can decide the next steps:
  • Set the phase to 'Take Instruction' which will run a workflow to get client instructions, and action further later
  • Set the phase to 'Accept' the offer; if required the user will be able to generate a letter/email accepting the offer, and if the offer includes monetary the system can create a payment expectation (if required)
  • Set the phase to 'Rejected'; if required the user will be able to generate a letter/email rejecting the offer