Stack Planning
Planning a marketing technology stack
Plan a marketing technology stack around real workflows, existing tools, data hand-offs and clear ownership before deciding what to change.
Plan a marketing technology stack around the work your team must do. Define outcomes, trace current workflows and data, then decide what to keep, improve or investigate. Build a product shortlist only when you can describe the problem it must solve.
Start with the outcomes
Choose a few activities that matter now: publishing campaigns, responding to enquiries or knowing which activity generated qualified leads. For each, record the decision someone must make and what a better result looks like. “Improve reporting” is broad; “give the campaign manager a consistent view of enquiries by channel before the weekly planning meeting” is easier to assess.
Include the people doing and receiving the work. A campaign manager may need speed, sales may need a reliable hand-off, and an analyst may need stable definitions. A request for a new tool does not establish that the current software caused the problem.
Trace the current work and data
List every marketing tool, including shared systems owned by sales, IT or another team. Record each tool’s purpose, users, business owner, administrator, important data, connected systems and contract contact. Mark unknowns for investigation.
Follow one real task across those systems. For a lead-generation campaign, trace the landing page, enquiry capture, agreed source information, transfer to sales and outcome report. Note where information is entered twice, changes meaning or needs manual repair. This shows where a change might help.
Keep a separate view of the capabilities the business needs. An inventory shows how work happens today; a capability map shows what the team must be able to do. A product may advertise a relevant feature while supporting the task poorly under your organisation’s plan, permissions or configuration.
When scoping the stack, include relevant tool categories as well as named systems. These may include AI, privacy, automation and analytics solutions. Note which categories support your team’s chosen outcomes, rather than treating them as automatic requirements.
Compare possible changes
| Response | When to investigate it | What to check |
|---|---|---|
| Improve the process | Responsibilities or definitions are unclear | The revised workflow and decision maker |
| Configure an existing tool | It may already support the task | Availability under the current plan, permissions and configuration |
| Connect existing systems | The task fails at a hand-off | Fields, transfer direction and responsibility for failures |
| Consider a new tool | A necessary capability remains unmet | A specific use case and the limits of current options |
An existing tool is useful only if it meets the requirement without disproportionate work. A new subscription will not resolve conflicting definitions or an unowned data transfer.
Set data and ownership boundaries
For each important customer attribute, identify where it is created, where it may be updated and who resolves conflicting values. Name a person to coordinate stack decisions. Record what a proposed connection would send to a provider.
If personal information is involved, involve the organisation’s privacy and security contacts in assessing the arrangement and applicable obligations. An available integration does not, by itself, authorise every data transfer.
For entities covered by the Privacy Act 1988 (Cth), OAIC guidance says reasonable steps are required to protect personal information from misuse, interference, loss, and unauthorised access, modification or disclosure. Reasonable steps include technical and organisational measures under APP 11.3, which applies to information held after 11 December 2024, including information acquired or created earlier.
Plan what happens when personal information is no longer needed: OAIC guidance says entities should take reasonable steps to destroy or de-identify it unless an exception applies. For organisations covered by the Privacy Act, OAIC advises reading its security guide alongside the Australian Privacy Principles guidelines and its data breach notification guidance.
Privacy and Security Requirements Under the Privacy Act 1988 (Cth)
- Applicable Obligations
- APP 11.3 – Reasonable steps to protect personal information
- Effective Date
- 11 December 2024
- Required Actions
- Prevent misuse, interference, loss, unauthorised access, modification or disclosure
- Data Disposal
- Destroy or de-identify personal information when no longer needed
Make the next step reviewable
For each proposed change, record the task, current failure, expected outcome, affected teams, data involved, existing options, dependencies, decision owner and evidence still needed. Prioritise changes that remove a clear obstacle in an important workflow. Allow for training, monitoring and a way to reverse a change that disrupts live work.
Suppose campaign enquiries reach sales with inconsistent source labels. First agree what the labels mean, then trace where they are created and altered. A process or configuration change may be enough; compare reporting products only after you understand the records they would use.
Revisit the plan when work, teams or data needs change. Its useful output is decisions and open questions people can act on.
In this guide
- Mapping marketing capabilities before shopping for toolsTurn real marketing tasks into a capability map that shows current methods, evidence of gaps and the next question to verify.
- Identifying overlapping tools in an existing stackIdentify genuine overlap in a marketing stack by comparing users, tasks, data and outputs rather than matching feature names.
- Choosing a stack owner when several teams share softwareChoose a stack owner for shared marketing software by defining cross-team decisions, system owners, specialist roles and escalation paths.
