1. Define the outcome and the boundary
Begin with the business change the programme is expected to create. A goal such as issue corporate cards is too broad to guide design. Replace it with an observable outcome, such as giving a field team a controlled way to pay approved operating expenses while providing finance with timely, attributable transaction data.
Then state what the first phase does not cover. A clear boundary protects discovery from becoming a catalogue of every possible use case and makes estimates more meaningful. Keep assumptions visible so they can be tested instead of hardening into requirements without review.
- Which spending problem are we solving, and for whom?
- What happens today, and where does that process create delay or uncertainty?
- What result would make the programme worthwhile for finance and cardholders?
- Which entities, countries, teams and use cases are in the first phase?
- Which adjacent needs are explicitly outside the initial scope?
- Who is the executive sponsor and who can make scope decisions?
2. Describe cardholders and real spending journeys
Group potential cardholders by the work they perform, not only by department. Two people in the same division may need different controls because one buys planned supplies and the other responds to urgent operational incidents. A small set of representative journeys will reveal more than a long feature list.
For each journey, describe the event that creates the need to spend, any approval that precedes it, the purchase itself and the evidence needed afterwards. Include difficult cases such as a declined transaction, a lost card, a departing cardholder or a purchase that cannot be matched to its original purpose.
- Who needs a card, and which entity or team is responsible for that person?
- Is a physical, virtual or other supported card form appropriate to the task?
- Where, when and how frequently does the spending occur?
- What value ranges and currencies are expected?
- What approval, receipt or reference should accompany the transaction?
- What should happen when the ordinary path cannot be followed?
3. Map funding, controls and decision rights
Funding and control choices should be reviewed as one operating model. Teams need to know where available funds come from, who monitors them and what happens when the required amount is not available. They also need to know which rules are automated and which decisions still rely on a person.
Turn policy language into named responsibilities. Limits and permitted-use rules need owners; alerts need recipients; exceptions need approvers and an expiry or review point. Confirm the available control options with prospective providers because terminology and granularity can differ between programme arrangements.
- What is the intended source of funds, and who owns funding operations?
- How will available funds be allocated or monitored?
- Which limits, merchant, channel, location or time rules are genuinely required?
- Who can request, approve and implement a control change?
- Which actions require independent approval or later review?
- How are urgent overrides recorded, communicated and reversed?
4. Specify data and reconciliation outcomes
Do not reduce the data discussion to whether an integration exists. Start with the record finance needs at the end of the process, then work backwards. Identify required fields, timing, ownership and the identifier that links the card transaction to the relevant person, entity, cost centre, project, invoice or approval.
Document both the normal process and the exception queue. Reversals, refunds, disputed transactions, missing evidence and late coding need an owner and a resolution path. If sensitive payment data could enter company systems, involve the appropriate security and compliance stakeholders in determining what should be collected, displayed, stored or exchanged.
- Which finance, expense, procurement or identity systems are involved?
- Which fields are required for posting, allocation and management reporting?
- How quickly must transaction and status data become available?
- What is matched automatically, and what enters a review queue?
- Who closes unresolved items, and what evidence is retained?
- Which teams approve access to programme and transaction information?
5. Turn discovery into a decision pack
Discovery should finish with an agreed set of decisions, dependencies and owners. Capture the programme outcome, scoped journeys, entity coverage, proposed responsibilities, funding assumptions, controls, data requirements, support model and rollout approach in one reviewable pack. Keep unresolved points separate from confirmed requirements.
The pack should also identify which questions require confirmation from potential providers and which require finance, legal, tax, security or other specialist review. Programme availability and responsibilities can vary by jurisdiction and arrangement. A checklist supports that review; it does not replace it.
- Rank requirements as essential, valuable or later-phase
- Assign an owner and decision date to every material open question
- Record dependencies on providers, internal systems and specialist review
- Define pilot population, training, support and communication needs
- Agree measurable readiness and rollout criteria
- Schedule a final cross-functional review before implementation begins
This article explains programme-design considerations and is not financial, legal, tax or regulatory advice. Availability and final responsibilities depend on the approved programme and its documentation.