How to assess an AI marketing implementation partner objectively

A suitable partner is not the organisation with the longest tool list. It can translate a clearly bounded marketing problem into a verifiable process, name dependencies and limits, build in controls, and hand over knowledge as well as the ability to operate. The selection therefore begins with your brief, not with the provider’s pitch.

Before the search: scoping the brief

Write a one-page problem briefing before you collect names. It should answer:

• Which marketing task or decision should improve?
• How does the process work today, and what baseline is known?
• Which users, customers or employees are affected?
• Which data would be needed, and who may approve access?
• Which errors are critical, and who stops the process?
• What must the team be able to operate or develop further in-house at the end?

A brief such as “introducing AI in marketing” is too broad to compare proposals. “Producing an internally reviewed draft briefing from approved product documents and testing it against today’s process” is bounded enough to compare capabilities, price and risk.

The SECO SME Portal points to the fragmented Swiss AI landscape and to SAIROP for orientation on research partners and service providers. SAIROP describes itself as a network hub. However, the reviewed partners page carries no accreditation, independent quality review or marketing specialisation. So use a directory for preliminary research, not as a pre-vetted shortlist.

Eight assessment areas for the longlist

1. Understanding the problem instead of a demo

A good candidate asks about the starting position, the users, the consequences of errors and the alternative without AI. Have every candidate structure the same anonymised problem case. Compare their questions and assumptions, not the speed of a prepared demo.

Warning sign: the provider commits to a product before data, integration, risk or success criteria are clarified.

2. Demonstrable marketing and domain expertise

Ask for examples that resemble your brief in task and risk class. A generic chatbot does not demonstrate expertise in media management, personalisation or marketing measurement. When taking references, ask about the baseline, the partner’s role, the client’s role, the test method, failures and the operational status.

Confidential references cannot be disclosed in full. In that case the provider should at least show concrete documents and method: anonymised test plans, defined roles and responsibilities, evaluation frameworks or handover structures. A percentage without a methodology is not evidence.

3. Data and system boundaries

The partner must be able to explain the data flow: source, purpose, transfer, storage, access, retention, deletion and possible use by subprocessors or model providers. Ask which data is explicitly excluded and how test data is produced.

An architecture diagram is only useful once responsibilities are visible. Who maintains the interfaces? What happens during an outage? Which logs does the client team receive? How are model or provider changes detected? Answers such as “it is all in the cloud” are not enough.

4. Evaluation and evidence

Agree test cases and acceptance criteria before implementation. A partner should distinguish between technical function, output quality, process impact and business impact. Ask for counter-examples and difficult cases as well. Rare critical failures must not disappear inside an average score.

The supplier should disclose which parts are synthetic, manually assessed or derived from production data. If a model is non-deterministic, the test needs repeated runs and documented versions.

5. Governance and human authority

Clarify who approves inputs, reviews outputs, authorises changes, handles incidents and accepts residual risk. “Human in the loop” is too imprecise. The contract or operating plan must name the role, the point in time, the information and genuine rights to stop the process.

A review structure should cover inventory, roles, third-party risks, monitoring, incidents and decommissioning. What follows is an editorial procurement template, not an external certification standard. The OECD accountability principle provides a sound guiding idea: data, processes and decisions should remain traceable. Ask the partner, therefore, not only for assurances but for concrete documents and accountable roles.

6. Security, data protection and rights

Ask for answers not only from sales but from the specialists responsible. What is needed includes an authorisation model, encryption, logging, a deletion process, an incident reporting route, a list of subprocessors, rights in inputs and outputs, and rules for confidential data.

Your data protection, security and legal leads decide which review is actually required. A certificate can be part of the evidence, but it does not replace the review of the specific data flow and use case.

7. Operation and change

A successful pilot demo does not answer who runs the system on Monday morning. Ask about monitoring, support hours, error classes, recovery, cost control, capacity limits, model updates and regression tests. Define which change triggers a fresh approval.

