SBL recommendations should turn analysis into practical actions linked to the scenario. General advice such as “improve communication” leaves the decision-maker with too much work still to do.
SBL recommendations: read the task before using a framework
Identify your role, audience and required output. A recommendation to the board is different from an operational instruction to a branch manager. The requirement may ask you to evaluate options, recommend an action or discuss risks; those verbs should shape the response.
Use models to organise thinking when they help. Do not make the answer a list of framework headings with little connection to the organisation’s actual problem.
A fictional case
A retailer is receiving complaints because online orders are promised for next-day delivery even when local stock is unavailable. Branch staff cannot see the same inventory data as the website. Management wants to restore customer confidence without increasing delivery costs sharply.
A weak recommendation is: “The company should improve its systems and train staff.” It names two broad ideas but says little about the mismatch causing the complaints.
Make the action specific
A stronger recommendation is: “Pilot a shared stock-availability check at two branches before confirming next-day delivery. Show an alternative delivery date when stock is unavailable, and train order-processing staff to use the same information. Monitor late deliveries and cancellations during the pilot before extending it.”
This action responds to the case’s information gap. It also avoids assuming that buying a completely new system is immediately necessary or affordable.
Explain benefits and constraints
The expected benefit is more reliable promises to customers, which could reduce complaints and rework. The organisation still needs accurate inventory data; sharing inaccurate figures would not solve the underlying problem.
Implementation may need responsibilities for stock updates, testing of data connections and a process for handling exceptions. Consider the cost, time and operational disruption where the case provides relevant information.
Use a compact recommendation structure
- Action: what should change?
- Case reason: which fact makes it appropriate?
- Implementation: who does what, and in what sequence?
- Monitoring: how will management know whether it works?
- Constraint: what could prevent the benefit?
You do not need to turn every sentence into a rigid template. Use the structure to check that the recommendation has enough substance for the task.
Practise by rewriting one paragraph
Take a past practice answer and underline proposals that could apply to almost any business. Rewrite one using the organisation’s stated facts. Remove claims you cannot support, and explain a realistic next action.
Explore the SBL course and ACCA’s official guidance on approaching SBL. Check current exam resources rather than relying on old format descriptions.
Evaluate an option before recommending it
In the retailer case, management could improve its existing stock records, purchase a new platform or reduce the delivery promise. Evaluate the options against the problem, available resources and stakeholder needs. A new platform may integrate information more effectively, but it may cost more and take longer. A revised delivery promise may reduce immediate complaints, but it will not necessarily fix inaccurate inventory data.
A balanced recommendation could combine a short-term change to promises with a controlled improvement in data quality. Explain why the combination fits the stated constraints. Do not assume a large technology project is justified solely because the case mentions a systems weakness. The board needs a reasoned choice, not an expensive solution selected before the cause is understood.
Give implementation an owner and sequence
For a fictional pilot, the operations manager could own the process while the IT team tests the stock-data connection. Branch managers could ensure stock updates follow the agreed procedure. Begin with a review of the causes of discrepancies, then clean and validate the data, test the customer-facing promise and train the relevant staff. Assign responsibilities so the recommendation can be acted on.
These roles are illustrative, not facts added to an exam case. In your answer, use the organisation’s actual structure where provided. If the case does not supply an exact job title, describe the responsible function without inventing a named person. Sequence matters because training staff on unreliable data will not produce reliable delivery promises.
Select measures linked to the intended benefit
Late-delivery rate, cancellations caused by unavailable stock and complaints about delivery promises are relevant measures for this pilot. Compare the results with a baseline and consider the volume and type of orders. A reduction in complaints may be misleading if sales fell sharply or dissatisfied customers stopped contacting the business. Use more than one measure to assess the result.
Monitor cost as well as service. Emergency transfers between branches may improve delivery performance while increasing transport costs beyond management’s constraint. Track the additional cost per fulfilled order and the operational workload. A recommendation should explain what success looks like and how management will identify an unintended consequence.
Show professional judgement through a trade-off
Suppose the pilot prevents misleading promises but displays longer delivery times for some customers. That may reduce conversion in the short term while improving reliability. Explain the trade-off rather than promising that every metric will improve immediately. Management may accept a realistic promise because repeated failed promises damage trust and create avoidable refunds and customer-service work.
If the case gives evidence of severe cash pressure, implementation cost and timing deserve particular attention. If it gives evidence of rapid growth, capacity and scalability may matter more. The recommendation should respond to the organisation’s priorities. A sensible action for one business may be unsuitable for another with different resources or risks.
A second case: overdue customer balances
Imagine a wholesaler whose overdue receivables are rising because sales staff grant inconsistent credit terms and disputed invoices are not resolved promptly. A generic answer says to improve credit control. An applied answer recommends an agreed credit policy, approval limits for exceptions, accurate invoices and a named process for resolving disputes. It explains how those actions address the stated causes.
Monitor overdue balances by age, dispute-resolution time and customer retention. Consider the risk that abrupt restrictions could harm valuable relationships. Prioritise persistent arrears and disputed invoices rather than sending the same demand to every customer. This example shows how the same action-reason-implementation structure produces a different recommendation when the case changes.
Use evidence honestly
Distinguish a fact from an inference. If the exhibit says complaints doubled, that is evidence of a reported change. If you infer that unreliable promises are damaging repeat business, label the possibility and explain the connection. Do not invent a revenue loss, market share or customer survey result to make the recommendation sound more precise.
Numbers can support judgement when the case provides them. Compare the proposed cost with the likely benefit and identify missing information. If exact savings cannot be calculated, explain the drivers and suggest a pilot or further analysis. A defensible recommendation can acknowledge uncertainty while still identifying a practical next step.
Match the output to the audience
A board briefing should lead with the decision and its reasons, while an operational note may need more detail on responsibilities and process. Use the requested format and tone. Avoid filling the answer with background definitions that the audience already understands. Frameworks should help you organise an applied argument rather than dominate its visible structure.
Before finishing, check that each recommendation addresses the requirement, uses a case fact and includes enough implementation detail to be useful. Remove duplicated proposals and unsupported guarantees. Read the answer from the recipient’s perspective: can they identify what you want them to approve or do, why it matters and what needs monitoring?
Frequently asked questions
Do I need to use a model in every SBL answer?
No. Use a model when it helps answer the requirement and interpret the case. Reproducing a framework without application does not create a useful recommendation.
Should a recommendation include a downside?
Where relevant, explain implementation constraints, trade-offs or risks. That helps demonstrate judgement rather than presenting every proposal as automatically beneficial.