Stack Planning
Part of Marketing technology procurement
Recording why a tool was selected or rejected
Document the options, evidence, rejection reasons and approval conditions behind a marketing software decision.
Write a marketing software decision record when the choice is made. A colleague should be able to find the need, options, evidence and reason for the outcome without reconstructing a meeting. Keep the record concise and link it to the versions of the supporting material that were considered.
State the decision
Name the business task, agreed requirements, decision owner and date. State whether the outcome is to select, reject, defer or run another defined check. Identify each proposal by product or service and offered edition, so a later reader does not confuse one rejected offer with another plan from the same supplier.
| Field | What to capture |
|---|---|
| Need and scope | The task, affected teams and decision boundary |
| Options | Proposed offers and any existing route considered |
| Evidence | What was observed, supplied in writing or remains unverified |
| Outcome and reason | The decision and the requirements or trade-offs that determined it |
| Conditions | Evidence or changes required before commitment or live use |
| Ownership | Who decided, who acts next and when the decision is reviewed |
Keep the record with the approved requirements, evaluation sheet, proof findings and final offer in the organisation's document system. Handle supplier material under the organisation's confidentiality and records rules.
Explain rejection precisely
Give a reason another reviewer can check. “The proposed setup did not show the corrected value reaching the receiving system” is more useful than “weak integration”. If the supplier proposed a workaround, record it and why it did or did not meet the requirement. If the offer was not tested, call the evidence insufficient rather than saying the product failed.
Distinguish unmet requirement, insufficient evidence and trade-off not preferred. Each leaves a different route for future reconsideration. Missing required support hours in one offer might be resolved through a different support package; an essential data boundary may require a more substantial change.
Attach conditions to a selection
A selected tool may still need a contract change, privacy assessment, plan-entitlement confirmation or implementation check. Put each condition beside the selection with an owner, required evidence and the point before which it must be resolved. State whether the selection authorises purchase, live data, production use or only the next step.
Explain any material departure from the scorecard. A higher total may carry an unresolved condition that matters more than a routine feature advantage. Preserve the specific evidence and judgement behind the choice rather than leaving a bare number.
Keep it useful later
At implementation, compare the delivered edition and responsibilities with the accepted offer. At renewal, revisit the original need, limitations and conditions. The record serves both reviews only if its supporting versions can still be found and its unresolved conditions have clear owners.