A partner should also be able to explain when a manual alternative is better and how it is activated. Anyone who shows only the normal case has not yet described operations.

8. Handover and exit

The client team needs more than access credentials. Require documentation on purpose, architecture, data, prompts or rules, test cases, known limits, decisions, suppliers, operation and open risks. Determine which deliverables reside in a client-owned system and in which format data can be exported.

The OECD accountability principle yields a concrete question for procurement: which evidence on data, processes and decisions does your organisation hold itself once the project ends?

Commission discovery, pilot and operation separately

A fair procurement process divides the project into decision phases. Discovery delivers the problem definition, the data and risk picture, options and a pilot plan. It does not authorise production deployment. Pilot delivers a limited implementation and evidence against criteria defined in advance. A successful pilot does not yet authorise ongoing operation. Operation covers integration, responsibilities, monitoring, support, change control and exit.

This separation protects both sides. Your organisation can stop after any phase or change the scope. The partner does not have to hide uncertainties inside an apparently firm overall commitment. Price offers become more comparable when every deliverable and every assumption is named.

A fixed price can make sense for discovery, provided the deliverables are clear. A pilot needs a budget ceiling and a stop point. In operation, variable infrastructure or model costs should be shown separately from services. Avoid remuneration that rewards the partner for higher usage alone when quality and risk are not measured as well.

Questions for reference calls

Where possible, speak to business and technical people on the client side. Do not ask only “Were you satisfied?”, but:

• Which problem was measurable before the start?
• Which assumption turned out to be wrong?
• How much rework remained after the pilot?
• Who operates and monitors the solution today?
• Which documentation and test cases were handed over?
• How did the partner respond to a failure or a change of scope?
• Which dependency would you negotiate differently next time?

The answers depend on the context. A good reference is not a guarantee, but it shows whether the provider speaks as concretely about operation and learning as about the start.

Assessment without false precision

Do not trade mandatory requirements away for glossy bonus points. Unresolved data use, a missing right to stop, unnamed subprocessors or an unmanaged handover can be grounds for exclusion. Only among the candidates that meet every mandatory requirement do you assess domain understanding, approach, team, cost and collaboration.

Have each assessor record their rationale before the group discussion. That way the best presentation does not automatically dominate. Clearly mark assumptions and evidence that is still outstanding. A “partly” is not a silent “yes”.

What a partner should not promise

Be sceptical about a guaranteed ROI without a baseline, complete freedom from error, automatic legal compliance, instant integration into “any” system, or a black box that delivers no test and operating documents. The claim that a general AI project demonstrates marketing expertise is just as problematic.

The right partner does not have to deliver everything itself. It must make limits transparent, name the specialists required and accept a clear responsibility matrix. For a Swiss team, that is more robust than the idea of a single universal AI provider.

How maitiq helps: a work sample says more than the tool list

Give prospective partners the same anonymised process case: a lead arrives with incomplete details and has to be routed to the right person. Ask for the proposed process, a visible result, the handling of missing data, and a plan for handover and operation. A good proposal also names which interface or data quality is initially missing.

In an agreed project, maitiq accompanies the technical setup, an understanding of current processes, training and the start of operation. Assess the partner by whether your team can explain the process after handover, use it and handle exceptions. The concrete scope of services belongs in the proposal; a convincing demonstration does not replace it.

A track record is only as sound as its comparability: task, risk class, the partner’s role, the measurement method and the operational status must match your own brief. General assurances do not replace this check.

How a first pilot with maitiq begins

An initial discovery phase shows how maitiq would scope your use case, implement it and move it into measurable operation with your team. You receive a clearly defined use case, the open data and control questions, a pilot plan and the criteria for later operation.

Sources and how to read them

The linked sources are specific: the SECO SME Portal interview describes how Swiss SMEs use artificial intelligence successfully. The SAIROP partners page describes the network and four partnership types, but no accreditation. The OECD accountability principle (P9) offers guidance on governance and traceability. Information about how maitiq works is available at maitiq.com.

Have maitiq review your specific case.