AWE Work Product Templates

Agentic Workforce Era (AWE) Organizational Model Version: 1.0 | April 2026 | Internal — Confidential

Unfamiliar term? See the AWE Glossary.

---

Every piece of work in the AWE model flows through a defined structure. These templates replace Jira sprints, PRDs, and traditional project management. They're designed to be filled out quickly and used daily.

Work Product Hierarchy

CAP (Customer Account Plan)
 └── CSB (Customer Solution Build)          — BSA is STO
      └── TSB (Technical Solution Build)    — TSA is STO
           └── BC (Build Cycle)             — 3-day max, DPEV

PSB (Platform Solution Build)               — TSA-initiated
 └── TSB → BC (same structure)

---

1. CAP — Customer Account Plan

The strategic plan for a customer relationship. Owned by the BSA. Living document, updated continuously.

Template

# CAP: [Customer Name]

**BSA (Owner):** [Name]
**Created:** [Date]
**Last Updated:** [Date]

## Customer Overview
<!-- Who are they? What do they do? How big? What industry? -->

## Key Stakeholders
| Name | Role | Relationship | Notes |
|------|------|-------------|-------|
|      |      |             |       |

## Business Objectives
<!-- What is this customer trying to achieve with Worksuite? -->
1.
2.
3.

## Current Solution Footprint
<!-- What Worksuite products/services are they using today? -->
- Platform modules:
- Services:
- Integrations:
- Contract details:

## Growth Opportunities
<!-- Where can we expand? What problems aren't we solving yet? -->
1.
2.

## Active CSBs
| CSB | Status | TSA | Target Date |
|-----|--------|-----|-------------|
|     |        |     |             |

## Risk Register
| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|
|      |           |        |            |

## Relationship Health
<!-- How's the relationship? NPS? Recent sentiment? Escalations? -->
- Last check-in:
- Sentiment:
- Open issues:

Example: CAP for Omnicom Media Group

# CAP: Omnicom Media Group (OMC)

**BSA (Owner):** Ryan Doyle
**Created:** 2026-01-15
**Last Updated:** 2026-04-10

## Customer Overview
Global media and advertising holding company. 70,000+ employees across
200+ agencies. Using Worksuite for contractor management across US
advertising agencies (BBDO, TBWA, DDB).

## Key Stakeholders
| Name | Role | Relationship | Notes |
|------|------|-------------|-------|
| Sarah Chen | VP Procurement | Primary sponsor | Monthly check-ins |
| Mike Torres | IT Director | Technical contact | Manages SSO/integrations |
| Lisa Park | Agency Ops Lead | Day-to-day | Handles escalations |

## Business Objectives
1. Consolidate contractor management across all US agencies onto Worksuite
2. Reduce time-to-onboard for new contractors from 14 days to 3 days
3. Achieve full compliance visibility across all agencies by Q3

## Current Solution Footprint
- Platform modules: Contractor Onboarding, Payments, Compliance
- Services: PayOps (weekly payment runs), CompOps (compliance monitoring)
- Integrations: SAP (payments), Workday (HR sync)
- Contract details: 3-year MSA, signed June 2025

## Growth Opportunities
1. Expand to healthcare agencies (IPG Health division expressing interest)
2. International contractor management (UK, Canada offices)

## Active CSBs
| CSB | Status | TSA | Target Date |
|-----|--------|-----|-------------|
| Custom role permissions for agency-level admins | In Progress | Adam R. | 2026-04-25 |
| Canada payroll integration | Planning | TBD | 2026-05-15 |

## Risk Register
| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|
| SSO migration delay blocks rollout | Medium | High | Weekly sync with Mike T. |
| Agency pushback on new onboarding flow | Low | Medium | Pilot with TBWA first |

## Relationship Health
- Last check-in: 2026-04-08
- Sentiment: Positive. Excited about custom roles feature.
- Open issues: 2 P2 tickets in support queue (payment timing)

---

2. CSB — Customer Solution Build

