BSA Handbook¶
Business Solution Architect Reference Guide Worksuite AWE (Agentic Workforce Era) | April 2026 | Internal
Unfamiliar term? See the AWE Glossary.
1. What Is a BSA?¶
A Business Solution Architect is an individual contributor who owns the customer relationship end-to-end. You are not an account manager with a new title. You are not a relay between customers and engineers. You understand the customer's business, design solutions using the ICE framework, coordinate technical delivery with TSAs, and measure outcomes.
In the old model, an account manager took notes on a call, emailed a product manager, who wrote a PRD, which went into a backlog, which got groomed into a sprint, which an engineer eventually picked up. The customer waited 6-12 weeks and the solution often missed the mark because the original context degraded at every handoff.
That's dead. In AWE, you hear the customer's problem, you design the solution, you engage a TSA directly, and you deliver. Two people. One handoff. No intermediaries.
What you own: - The full customer relationship and journey - Customer Account Plans (CAPs) as the strategic relationship document - Customer Solution Builds (CSBs) as Single Threaded Owner - Solution design using the ICE framework - Engaging TSAs and coordinating TSBs within your CSBs - Customer sign-off and outcome measurement
What you don't own: - Technical implementation (that's the TSA) - Platform investment decisions (TSAs initiate PSBs) - Operational service delivery (that's Worksuite Services under the Head of Services and PayOps) - Employee tooling and access (that's People Experience under the COO)
2. The Customer Journey¶
You own it. All of it. There is no "implementation team" to hand off to. No "customer success" function that takes over after go-live. The BSA who sells the vision is the BSA who delivers it and the BSA who maintains the relationship.
The Journey¶
Discovery ──► Solution Design ──► Delivery ──► Ongoing
│ │ │ │
│ ICE Spec (CSB) TSA builds CAP updates
│ │ TSBs/BCs New CSBs
│ │ │ │
You You You + TSA You
What this means in practice¶
| Phase | What you do | Old model equivalent |
|---|---|---|
| Discovery | Meet customer, understand their business, identify problems | Account manager took notes, forwarded to product |
| Solution Design | Write ICE Spec, create CSB, identify platform/services/TSB needs | Product manager wrote PRD after 3 meetings |
| Delivery | Engage TSA(s), track TSBs, keep customer informed, do UAT | PM + project manager + engineering lead |
| Ongoing | Update CAP, spot new opportunities, maintain relationship | Customer success manager (different person) |
You are one person doing what used to require four. The difference: agentic tooling handles the information processing, and the ICE Spec replaces the document overhead.
3. Work Products You Own¶
3.1 CAP (Customer Account Plan)¶
Your strategic document for each customer relationship. Living, updated continuously. Not a deck you make once a quarter.
A good CAP is a snapshot of everything you know about a customer: who they are, what they need, what we're building for them, and what's coming next. Anyone on the team should be able to read your CAP and understand the customer in 10 minutes.
When to update: After every meaningful customer interaction. After every CSB ships. When risks change. When stakeholders change. When you spot a new opportunity.
See work/work-product-templates.md for the full CAP template and example.
3.2 CSB (Customer Solution Build)¶
A discrete solution for a specific customer need. You're the STO.
Every CSB starts with an ICE Spec. Not a PRD. Not a requirements document. An ICE Spec captures Intent (what outcome?), Context (what do we know?), and Evaluation (how do we measure success?). The CSB is the solution deliverable; the ICE Spec is the design document inside it.
A CSB might be simple (configure an existing feature) or complex (requires multiple TSBs to extend the platform). Either way, you own it.
When to create a CSB: - Customer has a specific problem that needs a specific solution - The work is bounded (not "make them happier" but "give agency admins scoped permissions") - You can define evaluation criteria that the customer will agree to
CSB lifecycle:
See work/work-product-templates.md for the full CSB template and example.
3.3 How You Engage TSAs¶
This is the core operating relationship in AWE. Getting this right is the difference between shipping in days and shipping in months.
What you owe the TSA: - Clear Intent (what outcome does the customer need?) - Rich Context (customer history, constraints, timeline, what's been tried) - Specific Evaluation criteria (how do we know it works?) - Customer access when the TSA needs it - Fast answers when the TSA has questions
What the TSA owes you: - Technical approach (how they'll build it) - BC breakdown with timeline - Honest assessment of risks and unknowns - Shipping at the end of every BC - A heads-up when something is off track
When to engage a TSA: - Your CSB requires platform changes or new features - You need technical assessment of feasibility - The customer's problem can't be solved with existing configuration
When NOT to engage a TSA: - You can solve it with existing platform configuration - It's an operational issue (route to Worksuite Services) - You need research or competitive intel (use your agents)
4. ICE Framework in Practice¶
ICE (Intent, Context, Evaluation) is the framework for how you design solutions. The ICE Spec is the document you produce using that framework. It replaces PRDs, requirements documents, and the "let me capture your requirements and translate them for engineering" dance.
The Three Components¶
Intent: What are we trying to achieve? Not "build feature X" but "enable agency admins to manage their own contractors without seeing other agencies' data." Intent is about outcomes, not outputs.
Context: What do we know? This is where your customer knowledge matters. History, constraints, politics, technical landscape, timeline pressures, regulatory requirements, what's been tried before and why it didn't work. The richer your context, the better the TSA can design.
Evaluation: How do we measure success? Specific, testable criteria that you and the customer agree on. Not "it should work well" but "Lisa Park at BBDO can log in, see only BBDO contractors, and cannot access TBWA data."
Anchoring Intent to the Big 3 and FY26 Objectives¶
Every CSB ties back to Worksuite's Big 3 Metrics (ARR, eNPS, Operating Cash Burn) and at least one FY26 Annual Objective. Your Intent section names the anchor explicitly.
The Big 3 (current): - ARR — Does this solution grow, retain, or unlock customer ARR? - eNPS — Does this solution reduce employee friction or improve how teams execute? - Operating Cash Burn — Does this solution improve efficiency or reduce cost?
FY26 Objectives: 1. Grow OMC/IPG by $1.0M ARR 2. Grow non-OMC AOR to $0.5M ARR 3. Release 10 EASI product releases 4. Launch rebrand + close 20 new customers 5. Improve Gross Dollar Retention to 90%
If your CSB doesn't clearly advance one of these, pause and ask why you're building it. Urgency is not the same as priority. The Prioritization Operating Principle — "focus on what matters most; say no to the rest" — applies to BSAs first.
How to state the anchor in your ICE Spec:
"This CSB advances Objective 1 (OMC/IPG ARR growth) by unblocking the agency-level admin work that OMC has gated on. Direct Big 3 impact: $240K incremental ARR contingent on delivery within Q2."
Every Intent should close with a sentence like this. If you can't write it, you don't have an Intent — you have a request.
Good vs Bad ICE Specs¶
Bad Intent: "We need custom roles for OMC." Good Intent: "Give each OMC agency their own admin users who can manage contractors, approve payments, and view compliance status for ONLY their agency, so we can scale from 3 to 6 agencies without security risk."
Bad Context: "OMC wants permissions." Good Context: "OMC has 3 active agencies on Worksuite, expanding to 6 by Q3. Current permissions are tenant-wide. Sarah Chen flagged this as a blocker for the healthcare expansion. Similar request came from iMerit last quarter with project-level scoping. Platform has basic role support but no sub-tenant scoping."
Bad Evaluation: "Permissions work correctly." Good 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 - Lisa Park confirms the workflow in a live walkthrough
The ICE Spec Replaces PRDs¶
| Old PRD section | ICE equivalent |
|---|---|
| Problem statement | Intent |
| Background / research | Context |
| Requirements | Evaluation criteria |
| User stories | Included in Intent (outcome-focused) |
| Acceptance criteria | Evaluation |
| Technical specs | TSA writes this (not the BSA) |
| Prioritization | ICE itself is the prioritization tool |
The TSA handles the technical design. You don't write "the system shall" specifications. You write what the customer needs and how you'll know it's done. The TSA figures out how to build it.
5. The BSA-TSA Loop¶
This is the engine of AWE. Two people, working directly, no intermediaries.
How It Works¶
BSA TSA
│ │
│ 1. ICE Spec (CSB) │
├───────────────────────────────►│
│ │
│ 2. Technical approach + BCs │
│◄───────────────────────────────┤
│ │
│ 3. Questions / context │
│◄──────────────────────────────►│
│ │
│ 4. BC ships │
│◄───────────────────────────────┤
│ │
│ 5. Customer feedback │
├───────────────────────────────►│
│ │
│ 6. Next BC / complete │
│◄───────────────────────────────┤
Rules of Engagement¶
- The BSA starts every engagement with an ICE Spec. Don't walk up to a TSA and say "the customer needs a thing." Write the ICE Spec first.
- The TSA responds with a technical approach and BC breakdown. If the TSA says "I need more context," that's on you to provide.
- Stay available during BCs. The TSA will have questions. A 2-hour answer delay on a 3-day BC is a big deal.
- Review at the end of every BC. The TSA ships, you verify against evaluation criteria, you loop in the customer if needed.
- Don't design the technical solution. You own the "what" and "why." The TSA owns the "how."
When Multiple BSAs Need the Same TSA¶
This happens. Use D3 (Discuss, Debate, Decide):
- Discuss: Surface the conflict. Both BSAs explain their customer need and urgency.
- Debate: Challenge assumptions. Is one truly more urgent? Can one wait 3 days? Can a different TSA take one?
- Decide: Reach consensus. If you can't, escalate to the CSA (SA Group Leader) who makes the call.
The CSA is not a manager making priority decisions for you. The CSA is a tiebreaker when peers can't reach consensus.
6. A Typical Day¶
During an Active CSB¶
| Time | Activity |
|---|---|
| Morning | Check agent briefing (customer updates, Slack threads, emails overnight). Review active TSB status. |
| Mid-morning | Customer call or internal sync. Update ICE Specs with new context. |
| Midday | TSA check-in on active BCs. Unblock questions. Review shipped work. |
| Afternoon | CSB coordination: write new ICE Specs, update CAPs, prep for upcoming customer meetings. |
| End of day | Agent generates daily summary of customer activity. Flag anything that needs attention tomorrow. |
Between CSBs¶
| Time | Activity |
|---|---|
| Morning | Review CAPs. Agent surfaces opportunities, risks, upcoming renewals. |
| Mid-morning | Customer relationship building. Check-ins, forward useful intel. |
| Midday | Pipeline review. Which customers have emerging needs? |
| Afternoon | Proactive solution design. Write ICE Specs for opportunities before the customer asks. |
Weekly Rhythm¶
| Day | Focus |
|---|---|
| Monday | CAP reviews, week planning, TSA alignment on active CSBs |
| Tue-Thu | Execution: customer calls, ICE Specs, TSA coordination, delivery |
| Friday | Reflection: what shipped, what's stuck, CAP updates, next week prep |
7. Agentic Tooling¶
You are expected to use AI agents. They handle information processing so you can focus on relationships and judgment.
What Agents Handle¶
| Task | How agents help |
|---|---|
| Meeting prep | Agent pulls customer context from CAP, recent Slack threads, Jira issues, Sentry errors, and generates a 1-page briefing before every call |
| Customer intel | Agent monitors news, competitive moves, industry trends relevant to your customers |
| ICE Spec drafting | Agent drafts ICE Specs from meeting transcripts and notes. You refine and finalize. |
| Data analysis | Agent queries usage data, payment volumes, compliance metrics for customer reviews |
| Competitive research | Agent tracks competitor pricing, features, and positioning |
| Document generation | Agent produces branded reports, presentations, and deliverables |
| Follow-up tracking | Agent tracks action items from customer calls and nudges you when things are overdue |
What Requires Human Judgment¶
| Task | Why it's you |
|---|---|
| Relationship building | Trust, empathy, reading the room. Agents can't do this. |
| Negotiation | Commercial decisions, trade-offs, creative deal structuring |
| Solution design | Understanding the customer's real problem (not just what they asked for) |
| Prioritization | Deciding what matters most for this customer right now |
| Escalation judgment | Knowing when something is about to go wrong before it does |
| Cultural context | Understanding organizational politics, personal dynamics, unspoken concerns |
The Multiplier Effect¶
A BSA without agents can manage 3-5 active customer relationships well. A BSA with agents can manage 8-12 because the information processing, prep work, and documentation are handled.
The goal is not to do more with less effort. The goal is to go deeper with each customer because you're not drowning in admin.
8. Working with Worksuite Services¶
Worksuite Services (owned by Head of Services and PayOps (Cristin)) handles Payment Operations, Compliance Operations, and Help Desk. These are operational functions, not project delivery.
When Your CSB Involves Services¶
Many customer solutions leverage operational services. Example: a CSB for OMC's Canada expansion requires PayOps to set up Canadian payroll processing.
Your role: Identify the services dependency in your CSB. Coordinate timing with the Services team. Ensure the customer experience is seamless.
Services' role: Execute operational setup, ongoing operational support. Services ICs may also contribute to BCs and PSBs when their domain expertise is needed.
What Services Is NOT¶
- Not professional services (you own implementation)
- Not a delivery team you hand off to
- Not responsible for customer communication (that's you)
The Handoff¶
There is no handoff. You stay the customer's point of contact. Services operates behind the scenes. If the customer has an operational issue (payment didn't process, compliance flag), Help Desk handles it. If the customer has a solution issue (feature doesn't work as designed), that's your CSB.
9. Working with People Experience¶
People Experience (owned by COO) ensures you have the right tools, access, AI agents, processes, and communication methods. In the old model, your manager handled this. In AWE, People Experience fills that gap at the organizational level.
When to engage People Experience: - You need access to a new tool or data source - Your AI agents need new capabilities or permissions - A process is broken or missing - You need training on a new platform feature
10. STO on CSBs¶
When you're the STO (Single Threaded Owner) on a CSB, you have decision authority and accountability for that specific solution. You are not a manager. You are an IC who owns the outcome.
What STO Means¶
- You decide what's in scope and what's not
- You decide when to engage a TSA and which one
- You decide when the customer is ready for UAT
- You decide when the CSB is complete
- You are accountable if it ships late, ships wrong, or doesn't ship
What STO Does NOT Mean¶
- You don't tell TSAs how to build things technically
- You don't manage anyone's time or workload
- You don't approve anyone's PTO or do performance reviews
- You don't have authority beyond your specific CSB
If you're STO on a CSB and the TSA disagrees with your technical approach, the TSA wins on technical decisions. You own the "what" and "when." They own the "how."
11. What You Don't Do Anymore¶
| Old Activity | What Replaced It |
|---|---|
| Write PRDs | ICE Specs (you write Intent, Context, Evaluation; the TSA handles technical design) |
| Attend backlog grooming | Eliminated. There is no backlog. |
| Sit in sprint planning | Eliminated. TSAs start BCs when CSBs need them. |
| Send status update emails | Agents generate status from live data. Anyone can check. |
| Report up the chain | There is no chain. WLT sees outcomes, not status reports. |
| Hand off to implementation | You are the implementation coordinator. No handoff. |
| Hand off to customer success | You are customer success. No handoff. |
| Wait for product to prioritize | You prioritize using ICE. There is no product team. |
| Translate between customer and engineering | You and the TSA talk directly. No translation layer. |
12. Quick Reference¶
Frameworks You Use Daily¶
| Framework | When |
|---|---|
| ICE | Every solution design. Every CSB starts with an ICE Spec. |
| D3 | Resource disputes with other BSAs. Peer decisions. |
| DPEV | Understanding what your TSA is doing (so you can stay aligned). |
Work Products You Own¶
| Work Product | Your Role |
|---|---|
| CAP | Owner. Living strategic document per customer. |
| CSB | STO. Discrete solution containing the ICE Spec, coordinates TSBs. |
Work Products You Interact With¶
| Work Product | Your Role |
|---|---|
| TSB | Consumer. You provide the CSB; TSA provides the TSB. |
| BC | Reviewer. Check shipped BCs against your evaluation criteria. |
| PSB | Beneficiary. TSAs extend the platform; you get better tools. |
Key Relationships¶
| Person | Relationship |
|---|---|
| TSA | Your direct partner for technical delivery |
| CSA | Tiebreaker when D3 doesn't reach consensus |
| Head of Services and PayOps (Cristin) | Worksuite Services for operational dependencies |
| VP of People Success (Diana) | People Success if you need support |
| COO | People Experience for tools, access, AI |
Document maintained by Red. BSA reference guide for the AWE organizational model.