AI marketing strategy with a robust business case

An AI marketing strategy is a sequence of investment and operating decisions, not a collection of tool subscriptions. It determines which marketing problems are worked on, which data and risks are acceptable, how benefit is measured and when an initiative is stopped. A business case is not the largest possible number but a verifiable hypothesis about benefit, total cost and uncertainty.

The sensible order is: clarify the business goal, measure the baseline, narrow the use case, compare alternatives, design the pilot and only then decide on scaling. The SATW guide for Swiss SMEs likewise recommends starting from an actual need with small pilots and considering governance as part of the design. International planning frameworks add value, feasibility and traceability as decision dimensions.

Strategy starts with a portfolio, not with a platform

Marketing teams usually have more ideas than time, data and specialist capacity. A strategy must therefore make differences visible. An internal drafting assistant, a forecast, a customer-personalisation system and an automated campaign action do not involve the same implementation effort or the same consequences of failure. They do not belong in a single ranking without context.

First, sort ideas into three horizons:

Learn: limited assistance cases with easily recognisable errors and no irreversible action. The goal is knowledge about the task, data, quality and staff needs.

Improve: existing, stable processes in which a measurable bottleneck is to be removed. This requires a comparison against the current process.

Transform: integrated systems that substantially change roles, data flows or customer experiences. A short pilot and a tool budget are not enough for this; architecture, governance, operation and organisational change belong in the decision.

These horizons prevent a successful text draft from serving as proof for a complex automation. Vendor materials make a similar distinction between individual work assistance and comprehensive automation. That is not neutral proof of impact, but it provides a useful planning question: does the idea change only one task or the entire operational process?

The business case starts with the baseline

Without a baseline, almost any result can later be presented as a success. The baseline describes today’s process under normal conditions. It includes volume, processing time, quality defects and rounds of revision, external costs, waiting times and, where relevant, a business outcome. The period must be long enough not to mistake seasonality or unusual individual weeks for normality.

Direct revenue attribution is not necessary for every use case. For an internal briefing assistant, the first effect can be a shorter time to a version approved by a qualified reviewer. For anomaly detection, it can be a shorter time to reviewing a genuine anomaly. For personalisation, a downstream business effect would be relevant, but inappropriate targeting or messages, exclusions and consents must also be measured.

Keep three levels separate:

• Output: Is the individual output correct, complete and compliant with the rules?
• Process: Does the entire process improve, including review and rework?
• Business: Does a relevant outcome change compared with a suitable reference?

Faster output can lead to no process saving if review takes longer. A process saving can still be worthwhile without additional sales. Conversely, an observed business effect must not automatically be attributed to AI when campaign or price changes, or seasonal effects, may have confounded the result.

Formulate benefit as a testable hypothesis

A good benefit hypothesis contains target group, change, comparison and period: “If the team uses controlled assistance for task X, the median time to a version approved by a qualified reviewer falls compared with the current process, without the rate of critical errors rising.” The words “approved by a qualified reviewer” and “without” matter. They prevent speed from being optimised at the expense of quality.

For monetary planning, a team can use a simple, transparent calculation:

For a time-saving scenario: annual gross benefit = number of tasks affected per year × time saved per task in hours × defensible hourly rate. If tasks are eliminated entirely, state their number and the previous effort separately and do not count these tasks again among those completed more quickly. All quantities refer to the same period.

That is not yet a profit. All additional costs must be deducted. In addition, “avoided” must be estimated conservatively: time that is theoretically released for other work is only an economic benefit if it can actually be put to other use or reduced as an expense. Keep internal capacity value separate from a realised cash saving or additional cash income. If the review time is already included in the task time, it is not deducted a second time as additional effort.

Ideas close to revenue call for even more restraint. A forecast is better expressed as a range with assumptions. A pilot can demonstrate an additional effect only if comparison groups, measurement windows and other changes allow it. The business case should contain a base, a cautious and a negative scenario, not only the desired trajectory. Forecasts may work with clearly labelled assumptions; observed pilot results replace these assumptions instead of confirming them. A simple before-and-after comparison does not prove causality.

Include the full cost of ownership

Licence or API costs are often the most visible item, but not the largest. A complete cost picture includes at least:

1. Initial assessment and subject-matter requirements.
2. Data cleansing, access control and, where relevant, integration.
3. Tests, evaluation data and human assessment.
4. Data protection, security, legal and procurement review.
5. Training and time of the affected teams.
6. Review and approval in the ongoing process.
7. Monitoring, incident handling and vendor changes.
8. Exit, data export, fallback process and decommissioning.

Opportunity costs also belong here: which other improvement is not implemented because specialists are working on the AI initiative? The OECD synthesis on the adoption of AI in firms names skills, data maturity and regulatory uncertainty as hurdles, among other things. That does not support a blanket cost ratio, but it is a reminder that technology is only part of the investment.