A discrete solution built for a customer's specific need. BSA is STO. Uses ICE framework.

Template

# CSB: [Short Title]

**Parent CAP:** [Customer Name]
**BSA (STO):** [Name]
**Created:** [Date]
**Status:** [Planning | Active | Verify | Complete]

## Intent
<!-- What outcome are we trying to achieve? What does success look like
     for the customer? Be specific. -->

## Context
<!-- What do we know? What constraints exist? What's been tried before?
     Include customer history, technical constraints, timeline pressures,
     regulatory requirements. -->

## Evaluation
<!-- How do we measure success? What are the acceptance criteria?
     How will the customer confirm this is done? -->
- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3

## Solution Design
<!-- How are we solving this? What's the approach? -->

### Platform Components
<!-- Which existing Worksuite platform features does this leverage? -->
-

### Services Components
<!-- Does this require PayOps, CompOps, or Help Desk involvement? -->
-

### TSBs Required
| TSB | TSA (STO) | Scope | Status |
|-----|-----------|-------|--------|
|     |           |       |        |

## Timeline
| Milestone | Target Date | Status |
|-----------|-------------|--------|
|           |             |        |

## Customer Sign-off Criteria
<!-- What does the customer need to see/approve before we call this done? -->
-

Example: CSB for OMC Custom Role Permissions

# CSB: OMC Agency-Level Admin Permissions

**Parent CAP:** Omnicom Media Group
**BSA (STO):** Ryan Doyle
**Created:** 2026-03-28
**Status:** Active

## Intent
Give each OMC agency (BBDO, TBWA, DDB) their own admin users who can
manage contractors, approve payments, and view compliance status for
ONLY their agency. Right now, all admins see everything across all
agencies, which is a security and operational problem.

## Context
- OMC has 3 active agencies on Worksuite, expanding to 6 by Q3
- Current permissions model is tenant-wide (all or nothing)
- Sarah Chen flagged this as a blocker for the healthcare expansion
- Platform has basic role support but no agency-level scoping
- Similar request came from iMerit last quarter (different structure)

## Evaluation
- [ ] Agency admin at BBDO can only see BBDO contractors and payments
- [ ] Agency admin at TBWA cannot access BBDO data (verified by test)
- [ ] Existing global admin permissions unchanged
- [ ] OMC IT team validates SSO integration still works with new roles
- [ ] Lisa Park confirms the workflow in a live walkthrough

## Solution Design
Extend the existing role/permissions system with an "agency scope"
attribute. Each agency maps to a tenant partition. Admin roles get
scoped to one or more agencies.

### Platform Components
- Existing: Role management, user admin, tenant config
- New: Agency scope attribute on roles (TSB required)

### Services Components
- Help Desk: Update runbook for agency-scoped admin support tickets

### TSBs Required
| TSB | TSA (STO) | Scope | Status |
|-----|-----------|-------|--------|
| Agency-scoped role permissions | Adam R. | Backend role model + API | Active |
| Agency admin UI | Weston K. | Frontend permissions UI | Planning |

## Timeline
| Milestone | Target Date | Status |
|-----------|-------------|--------|
| Backend role model complete | 2026-04-15 | On track |
| Frontend UI complete | 2026-04-22 | Not started |
| OMC UAT | 2026-04-25 | Scheduled |
| Go-live | 2026-04-28 | — |

## Customer Sign-off Criteria
- Lisa Park completes walkthrough with test accounts for BBDO and TBWA
- Mike Torres confirms SSO still maps correctly to scoped roles
- Sarah Chen approves for production rollout

---

3. TSB — Technical Solution Build

A technical implementation that extends the Platform or Services. TSA is STO. 3-week max.

Template

# TSB: [Short Title]

**Parent:** [CSB or PSB name]
**TSA (STO):** [Name]
**Created:** [Date]
**Status:** [Planning | Active | Verify | Complete]
**Deadline:** [Date — max 3 weeks from start]

