Clarify the task and decision
This guide turns agency implementation playbook into a reviewable operating workflow. It connects domain decisions, ownership, evidence, and acceptance so the result continues to work in production.
An agency rollout succeeds when discovery, architecture, content operations, accountability, handoff, and ongoing service are designed together.
Practical workflow
- 1
Establish a baseline from observed content volume, effort, delay, quality, support demand, and risk.
- 2
Define the target operating model, audiences, channels, ownership, integrations, and review standard.
- 3
Model cost and benefit with named data sources and separate confirmed values from assumptions.
- 4
Run a representative pilot with agreed acceptance measures and a decision date.
- 5
Approve scale-up only after owners accept the operating process, evidence, budget, and reporting cadence.
Worked example or tool
A responsibility matrix clarifies client, agency, specialist reviewer, IT, privacy, and product ownership. In the tool, also record the baseline, owner, decision, evidence, open issue, and approval date. Use a real page or transaction so the team sees dependencies, exceptions, and the maintenance work that follows release.
| Decision point | Record | Acceptance criterion |
|---|---|---|
| Baseline | Observed current state | Source and date recorded |
| Decision | Selected option and rationale | Risk and audience considered |
| Evidence | Test, document, or measure | Reviewable and version-specific |
| Approval | Name, role, and date | All mandatory criteria met |
Discover the service before designing the integration
Map audiences, journeys, source systems, content ownership, approval, publication, support, and measurement. Sample real content and observe editors at work. The implementation brief should expose exceptions, not only the ideal workflow.
Record non-functional needs for accessibility, security, privacy, performance, availability, retention, and audit. Confirm which organisation owns each decision and which evidence is required for acceptance.
Interview service, editorial, IT, and user representatives.
Inventory systems, content types, and volumes.
Document risks and mandatory controls.
Approve measurable acceptance outcomes.
Design architecture and responsibilities together
Choose synchronous API, batch, webhook, widget, or manual workflow according to user timing, failure tolerance, volume, and review. Define source of truth, identifiers, versioning, cache behaviour, retry safety, and rollback.
Create a responsibility matrix for content, terminology, credentials, configuration, incidents, supplier changes, accessibility, quality, and release. Every shared responsibility needs one accountable owner and an escalation path.
- 1
Diagram data and control flows.
- 2
Design failure and recovery states.
- 3
Assign accountable and supporting roles.
- 4
Review the design with operators and reviewers.
Deliver in verified slices
Start with one representative journey and production-like content. Test authentication, limits, malformed input, timeouts, retries, duplicate callbacks, inaccessible output, editorial rejection, and publication rollback. Instrument cost, latency, quality, and error causes.
Expand only after acceptance evidence is complete. Maintain decision records, configuration versions, test results, and known limitations. Treat training and operational documentation as deliverables, not post-launch extras.
Use protected test and staging environments.
Automate repeatable technical checks.
Run editorial and target-user acceptance.
Require release and rollback approval.
Handoff a service that can be operated
Provide runbooks, architecture, credentials inventory, dashboards, alert rules, support routes, release process, supplier contacts, data schedule, and recovery procedure. Pair agency and client staff through real incidents and releases before handoff.
Agree ongoing service levels for maintenance, quality review, security updates, model changes, and improvement. Test export and recovery, close temporary access, and record open risks with owners and dates.
- 1
Validate documentation through an operator exercise.
- 2
Transfer repositories, accounts, and evidence.
- 3
Remove temporary privileges and secrets.
- 4
Schedule service and benefit reviews.
Manage quality and change after launch
Create a service scorecard that combines technical reliability with editorial and user outcomes. Track successful requests, latency, failed jobs, manual corrections, terminology exceptions, review time, publication defects, target-audience findings, cost by content type, and avoidable support demand. Define the data source, calculation, reporting frequency, target, tolerance, and owner for every measure. A dashboard without agreed action thresholds records problems but does not manage them.
Introduce a controlled change path for prompts, models, terminology, integrations, content schemas, and provider settings. Each change should have a reason, affected audiences, risk assessment, representative evaluation set, accessibility review, security impact, rollback point, approver, and release record. Compare results with the previous version before deployment. Keep a small set of difficult and safety-critical examples so apparently harmless improvements do not silently reduce accuracy elsewhere.
Structure the agency relationship around transparent service improvement. Review recurring defects and user evidence together, decide which party owns correction, and price predictable maintenance separately from new scope. The client should retain access to source code, configuration, evaluation material, operational data, and supplier correspondence. This prevents knowledge becoming an agency dependency and lets a successor continue the service without rediscovering its basic decisions.
Define action thresholds for technical, editorial, and user measures.
Version every model, rule, prompt, glossary, and configuration change.
Evaluate changes against representative and safety-critical content.
Keep service knowledge and evidence accessible to the client.
Use release readiness evidence for every production change
Require one signed readiness record covering acceptance results, unresolved defects, migrated content, monitoring, support coverage, security approval, privacy conditions, user communication, rollback, and the person authorised to proceed. Hold a short early-life support period with daily review of failures, correction effort, and affected audiences.
Define exit criteria for that period before launch. Stable request processing alone is insufficient if editors still repair substantial output or users cannot complete their tasks. Move to normal operation only when technical, editorial, accessibility, and user thresholds remain within tolerance for the agreed duration. Carry every open item into the service backlog with impact, workaround, owner, and date.
Sign one readiness record before production release.
Monitor technical and content outcomes during early-life support.
Use predefined exit criteria across all quality dimensions.
Transfer every open item with impact, owner, and deadline.
Roles, evidence, and approval
A credible business decision remains useful after the presentation. Store assumptions with an owner, source, date, range, and sensitivity. Report quality and service outcomes alongside cost. Do not count benefits twice, and do not treat generated volume as reader value. The accountable owner should review actual results against the baseline after the pilot and at regular operating intervals.
Operations and maintenance
The work does not end at publication. Link the language version or configuration to its source, monitor quality and service measures, and define concrete review triggers. Triggers include source changes, legal changes, new audience needs, recurring support questions, technical changes, and incidents. A named owner evaluates the trigger, opens a new revision when needed, and records renewed approval.
Release checklist
The baseline uses observed data.
Audience and service outcomes are measurable.
One-time and recurring costs are separated.
Assumptions have owners and sensitivity ranges.
Quality, accessibility, security, and integration work are included.
Pilot acceptance criteria are agreed in advance.
Benefits are not double-counted.
The scale-up decision and reporting cadence are assigned.