Current time, cost and quality
Establish current task volume, effort, waiting time and errors. Agree which improvement matters and how it will be observed.
Delivery process
How we deploy marketing AI.
We review the task with your marketing team, connect the required data and tools, build the workflow, and test it with users. We then support rollout, training and handover.
Before committing to a build
Before the project starts.
A useful starting point has a recurring task, an accountable owner and data the team can legally access. A process that changes every week may need clarification before automation.
Data and system access
Confirm permissions, source quality, refresh frequency and a technical path into the existing environment.
People available for testing
Identify operators and reviewers who can test the workflow. Reserve time for feedback, training and acceptance.
Approvals and a manual fallback
Define the consequences of a wrong output, the actions that require approval and the manual process used if the system is paused.
Delivery stages
The deployment process.
The ranges below are planning illustrations, not fixed delivery promises. Source access, procurement, review requirements and integration complexity determine the schedule. Some stages overlap.
01 / Indicative 2–3 weeks
Define the project
Which task are we improving, and for whom?
Review the current process with the team that runs it. Record task volume, time, cost and error rates. Confirm which data is available and agree the scope of the first deployment.
- A defined use case and project owner
- Current time, cost and quality measures
- Data access and quality assessment
- Agreed scope and acceptance criteria
Review decision: Confirm an owner, usable sources and a baseline. Stop if the proposed benefit cannot be evaluated.
02 / Indicative 2–4 weeks
Design the workflow
What connects to what, and where is review needed?
Specify the data sources, software connections, AI tasks, dashboards and approval steps. Review the design with business and IT owners before implementation.
- Data and system integration plan
- Workflow steps and reviewer responsibilities
- Test plan and release criteria
- Implementation schedule and running-cost estimate
Review decision: Approve the integration and control design. Resolve access or policy restrictions before build.
03 / Indicative 4–10 weeks
Build and integrate
Does the workflow complete the agreed task?
Build the connections and AI workflow in the agreed environment. Add status reporting, error handling and a way to return to the manual process. Start with a limited group of users.
- A working implementation
- Dashboard or task queue for users
- Error and running-cost reporting
- Operating and recovery instructions
Review decision: Run the first version with a small user group. Check progress, errors and costs, and keep a manual fallback available.
04 / Indicative 2–4 weeks
Test with your team
How do quality, time and cost compare with the original process?
Test representative requests, missing data and common failure cases. Have users check outputs. Compare the results with the agreed acceptance criteria and fix issues before wider rollout.
- Test results and open issues
- Time, quality and cost comparison
- Feedback from users and reviewers
- A decision to launch, revise or stop
Review decision: Compare the agreed measures. Record a decision to expand, revise or stop, including operating cost.
05 / Indicative 1–3 weeks
Launch and hand over
Who runs and maintains it after launch?
Train the team, transfer access and documentation, and agree who handles support and changes. Confirm that the internal owner can run the workflow and resolve a typical failed request.
- Documentation and configuration
- Training for users and technical owners
- Access and support responsibilities
- A maintenance plan or separately agreed support scope
Review decision: Have the internal team run the workflow, respond to an exception and demonstrate a controlled change.
Efficiency and cost
Estimate the time saved.
Manual checking, exceptions and support can absorb part of the time an automation saves. Use a simple estimate to identify the assumptions that need testing before making a business case.
Estimate time released
Change the illustrative assumptions. This estimates hands-on capacity, not cash savings or total elapsed cycle time.
Illustrative monthly estimate
40 hoursNet hands-on capacity released under these assumptions.
- Current effort
- 150 h
- Assumed time reduction
- 60 h
- Additional review
- −20 h
To assess financial value, also include implementation, licences, model usage and support costs. Cash savings require a separate, evidenced reduction in expenditure.
Working responsibilities
Who does what.
Business owner
Chooses the workflow, agrees the baseline and accepts or rejects the outcome. Makes the decision to expand, revise or stop.
Data and platform owners
Approve source access, integration patterns and operational requirements. Provide the environments and permissions needed for delivery.
Risk and specialist reviewers
Set the review requirements for claims, personal data, brand rights and consequential actions. Approve relevant test and release criteria.
Strategy Engineered
Documents the design, implements the agreed scope, runs evaluations and prepares the operating handover. Raises unresolved risks before release.
Handover
Documentation and training.
The team should know how to operate the workflow, investigate a failed run and release a change safely. Ongoing support is scoped separately when needed.
- Source and integration documentation, including permissions and retention
- Versioned prompts, configuration and evaluation cases
- Runbooks for monitoring, exceptions, incidents and rollback
- Training for operators, reviewers and the technical owner
- Access transfer, support contacts and an agreed change process