## Intent
<!-- What technical outcome are we building? -->

## Context
<!-- Technical constraints, existing architecture, dependencies,
     what's been tried, relevant code/modules affected. -->

## Evaluation
<!-- Technical acceptance criteria. How do we know this works? -->
- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3

## Technical Approach
<!-- High-level design. Architecture decisions. Trade-offs made. -->

## BC Breakdown
| # | BC Title | Days | Status | Ship Date |
|---|---------|------|--------|-----------|
| 1 |         |      |        |           |
| 2 |         |      |        |           |
| 3 |         |      |        |           |

## Dependencies
<!-- External dependencies, other TSBs, infrastructure needs. -->
-

## Risks / Unknowns
| Risk | Mitigation |
|------|------------|
|      |            |

## Definition of Done
<!-- When is this TSB complete? What's the bar? -->
-

Example: TSB for Agency-Scoped Role Permissions

# TSB: Agency-Scoped Role Permissions Backend

**Parent:** CSB — OMC Agency-Level Admin Permissions
**TSA (STO):** Adam Robak
**Created:** 2026-04-01
**Status:** Active
**Deadline:** 2026-04-18 (3 weeks)

## Intent
Add agency-level scoping to the role/permissions system so that admin
roles can be restricted to a specific agency partition within a tenant.

## Context
- Current role model: roles are tenant-wide, defined in `RoleDefinition`
  table with permission flags
- Tenant config already supports "groups" but they're cosmetic (display
  only), not permission boundaries
- Django middleware checks `request.tenant` but not sub-tenant scope
- iMerit asked for something similar but with project-level scoping;
  this implementation should be generic enough to support both
- Affected modules: `accounts`, `permissions`, `api_v2`, `admin`

## Evaluation
- [ ] New `scope` field on `RoleAssignment` model (nullable, backward-compatible)
- [ ] API endpoints filter results by user's role scope when present
- [ ] Existing unsecured roles continue to work (scope=null = full tenant)
- [ ] Admin API for assigning scoped roles
- [ ] Unit tests: 95%+ coverage on new permission checks
- [ ] Load test: no measurable latency increase on permission checks

## Technical Approach
Add optional `scope` FK on `RoleAssignment` pointing to a new
`OrgUnit` model. Middleware injects scope into request context.
ViewSet mixins filter querysets by scope. Backward-compatible:
null scope = tenant-wide (current behavior).

## BC Breakdown
| # | BC Title | Days | Status | Ship Date |
|---|---------|------|--------|-----------|
| 1 | OrgUnit model + migration + scope FK on RoleAssignment | 3 | Complete | 2026-04-04 |
| 2 | Middleware scope injection + ViewSet mixin filters | 3 | Active | 2026-04-09 |
| 3 | Admin API for scoped role assignment + unit tests | 2 | Planned | 2026-04-11 |
| 4 | Load testing + edge cases + documentation | 2 | Planned | 2026-04-15 |

## Dependencies
- Frontend TSB (Weston) depends on the Admin API from BC #3
- OMC tenant config needs OrgUnit entries created (BSA to coordinate)

## Risks / Unknowns
| Risk | Mitigation |
|------|------------|
| Permission check latency at scale | BC #4 includes load test; add caching if needed |
| Existing API consumers break | Null scope = full access; backward-compatible by design |

## Definition of Done
- All 4 BCs shipped
- API docs updated
- Weston can build frontend against the Admin API
- Ryan (BSA) confirms it meets CSB evaluation criteria

---

4. BC — Build Cycle

The atomic unit of work. 3-day max. Follows DPEV (Discuss, Plan, Execute, Verify). Ships every time.

Template

# BC: [Short Title]

**Parent TSB:** [TSB name]
**TSA:** [Name]
**Started:** [Date]
**Target Ship:** [Date — max 3 days from start]
**Status:** [Discuss | Plan | Execute | Verify | Shipped]

---

