Identify what types of objective are delivered by your product, and at what frequencies

For each product period, you must identify the types of objectives that your product supports.

Identify what it is that your product "delivers". A common type of delivery is that of a benefit payment to a person or a household. There may be more than one type of thing delivered by your product, for example your product may deliver two different financial components (aimed at different types of nominees - for example a personal allowance and a child allowance), and also a recommendation.

Once you have identified what it is that your product delivers, you need to map these deliverable things to types of objectives. You may have a design decision to make regarding whether to have a smaller number of complex objective types, or a larger number of simple objective types.

To answer this you may need to consider such things as whether each case needs to have the flexibility to pay certain types of benefits to one nominee and other types of benefit to different types of nominee:

• if so, you may well need to have separate types of objectives for the different types of benefit that your product delivers; however
• if benefit payments are always to a single nominee, then your choice of whether to implement separate objective types may rest on whether the total benefit paid is a simple aggregation of all objectives achieved, or whether there are complex rules to come up with the total amount payable (if the latter, then one complex objective type is likely to be more suitable).

You may find it useful to come up with a trial design of objectives, and walk through different business scenarios and how they are treated by the Engine and financial processing, to ensure that your business requirements mapping to objective types allows your business requirements for your product to be met.

Once you are happy with your types of objectives, then for each type of objective, identify at what frequency it can be delivered. Typically a daily rate is always required (to handle ramp up and ramp down periods) but you can implement longer periods such as weekly or monthly too. These longer periods can be useful if your daily rate represents a rounded-up fraction of a weekly or monthly rate, or if your eligibility results are always exactly some larger unit, e.g. if you have business requirements that say each case is either entitled to an objective for an entire month or not at all.

At this point, you have identified the types of things delivered by your product in general; now you need to turn your attention to how the system will decide HOW to deliver a particular product delivery CASE.