On this page
Learning objectives
- Choose a deployment unit with visible business and system boundaries
- Define embedded ownership across marketing, data, engineering, risk, and operations
- Plan integration, adoption, runbooks, and service expectations together
- Transfer operation only after evidence shows the receiving team can run and improve it
Before you start
- • A bounded workflow that has passed its evaluation and risk gates
- • Named business, technical, data, risk, and operating owners
- • Access to systems of record, baseline metrics, users, and incident history
Working definition
Forward deployed marketing
Forward Deployed Marketing is an embedded delivery model in which strategy, data, automation, agents, measurement, and adoption are built inside a real marketing workflow. The delivery team operates the system with users until ownership, reliability, recovery, and improvement are explicit. It is a way to close the gap between a prototype and dependable weekly work, not a promise that every workflow needs custom software.
Marketing systems usually fail at seams: permissions, record ownership, stale data, exceptions, review load, vendor changes, and unclear on-call responsibility. A strategy deck cannot resolve those operating conditions.
Embedded work shortens feedback between builders and operators. A bad field mapping, confusing approval packet, or unsupported exception appears during real use and can be corrected within the same accountable unit.
Adoption is part of the product. Training, interface fit, service expectations, local champions, manual fallbacks, and change communication belong in the deployment plan.
Handoff should be demonstrated through operation. Documentation alone does not prove that a receiving team can diagnose a failure, recover a run, change a rule, evaluate a release, or manage a vendor exit.
Field situation
Vela Industrial quarterly campaign operating system
Named synthetic scenario. Vela Industrial is fictional and the 90-day plan contains no claimed client or commercial result.
- Owner
- You are the deployment lead turning a validated industrial campaign workflow into a system used by product marketing, regional teams, legal, and revenue operations.
- Decision
- Define a 90-day deployment, operating model, acceptance gates, and handoff conditions for one production workflow.
- Starting state
- A pilot can assemble evidence and recommend a campaign brief, but it uses test credentials, one region, and a builder-operated review queue. Regional marketers still copy the brief into separate tools and no one owns dependency incidents after launch.
- Expected outcome
- A deployment charter with phases, roles, architecture, risk register, runbook, scorecard, adoption plan, and evidence-based transfer decision.
Constraints
- • The first production boundary covers one region and one campaign type
- • CRM, content, identity, and project systems remain authoritative
- • The agent stays in recommendation mode during the first production phase
- • Handoff requires recovery drills and two receiving-team-operated release reviews
Worked example
Scoping one region before building a global campaign platform
Evidence status: Named synthetic scenarioVela stakeholders ask for multilingual generation, global campaign planning, automatic CRM updates, and media activation. The pilot evidence covers only one English-language regional brief, and the receiving team has not operated the failure queue.
The deployment unit remains the approved-evidence-to-brief workflow for one region. Days 1 to 30 confirm architecture, data ownership, access, baselines, and user journeys. Days 31 to 60 integrate managed identities, production records, approval, logs, and manual recovery while the embedded team operates the queue. Days 61 to 90 test real volume, train users, run incidents, and have receiving owners conduct two release reviews. Multilingual work, CRM mutation, and activation remain future decisions.
The example produces a credible operating boundary and a transfer test. It rejects premature platform scope without rejecting future expansion. No efficiency, adoption, pipeline, or revenue outcome is asserted.
Limits
The scenario is synthetic. Ninety days may be too short for low-volume workflows, procurement, privacy review, or complex integration. Embedded delivery can add coordination cost and should not replace clear product ownership. Tenten's field material describes its service approach and is not independent evidence of outcomes.
Method
Build it, with checkpoints
Field situation
Define a 90-day deployment, operating model, acceptance gates, and handoff conditions for one production workflow.
- 01Choose the smallest material deployment unit
- 02Map ownership and production architecture
- 03Set phased gates and service expectations
Acceptance checks
A production plan that connects technical integration with human operation. It makes scope, owners, gates, risk, service expectations, user adoption, recovery, and transfer visible, while preserving evidence requirements for later expansion.
- 01
Choose the smallest material deployment unit
Name one workflow, consumer decision, region, campaign type, volume, user group, systems, and permitted action class. List adjacent requests as out of scope with their own evidence needs.
CHECKPOINT · Every stakeholder can state what reaches production in 90 days and which attractive capabilities will not.
- 02
Map ownership and production architecture
Document systems of record, data contracts, identities, approvals, external dependencies, observability, error queue, retention, fallback, and exit. Assign responsible and accountable roles for routine operation and incidents.
CHECKPOINT · No data field, credential, approval, vendor, failure queue, or on-call decision is left with an implied owner.
- 03
Set phased gates and service expectations
Use discovery, shadow operation, limited live operation, and transfer. Attach quality, reliability, cost, adoption, risk, and recovery evidence to each gate. Define incident severity and response targets appropriate to the workflow.
CHECKPOINT · Failure of any hard risk gate blocks the next phase, and schedule pressure cannot silently change acceptance criteria.
- 04
Operate with users and close exceptions
Run real volume within scope. Hold weekly trace, queue, user, metric, and risk reviews. Convert repeated manual exceptions into product decisions, documented rules, or intentional human work.
CHECKPOINT · The exception backlog records frequency, impact, owner, disposition, and whether the fix changes policy, code, training, or scope.
- 05
Prove transfer and choose the next boundary
Have the receiving team operate a release review, handle a dependency outage, recover a partial run, rotate a credential, update a rule, and explain the scorecard. Decide retain, transfer, revise, retire, or propose one separately evaluated expansion.
CHECKPOINT · Handoff is accepted through observed demonstrations, current documentation, access ownership, and a signed post-transfer support boundary.
Hands-on lab
Draft a 90-day deployment and operating charter
Use Vela or a validated workflow from this track. Do not expand scope to adjacent workflows unless their data, users, risk, and acceptance evidence are separately understood.
Prepare
- • Bring the workflow charter, evaluation scorecard, architecture, user list, and incident examples
- • Interview the business owner, daily operator, reviewer, system owner, risk owner, and receiving manager
- • List contracts, access reviews, and policy decisions that can block production timing
Deliverable
A signed charter, responsibility map, phased backlog, system and data diagram, risk register, service and incident runbook, adoption plan, scorecard, and handoff demonstration script.
Starter kit: Forward-deployed charter
Copyable Markdown# 90-day deployment charter
Workflow and business decision:
In-scope region, campaign, users, volume, systems, and action class:
Explicitly out of scope:
Current baseline and evidence:
Business owner / product owner / technical owner / data owner / risk owner / operator / on-call:
System-of-record map and data contract:
Phase 1 discovery and production design gate:
Phase 2 integration and shadow-operation gate:
Phase 3 live operation and transfer gate:
Quality / reliability / cost / adoption / risk thresholds:
Approval and autonomy stage:
Service expectations and incident severity:
Manual fallback, rollback, and vendor exit:
Training and change plan:
Handoff demonstrations:
30 / 60 / 90-day decisions:
Expansion backlog with separate evidence requirements:Expected result
A production plan that connects technical integration with human operation. It makes scope, owners, gates, risk, service expectations, user adoption, recovery, and transfer visible, while preserving evidence requirements for later expansion.
Carry forward
The charter, scorecard, runbook, and transfer record become the operating baseline. Reuse the same gates when a model, vendor, region, language, data source, or autonomy level changes.
Acceptance checks
- 01Scope identifies one workflow, region, campaign type, user group, volume, systems, and action class
- 02The responsibility map names business, product, technical, data, risk, operator, and incident owners
- 03Each phase has observable quality, reliability, cost, adoption, and risk gates
- 04Runbooks cover manual operation, partial failure, dependency outage, rollback, credential rotation, and vendor exit
- 05Real-user feedback and exception work feed a prioritized operating backlog
- 06The receiving team completes at least two release reviews and the required recovery demonstrations
- 07Expansion items remain separate decisions with explicit evidence prerequisites
What breaks
Failure clinic
F1The program produces a polished roadmap but weekly work remains unchanged.
- Inspect
- Compare deck milestones with live integrations, user actions, queue ownership, and accepted outputs.
- Likely cause
- Delivery stopped at strategy and did not own implementation or adoption.
- Repair
- Return to one bounded workflow, place builders with operators, and gate progress on observed use.
- Prevent next time
- Contract and plan around operating acceptance rather than document delivery alone.
F2A custom platform grows before one workflow has stable demand or rules.
- Inspect
- Review pilot adoption, exception distribution, repeated needs, existing platform capability, and irreversible build choices.
- Likely cause
- Architecture ambition outran evidence from the deployment unit.
- Repair
- Freeze expansion, simplify to the validated path, and retire unused components where safe.
- Prevent next time
- Require a passed workflow gate and reuse analysis before custom platform investment.
F3The receiving team owns production on paper but cannot diagnose a failed run.
- Inspect
- Observe access, alert routing, runbook use, recovery steps, release review, and escalation behavior.
- Likely cause
- Handoff was measured by training attendance and document delivery.
- Repair
- Restore embedded support, run scenario-based demonstrations, and transfer authority in stages.
- Prevent next time
- Make independent operation and recovery an acceptance test.
F4Regional expansion introduces unsupported claims, broken consent logic, or overloaded review.
- Inspect
- Compare new language, evidence, policy, data, volume, reviewers, and service needs with the validated boundary.
- Likely cause
- Expansion was treated as configuration instead of a new risk and evidence context.
- Repair
- Pause the new boundary, return to recommendation or manual mode, and validate regional requirements separately.
- Prevent next time
- Create release gates for every new geography, language, data source, action class, and volume tier.
Beyond the demo
Production boundary
- 01The deployment unit and explicit exclusions are signed by business and delivery owners
- 02System-of-record, data contract, identity, retention, and access ownership are documented
- 03Architecture reuses existing capabilities where they meet the validated need
- 04Quality, reliability, cost, adoption, and risk gates control each phase
- 05Service expectations, alerts, queue ownership, incident severity, and escalation are live
- 06Manual operation, rollback, partial recovery, dependency outage, and vendor exit are rehearsed
- 07User training, office hours, champions, feedback, and workflow changes have accountable owners
- 08Run, trace, review, cost, incident, and adoption records support the weekly operating review
- 09Receiving operators demonstrate release, recovery, credential, rule, and scorecard tasks
- 10Every expansion in region, language, system, volume, or autonomy receives a separate gate
Evidence status
Sources and claim limits
Sources support the named claims; they do not guarantee the same result in another system.
- [1]OpenAI Academy Courses: Champion Deployment Guidedeployment sponsorship · enablement cadence · adoption measurement
OpenAI Academy · Official documentation · 2026-08-20
- [2]Improving support with every interaction at OpenAIfrontline feedback · trace review · evaluation and knowledge operations
OpenAI · Public case · 2026-08-20
- [3]Forward Deployed Marketingembedded delivery · integration · operating ownership
Tenten AI · Tenten field method · 2026-08-20
- [4]Forward Deployed Marketing Enterprise Playbookdeployment decisions · governance · handoff planning
Tenten AI · Tenten field method · 2026-08-20
- [5]Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profilerisk ownership · measurement · human oversight
NIST · Official documentation · 2026-08-20
- [6]AI RMF Core: Measuremeasurement design · monitoring · risk metrics
NIST AI Resource Center · Official documentation · 2026-08-20
Related Tenten resources