The Loyalty Scheme Nobody Owned
A mid-sized retailer's loyalty programme has 1.4 million members, but redemption rates have fallen from 38% to 19% in two years. The new marketing director asks you, a business analyst in the IT department, to "specify a new mobile app" to reverse the trend. Initial interviews reveal three groups each believe they own part of the scheme: Marketing runs campaigns, Finance controls the points liability (currently £2.1m on the balance sheet), and Store Operations handles in-store redemption. No documented business case exists for the original scheme. Customer complaints cite confusing point values and expiry rules. The board has allocated £600k for "digital loyalty" but no outcome has been defined. Your manager wants a requirements document within four weeks.
1. The marketing director has already named the solution. How should you respond as a business analyst, and what should happen before any requirements are written?
Read the worked answer
Treat the requested app as a proposed solution, not a requirement. The measurable problem is a 19-point fall in redemption and a £2.1m liability that may be growing faster than it is being used. Before writing requirements, establish the business need: what outcome does the board want (redemption rate, retention, liability reduction, complaint volume)?
Recommended actions:
- Stakeholder analysis - map Marketing, Finance and Store Operations, and agree who is accountable for the scheme's outcomes. The absence of a single owner is a root cause, not a side issue.
- Situation investigation - use root cause analysis (for example, a fishbone diagram or the '5 whys') on the redemption decline. Falling redemption may reflect poor value perception, unclear rules or changing customer behaviour, none of which an app automatically fixes.
- Business case - produce a lightweight options appraisal: do nothing, fix rules and communications, build the app, or combine. Compare costs against the £600k envelope.
- Define success measures before requirements, so scope can be challenged later.
Only then elicit requirements. If the app is still justified, it becomes one option within a defined scope rather than the starting assumption. Flag to your manager that four weeks is realistic only if the business need is agreed in week one.
2. Finance and Marketing disagree about whether points expiry should be shortened to reduce the liability. How do you handle this as an analyst?
Read the worked answer
This is a conflict of business interests, not a requirements-elicitation gap, so do not resolve it by choosing the more senior voice or by writing a requirement that splits the difference. Instead:
- Make the trade-off explicit. Model both options: shortened expiry reduces the £2.1m liability but may depress redemption and retention further, which conflicts with the board's growth intent. Quantify what is known and state assumptions where data is missing.
- Separate criteria from preferences. Agree evaluation criteria (customer impact, financial impact, regulatory and consumer-law constraints, operational effort) and score options against them.
- Escalate with structure. Present the options and consequences to the accountable owner once one is agreed. If no owner exists, escalate that gap first - it is the real blocker.
- Check constraints. Expiry terms may have legal or consumer-protection implications and may appear in existing terms and conditions; confirm with legal rather than assuming.
- Record the decision and its rationale in a decision log so later requirements trace back to an agreed position.
Your role is to ensure the decision is informed and owned, not to make a commercial judgement on Finance's or Marketing's behalf.
3. What should your requirements documentation contain to be credible in four weeks, given no original business case exists?
Read the worked answer
Aim for a focused, decision-oriented package rather than a large specification:
- Business context and problem statement - the redemption decline, liability position, complaint themes, and the gap left by the missing business case.
- Objectives and success measures - specific, measurable targets agreed with the scheme owner.
- Scope - in scope, out of scope, and assumptions, with the app positioned as one candidate solution.
- Stakeholder summary - roles, interests, influence, and the ownership question.
- Options appraisal - costs, benefits, risks and a recommendation.
- Requirements - prioritised (for example MoSCoW), each traceable to an objective, with acceptance criteria for the highest-priority items.
- Rules and data - current point value and expiry rules documented as business rules, since complaints suggest they are unclear.
- Risks and open issues - including the unresolved ownership and the Finance/Marketing disagreement.
Use timeboxing and workshops to compress elicitation. Be explicit that lower-priority requirements are provisional pending validation. Credibility comes from traceability and honest gaps, not from volume.