Assess value, feasibility and risk separately

A single average score hides important blockers. So assess three axes and document the rationale.

Value: How relevant is the problem, how often does it occur and how would an improvement become visible? Is there a simpler alternative without AI?

Feasibility: Are data, integrations, specialist knowledge, operating capacity and a meaningful comparison available? Can the team test rare errors?

Risk: Which people, rights, budgets and relationships are affected? How quickly does an error become visible and get reversed? What residual risk does the responsible leadership accept?

This three-axis assessment is a working template, not a compliance seal. The OECD’s accountability principle recommends that datasets, processes and decisions remain traceable across the life cycle, according to the role and the context. As a principle, it is a recommendation and not an automatically binding legal obligation. For the business case, maitiq derives a practical template from it: every assessment needs a source, a rationale, a person responsible and a date, so that a later committee can review it and change it in the light of new findings.

A high value score does not cancel out a data protection blocker. High feasibility does not make a trivial task strategic. And a low-risk pilot does not prove that a later integrated variant would also be low-risk.

A roadmap with decision points

Instead of a rigid multi-year plan, the roadmap needs verifiable decision points:

Decision point 0 — problem: the person responsible, users, baseline, alternative and desired outcome are documented.

Decision point 1 — pilot approval: data, rights, test cases, roles, budget, stop point and fallback process have been reviewed.

Decision point 2 — evidence: the pilot reaches quality and process values defined in advance; errors and rework are fully recorded.

Decision point 3 — operational readiness: integration, monitoring, support, change control, training, vendor management and exit are funded.

Decision point 4 — scaling: the effect persists under broader volume or additional teams, and new risks have been reassessed.

At every decision point, “stop”, “narrow the scope” and “test again” are just as valid as “continue”. A strategy that allows only forward movement does not provide effective oversight.

The pilot must test the assumption that is relevant to the decision

A proof of concept should not simply show that a model can generate text or process data. It should test the most uncertain assumption and the one most important to the business case – not necessarily the most expensive one. That can be data access, accuracy in the relevant domain, necessary rework, user acceptance or technical latency. Vendor guidelines recommend focused tests with clear success criteria and feeding observed results back into prioritisation. The underlying idea is useful without adopting the products or time frames named there.

Before the test, define a reference, a minimum improvement and a non-deterioration threshold. Example: processing time should fall while no additional critical factual error arises. Also document outages and cases in which employees bypass the system. Otherwise only the best demonstration is measured.

Who decides on the investment?

Marketing owns the business context but not all decision rights. Data owners review purpose and access. IT and security assess integration and operation. Legal and data protection clarify applicability and contracts. Affected employees know the exceptions and the actual workload. Finance reviews assumptions and costs. Leadership accepts residual risk and prioritises resources.

A named decision-making body does not have to be large. But it must know what it is approving: a time-limited test, a technical implementation or ongoing operation. These three approvals are not interchangeable.

What a robust business case shows in the end

A good business case does not show a profit estimate that implies more precision than the evidence supports. It shows a problem with a baseline, several solution options, a justified value range, complete costs, material risks, an evidence plan and a person responsible. It states explicitly which assumptions are still unproven and which decision follows the pilot.

That turns the AI marketing strategy into a learning portfolio. Small, controlled experiments generate evidence. Evidence changes priorities. Only initiatives with proven benefit and sustainable operation receive the next investment. That is slower than buying a tool in one meeting, but faster than an organisation full of unmeasured pilots.

How maitiq helps: a business case that Finance can follow

Illustrative calculation example: 40 tasks per month previously take 30 minutes each; in the pilot, 15 minutes each including review. That releases ten hours per month. At an internal rate of CHF 100 per hour, that is CHF 1,000 of capacity value per month. Deduct ongoing tool and operating costs and treat the initial setup effort separately.

Released capacity is not yet a cost reduction: it must be clear which additional work will be done with it, or which expense actually disappears. In an agreed pilot, maitiq helps to select a use case that can be measured, and reviews time, quality and usage with you before you extend the process.

How an agreed pilot with maitiq begins

For an agreed pilot, a short initial assessment establishes the available baseline and the assumptions that still need testing. The resulting plan is the basis for the investment decision: it gives the use case a clearly defined scope and sets out the unresolved data and control questions, the pilot design and the criteria for putting it into ongoing operation.

Decision rule: for each use case, the business case must show cost, benefit, uncertainty, risk and decision point; a portfolio view alone is not enough.

Sources and how to interpret them

Platform documentation explains features and limits, and authority sources explain the legal context. Publications by providers and associations must be classified accordingly, not as a general market price or proof of success. Information on how maitiq works is available at maitiq.com.

Have maitiq review your specific case.