## Discuss
<!-- What are we building? Why? Who needs to be aligned? -->
- What:
- Why:
- Aligned with:

## Plan
<!-- Approach, scope boundary, acceptance criteria. -->
- Approach:
- Scope (IN):
- Scope (OUT):
- Acceptance criteria:
  - [ ]
  - [ ]
- Estimated hours:

## Execute
<!-- Implementation notes. Commits, PRs, blockers. -->
- Key commits/PRs:
- Blockers encountered:
- Decisions made during execution:

## Verify
<!-- Test results. Review. Ship confirmation. -->
- Tests passing:
- Reviewed by:
- Shipped: [Yes/No] [Date] [Environment]
- Notes:

Example: BC for OrgUnit Model + Migration

# BC: OrgUnit Model + Scope FK on RoleAssignment

**Parent TSB:** Agency-Scoped Role Permissions Backend
**TSA:** Adam Robak
**Started:** 2026-04-02
**Target Ship:** 2026-04-04
**Status:** Shipped

---

## Discuss
- What: New OrgUnit model and a scope FK on RoleAssignment
- Why: Foundation for agency-level permission scoping. Without this,
  roles can't be restricted to a subset of tenant data.
- Aligned with: Ryan (BSA), Weston (frontend TSA — needs to know
  the data shape)

## Plan
- Approach: New `OrgUnit` model in `accounts` app. Add nullable
  `scope` FK to `RoleAssignment`. Migration must be backward-compatible
  (null = tenant-wide). Seed script for OMC's 3 agencies.
- Scope (IN): Model, migration, basic admin registration, seed script
- Scope (OUT): API filtering, middleware, frontend
- Acceptance criteria:
  - [x] OrgUnit model with name, tenant FK, type enum
  - [x] RoleAssignment.scope FK (nullable)
  - [x] Migration runs cleanly on staging
  - [x] Seed script creates BBDO, TBWA, DDB org units for OMC tenant
- Estimated hours: 6

## Execute
- Key commits/PRs: PR #4821 — "Add OrgUnit model and scope FK"
- Blockers encountered: None
- Decisions made during execution: Made OrgUnit.type an enum
  (agency, project, division) to support iMerit's project-scoping
  use case later without another migration.

## Verify
- Tests passing: 14/14 new tests, full suite green
- Reviewed by: Chris K. (code review), staging migration verified
- Shipped: Yes, 2026-04-04, staging
- Notes: Production migration scheduled with next deploy window.
  No data changes for existing tenants (scope defaults to null).

---

5. PSB — Platform Solution Build

A platform-level investment initiated by TSAs when patterns emerge across multiple customers or TSBs. Can involve multiple TSAs collaborating.

Template

# PSB: [Short Title]

**Initiated by:** [TSA name]
**TSA Team:** [Names]
**Created:** [Date]
**Status:** [Proposed | Approved | Active | Complete]

## Pattern Observed
<!-- What triggered this? Which CSBs/TSBs showed the same need?
     This is the justification for platform investment. -->
- Signal 1:
- Signal 2:
- Signal 3:

## Intent
<!-- What platform capability are we adding? -->

## Context
<!-- Current platform state. What exists? What's missing?
     Technical constraints. Scale considerations. -->

## Evaluation
<!-- How do we know the platform extension is successful? -->
- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3

## Scope
<!-- Which modules or services are affected? -->
- Modules:
- Services:
- APIs:
- Cross-cutting concerns:

## TSB Breakdown
| TSB | TSA (STO) | Scope | Status |
|-----|-----------|-------|--------|
|     |           |       |        |

## TSA Assignments
| TSA | Responsibility | Availability |
|-----|---------------|-------------|
|     |               |             |

## Cross-Cutting Concerns
<!-- Security, performance, backward compatibility, data migration. -->
-

## Definition of Done
<!-- When is this PSB complete? What's the bar for "platform-ready"? -->
-

Example: PSB for Generic Sub-Tenant Scoping

# PSB: Generic Sub-Tenant Scoping Engine

