I've spent my career building marketing for the Saudi market, mostly from the operator's chair and not the vendor's pitch deck. That seat teaches you one thing fast: the first 90 days of anything new are a test, not a rollout. The goal is not to “AI-enable” the entire department. It is to prove that the company can select the right workflow, connect it to trusted data, operate it safely, get the team to use it, and measure whether it improves a business decision.
That is harder than launching a chatbot or buying a content platform. It is also worth far more.
Most transformation programmes fail quietly. The tools remain active, but work continues through spreadsheets, private messages, and manual reports. Leadership sees pilots, the team sees extra steps, and finance sees no dependable connection to revenue.
Here is the unpopular part, after watching a lot of these programmes start well and stall anyway: the tool you pick is the least important decision in the whole exercise. Most of this market will sell you the model and quietly disappear before the hard part, which is whether a real person opens the thing under deadline pressure on an ordinary Tuesday. Given the choice, take the boring workflow people will actually use over the impressive one they will admire and avoid.
A better 90-day plan has three phases:
- Days 1–30: diagnose the operating system and choose the first bets.
- Days 31–60: build, test, and run one high-value workflow.
- Days 61–90: stabilise adoption, reconcile outcomes, and decide what to scale.
The result should be a working capability, not a presentation.
The 90 days at a glance
| Phase | Focus | Primary owner | Gate decision |
|---|---|---|---|
| Days 1–30 | Audit: diagnose workflows, agree scope, set the baseline | Operating owner + executive sponsor | Approve one pilot |
| Days 31–60 | Build: ship the minimum viable workflow, test it with real users | Operating owner + workflow owner | Continue, redesign, or stop |
| Days 61–90 | Optimise: stabilise, train, decide the operating model | Operating owner + business owner | Scale, stabilise, extend, or stop |
Start with a transformation thesis
Before selecting tools, write a one-sentence thesis that connects the programme to a commercial constraint.
Useful examples:
- “Reduce the time from approved campaign idea to launch without weakening brand or compliance review.”
- “Improve lead response and qualification so paid acquisition is optimised against sales-ready opportunities.”
- “Reconcile ad spend with CRM and collected revenue so budget decisions use financially meaningful outcomes.”
- “Turn fragmented customer evidence into reusable inputs for campaign strategy and content.”
Weak theses sound like:
- “Use generative AI across marketing.”
- “Automate 50% of tasks.”
- “Increase content output.”
The weak versions describe technology or activity. The stronger versions describe an operating constraint and the decision that should improve.
Days 1–30: diagnose before you automate
The first month should create a reliable picture of how marketing works through a focused operational diagnosis.
Week 1: align leadership and define the commercial boundary
Bring together the executive sponsor and the leaders of marketing, sales, operations, finance, and technology where relevant.
Agree on:
- the primary commercial problem;
- the markets and business units in scope;
- the decisions the programme may change;
- the systems that hold customer and revenue data;
- security, privacy, and brand constraints;
- who can approve process changes;
- what is explicitly out of scope for the first 90 days.
Across the UAE, Qatar, and Saudi Arabia, surface differences in language, offers, approvals, customer expectations, sales ownership, and data access. A regional workflow may need market-specific rules.
Week 1 deliverable: a one-page transformation charter with the thesis, scope, sponsor, operating owner, and decision rights.
Week 2: map the current workflows
Do not map the marketing org chart. Map the movement of work.
Choose the important recurring flows, such as:
- customer research to campaign brief;
- campaign brief to creative approval;
- lead capture to sales follow-up;
- content request to publication;
- ad spend to revenue reporting;
- customer feedback to retention action.
For each workflow, record:
| Element | Question |
|---|---|
| Trigger | What starts the work? |
| Inputs | Which data, documents, and decisions are required? |
| Steps | What actually happens, including workarounds? |
| Owners | Who performs and approves each step? |
| Systems | Where does the work and data live? |
| Delay | Where does work wait? |
| Failure | What repeatedly goes wrong? |
| Outcome | Which business decision or customer result does it support? |
Observe the work rather than accepting the official process; reality often differs from documentation.
Week 2 deliverable: current-state maps and a list of delays, rework, data gaps, and decision bottlenecks.
Week 3: establish the measurement baseline
You cannot prove improvement if the baseline is “the team feels busy.”
Choose measures from four categories:
- Speed: cycle time, waiting time, response time.
- Quality: error rate, revision rate, approval rejection, data completeness.
- Adoption: active users, workflow completion, manual bypasses.
- Commercial relevance: qualified opportunities, fulfilled orders, collected revenue, retention, or cost-to-serve.
Every pilot should connect an operational metric to a commercial reason.
For revenue-facing workflows, define the outcome hierarchy clearly:
Platform event → lead/order → qualified/fulfilled outcome → collected revenue
The stages must not be treated as interchangeable. If your paid media dashboard cannot be reconciled with the CRM or order system, that is part of the transformation scope, not a footnote. The guide to reconciling Meta, CRM, and collected revenue provides a working model.
Week 3 deliverable: baseline scorecard, data definitions, and known evidence gaps.
Week 4: prioritise and design the pilot
Score candidate workflows from 1 to 5 against:
- business impact;
- frequency;
- current friction;
- data readiness;
- implementation effort;
- governance risk;
- team willingness;
- reusability across markets or teams.
Do not simply choose the highest total. Choose:
- one workflow that can demonstrate operational value quickly;
- one measurement foundation that improves future decisions;
- one longer-term capability to investigate.
Then design the first pilot in detail:
- trigger;
- inputs and approved sources;
- AI or automation step;
- human review;
- system of record;
- exception path;
- owner;
- users;
- success thresholds;
- stop conditions.
Day 30 decision: approve one pilot for production testing. Keep the rest in a ranked backlog.
Quick wins that build momentum before day 30
A full pilot takes weeks to reach a verdict, but a transformation programme also needs visible proof of momentum before day 30, something concrete enough that sceptical stakeholders relax. None of these replace the diagnosis above; they run alongside it.
- Fix one broken measurement link, such as tagging that breaks lead source at the CRM. It takes days, not weeks, and it improves the baseline for every workflow that follows.
- Automate a single low-risk, high-frequency step inside a workflow you have already mapped, such as a first-draft or summarisation step with mandatory human review, never a customer-facing action. If you are unsure which step qualifies, the shorter checklist of marketing workflows worth automating is a faster starting point than the full programme.
- Publish the current-state workflow map itself. Teams rarely see their own process laid out end to end, and the exercise alone tends to surface two or three fixes that never needed AI in the first place.
- Close one long-standing data-access gap, such as API credentials, a shared dashboard, or a missing CRM field, that has been blocking reporting for months regardless of AI.
Quick wins earn the credibility to run a longer pilot. They are not the transformation.
Days 31–60: build for real work
The second month turns the chosen workflow into something a team can use. You are not chasing technical completeness here; you want dependable operation under normal conditions.
Week 5: create the minimum viable workflow
Build the smallest end-to-end version that reaches a real user and a real system of record.
For example, an AI-assisted campaign brief workflow might:
- collect an approved request;
- retrieve relevant customer evidence and brand rules;
- draft the brief in a standard format;
- flag unsupported claims or missing inputs;
- route the draft to a human approver;
- store the approved version in the campaign workspace.
Avoid adding every channel, language, and exception immediately. Complexity should be earned by observed use.
Week 6: test quality, controls, and exceptions
Test with normal, difficult, and incomplete inputs.
Ask:
- What happens when required data is missing?
- Can the system cite the source used for a factual statement?
- Which outputs require human approval?
- Who can see sensitive customer data?
- How are rejected outputs captured and improved?
- What happens when an integration fails?
- Can users complete the work manually if the automation is unavailable?
Evaluate AI quality against a defined rubric. Content, for instance, can be checked for factual support, audience relevance, offer accuracy, brand tone, language quality, and prohibited claims.
Week 7: run with a small user group
Choose users who perform the workflow regularly, and include at least one constructive sceptic. The sceptic is not a morale problem. The sceptic is your best instrument. Run the new process alongside the previous one where the risk justifies a comparison.
Then watch what people actually do, not what they report in the standup. Notice the steps they quietly skip and the fields they misread. Pay attention when an output gets rewritten from scratch, because a draft that always gets rewritten is not saving anyone time. After that, the usual suspects show themselves: the unofficial channels that refuse to die, the approval that adds a day, the data that arrives too late to matter, and the workflow that has simply moved work around instead of removing it.
Week 8: measure and revise
Compare the pilot with the baseline. Do not rely on a single headline metric.
A workflow may be faster but produce more revisions. It may generate more leads but reduce qualification quality. It may save analyst time but depend on fragile manual exports.
Use a balanced pilot review:
- operational change;
- quality change;
- user adoption;
- commercial signal;
- failure rate;
- new risk introduced;
- maintenance burden.
Day 60 decision: stop, redesign, continue, or prepare for wider rollout.
Days 61–90: turn the pilot into capability
The third month separates a useful demo from transformation. The work now shifts toward ownership, repeatability, and executive decision-making.
Week 9: stabilise the workflow
Resolve the most common exceptions. Simplify steps that users bypass. Confirm permissions, logging, and backup procedures. Remove features that do not improve the outcome.
Document:
- standard operating procedure;
- input requirements;
- review checklist;
- escalation path;
- system owner;
- business owner;
- maintenance cadence;
- change log.
Week 10: train for judgment, not button-clicking
Users need to understand:
- what the workflow is designed to do;
- what it cannot reliably do;
- how to recognise poor outputs;
- which sources are permitted;
- when to override or stop the process;
- how their feedback changes the system.
Managers need separate training on how to evaluate results without rewarding raw output volume.
For Arabic and English regional marketing, quality assurance should be language-specific. Translation is not equivalent to locally credible Arabic marketing; reviewers must reject literal or culturally weak copy.
Week 11: connect the management cadence
Create a short recurring review that focuses on decisions:
- Is the workflow being used?
- Is it improving speed or quality?
- Which exceptions are growing?
- Does the commercial signal justify continued investment?
- What change should be made before the next review?
The scorecard should fit on one page. A transformation programme that requires a complex dashboard to explain whether one workflow works is probably measuring too much.
Week 12: decide the next operating model
At day 90, choose one path:
- Stop: the workflow does not create enough value or carries unacceptable risk.
- Stabilise: keep the current scope and improve reliability before expanding.
- Scale: roll the workflow into more teams, channels, languages, or markets.
- Extend: begin the next workflow while the first remains governed.
Also decide who leads the next phase:
- internal owner;
- fractional AI marketing leader;
- specialist implementation partner;
- agency;
- full-time hire.
The answer depends on whether the next constraint is leadership, technical capability, or execution capacity.
Who owns each phase
A 90-day programme fails less often for lack of good tools than for lack of a name attached to each decision. Assign these roles before day 1, and revisit them at every 30-day gate.
| Role | Responsibility | Typically held by |
|---|---|---|
| Executive sponsor | Approves the thesis, protects scope, removes organisational blockers | CMO, CEO, or GM |
| Operating owner | Runs the programme day to day, chairs the review cadence, owns the day-30/60/90 decision | Marketing ops lead or fractional AI marketing leader |
| Workflow owner | Owns the specific workflow being piloted — can explain every step without notes | Campaign manager, growth lead, or CRM owner |
| Business owner | Accountable for the commercial outcome the workflow is meant to move | Head of marketing, sales, or the relevant P&L owner |
| Technical/data owner | Maintains the integration, data access, and system reliability | IT, marketing ops, or an implementation partner |
| Approver | Signs off outputs that require human review before they go live | Brand, legal, or compliance, depending on the workflow |
If no one can name who holds each of these six roles, the workflow is not ready for a production pilot.
Governance that belongs in the first 90 days
Governance belongs inside the workflow design from the start, not in a document bolted on once the pilot has already worked.
At minimum, define:
Data rules
- approved data sources;
- prohibited sensitive inputs;
- retention and deletion expectations;
- user permissions;
- vendor access;
- treatment of customer and employee information.
Content and decision rules
- outputs that require human approval;
- claims that require evidence;
- brand and legal review;
- actions the system may recommend;
- actions it may execute automatically;
- thresholds that trigger escalation.
Ownership rules
- business owner;
- technical owner;
- data owner;
- approver;
- incident contact;
- person accountable for adoption.
The simplest useful rule is: every automated action must have an owner, and every owner must know how to inspect and stop it.
Metrics that matter at each gate
The baseline work from Week 3 and the balanced review from Week 8 both feed a single scorecard. Keep it in one place, and keep it to a page.
| Day 30 | Day 60 | Day 90 |
|---|---|---|
| Baseline cycle time, error rate, and current commercial signal recorded | Cycle time, quality, and adoption compared against baseline | Commercial signal reconciled through to collected revenue or fulfilled outcome, where applicable |
| Data gaps and evidence gaps listed | Bypass rate and manual workaround rate measured | Scorecard running on a recurring cadence with a named owner |
| Pilot success thresholds and stop conditions defined | Continue, redesign, or stop decision documented | Scale, stabilise, extend, or stop decision documented |
If a metric cannot change a decision at the next gate, it does not belong on the scorecard yet. Measuring automation ROI properly means tracing effort back to a commercial outcome, not counting activity.
Risks to watch across all three phases
Treat these as a running risk register, not a one-time checklist at kickoff.
- Data risk — the workflow touches customer or employee data it was not scoped to touch. Mitigate with the data rules defined under governance, checked at every gate, not only on day 1.
- Brand and compliance risk — content or claims ship without the review step actually happening under deadline pressure. Mitigate by making the approval step visible inside the tool, not a side conversation.
- Adoption risk — the workflow works technically but the team quietly reverts to the old process. Mitigate by watching bypass rate, not just usage logs.
- Reconciliation risk — a lead-generation or paid-media workflow scales before its output can be traced to collected revenue. Mitigate by holding the scale decision until the reconciliation model in Meta, CRM, and collected revenue actually closes.
- Vendor and platform risk — a workflow becomes dependent on a single vendor's roadmap or pricing. Mitigate by keeping a manual fallback path documented through day 90.
- Governance drift risk — the rules agreed in week 1 quietly stop being enforced once the pilot gets busy. Mitigate by re-confirming ownership at every 30-day gate, not only at the start.
Common 90-day mistakes
Starting with the most impressive use case
High-autonomy campaigns or broad content engines attract attention, but they often combine poor data, subjective quality, and unclear ownership. Start where the workflow is frequent, measurable, and governable.
Automating a broken process
If approvals, responsibilities, or data definitions are confused, automation makes the confusion move faster. Simplify before adding technology.
Treating adoption as training attendance
A completed workshop does not mean the workflow is used. Measure actual completion, bypasses, repeated errors, and manager behaviour.
Measuring only hours saved
Time matters, but saved time has no value unless it is removed, redeployed, or converted into better work. Pair efficiency with quality or commercial outcomes.
Scaling before reconciliation
Do not expand a lead-generation or paid-media workflow when downstream revenue cannot be reconciled. More volume can magnify a measurement error.
Ignoring the operating owner
Executive sponsorship opens doors. A named operating owner keeps the system alive after the launch.
90-day executive checklist
By day 30:
- Transformation thesis approved.
- Scope and exclusions documented.
- Current workflows mapped.
- Baseline metrics agreed.
- Pilot selected with a named owner.
By day 60:
- End-to-end pilot used in real work.
- Human review and exceptions tested.
- Security and data controls verified.
- Operational and quality measures compared with baseline.
- Continue, redesign, or stop decision made.
By day 90:
- Workflow documentation complete.
- Internal owner and backup trained.
- Management scorecard running.
- Commercial outcomes reconciled where applicable.
- Scale, stabilise, extend, or stop decision approved.
What success looks like
Success after 90 days is not a department transformed beyond recognition. It is evidence that the company can repeatedly transform work:
- choose a meaningful constraint;
- design a controlled workflow;
- connect it to trusted data;
- win user adoption;
- measure the operational and commercial effect;
- transfer ownership;
- make an informed scale decision.
Once that pattern is established, later workflows become faster and less risky. The first 90 days build the company’s transformation muscle. The first automation is only the proof that the muscle works.
Build the roadmap around your real constraint
Start your 90-day AI marketing transformation the same way the phases above are structured: diagnose, build, then decide what has earned a wider rollout. That is the shape of my AI marketing systems work, whether you run the programme internally or bring in outside help for the first cycle.
If you want help turning scattered AI experiments into a governed 90-day transformation programme, request a systems diagnostic. For a quicker discussion, message Ahmed on WhatsApp.