A3

A discovery session across federal, public sector, and enterprise account teams produced a use-case inventory substantially larger than I could build in the summer. The obvious response was to rank the inventory and build down the list. The inventory itself showed why that fails: use cases overlapped, recurred across segments, and each sat at a specific point in a sequence nobody had visualized. Building them individually would have produced a drawer of one-off solutions, each owned by whoever requested it and all orphaned the moment their requester changed roles.

Account-based experience spans segment activation and field teams, each owner already an expert in their own stage. What none of them had was a working sense of where AI could sit in it. Requests arrived naming a tool rather than a task because the vocabulary for describing an automatable step did not exist yet in the organization. The handoffs between stages were the second, larger gap. Every owner could describe their own process end to end yet nobody could describe what arrived from the stage before or what they passed to the stage after. Effort and ambiguity both concentrate in those handoffs, and the handoffs belonged to nobody in particular, which meant no cross-functional solution had an owner who could authorize it.

Discovery

Use cases overlapped across segments and each one sat at a specific point in a sequence, so ranking them and building down the list would have solved the same problem three times over. I took the position further and argued for mapping the whole system first, then placing each use case where it actually lived in the larger playbook.

Framing

Every request arriving at the team named a tool before it named a step, and there was no way to weigh one against another without knowing where in the sequence each would land. Mapping the loop first made the requests comparable, which is what turned an inventory into a ranked set of decisions.

Tradeoffs

• A measurable pilot over an ambitious one: prove the loop on one workflow that can be counted
• Human signal validation over automatic action: a wrong targeting decision is paid for in a conversation the system never observes
• Appetite over size when picking the first target

Stop describing the workflow and start measuring it.

I drafted a ten-step metrics request asking each owner for hours, people, and rounds of review per step, secured approval before sending it, and issued it to the field group. The returned estimates converted an argument about efficiency into a defensible range, and they came from the accountable manager rather than from an analyst’s inference.

The measured baseline and the modeled future state are labelled apart.

Current-state effort runs 12.1 to 18.5 hours per cycle, reported step by step by the people who perform the work. The modeled future state runs 7.8 to 11.0 hours, a directional reduction of 35 to 41 percent. One describes what the organization does. The other describes what it could plausibly do, and it carries the word directional everywhere it appears.

The concept, a use-case inventory ranked across three horizons and split by build path against enablement path, owner-facing capture templates, current and future state maps, and a KPI architecture. Tested on the Mid Market Engager Program, it became the model applied to other high-impact workflows.

Core loop

Research → Strategy → Content → Distribution → Intelligence → back to Research.

Reframes are rejected differently than builds

The playbook’s value was in converting a backlog of one-off automations into a five-stage operating loop, which is an argument rather than an artifact. A build fails on acceptance criteria and tells you why. An argument fails by being received politely and then not used which returns no signal at the point of failure. I would now attach a usage commitment to a reframe at the moment it is accepted so that non-adoption surfaces as a missed step rather than as silence.