**Initiated by:** Adam Robak
**TSA Team:** Adam Robak, Chris Koens
**Created:** 2026-04-14
**Status:** Proposed

## Pattern Observed
- Signal 1: OMC needs agency-level admin scoping (CSB active, TSB in progress)
- Signal 2: iMerit requested project-level data partitioning last quarter
  (handled as custom work, should have been platform)
- Signal 3: GoodRx onboarding will need department-level scoping
  (Ryan flagged in CAP review)

Three customers, three flavors of the same need: restrict visibility
and permissions to a subset of tenant data. Building this custom each
time is unsustainable.

## Intent
Build a generic, configurable sub-tenant scoping engine that supports
agency, project, department, or any other partition type. Once in
platform, BSAs can configure scoping for new customers without
needing a TSB.

## Context
- Adam's current OMC TSB is building the OrgUnit model as foundation
- Middleware scope injection pattern works but is OMC-specific
- Need to generalize: configurable scope types, UI for scope admin,
  self-service for BSAs
- Django multi-tenancy layer already handles tenant isolation;
  sub-tenant is a new concept
- Performance: permission checks run on every API call; caching is
  required at scale

## Evaluation
- [ ] BSA can configure a new scope type via admin UI (no code change)
- [ ] Scoping works across all major modules (accounts, payments,
      compliance, onboarding)
- [ ] Existing tenants unaffected (null scope = full access)
- [ ] Performance: <5ms added latency on permission checks at P99
- [ ] Documentation: BSA-facing guide for configuring scopes
- [ ] Tested with OMC (agency), iMerit (project), and a synthetic
      department-scoped tenant

## Scope
- Modules: accounts, permissions, payments, compliance, onboarding, admin
- Services: API v2 (all scoped endpoints), Admin UI
- APIs: New scope management endpoints, updated permission check middleware
- Cross-cutting: Caching layer, migration tooling, tenant config schema

## TSB Breakdown
| TSB | TSA (STO) | Scope | Status |
|-----|-----------|-------|--------|
| Generic OrgUnit + scope engine | Adam R. | Core model, middleware, caching | Active (evolved from OMC TSB) |
| Scope admin UI + BSA config | Chris K. | Admin interface, self-service config | Planning |
| Module-by-module scope integration | Adam R. + Chris K. | payments, compliance, onboarding | Planning |

## TSA Assignments
| TSA | Responsibility | Availability |
|-----|---------------|-------------|
| Adam Robak | Core engine, middleware, payments integration | Full-time through April |
| Chris Koens | Admin UI, compliance + onboarding integration | Starting April 21 |

## Cross-Cutting Concerns
- Backward compatibility: null scope must always mean full tenant access
- Performance: Redis caching for scope lookups; benchmark before/after
- Data migration: existing OMC OrgUnits migrate into generic engine
- Security: scope boundary must be enforced at DB query level, not just API

## Definition of Done
- All 3 TSBs shipped
- BSA can configure agency/project/department scoping without engineering
- OMC, iMerit test tenants validated
- Performance benchmarks pass
- BSA-facing documentation published

---

Quick Reference: When to Use What

I need to...	Use this
Plan a customer relationship	CAP
Solve a specific customer problem	CSB (with ICE)
Build something technical	TSB (3-week cap)
Do a focused chunk of work	BC (3-day cap, DPEV)
Invest in the platform itself	PSB (TSA-initiated)

Rules

1. Every BC ships. If it didn't ship, it wasn't a BC.
2. 3-day BC cap is non-negotiable. If it won't fit, break it smaller.
3. 3-week TSB cap is non-negotiable. If it won't fit, break into multiple TSBs.
4. ICE on every CSB. No solution design without Intent, Context, Evaluation.
5. DPEV on every BC. Skip a phase, ship a bug.
6. PSBs need pattern evidence. One customer asking isn't a platform investment. Three is.

---

Document maintained by Red. Work product templates for the AWE organizational model.