skills/build-business-case/references/workflow.md

# Build Business Case Workflow

## Standard workflow the skill should follow
Run these steps in order. Do not skip ahead.

### Step 1: Understand the customer context

First determine:

- who the customer is
- what industry they are in
- what their strategic priorities are
- what pressures they are facing
- what type of transformation they care about
- what constraints may matter

Pressure examples:

- efficiency pressure
- growth pressure
- cost pressure
- modernization
- software productivity
- customer experience
- workflow automation
- risk or compliance
- time to market

Key question:

`What is this customer trying to achieve, and what is getting in the way?`

Operating rules:

- Do anchor the narrative in the customer objective and business pressure.
- Do identify the pressure that makes the workflow important now.
- Do not jump to product recommendations before this step is complete.

### Step 2: Find the account-native business-case anchor

Before broad research, look for the strongest account-native artifact:

- user-provided metrics, notes, links, or exports;
- exact-match ~~Knowledge & Files queries such as `[customer] business case`, `value case`, `ROI`, `pilot target`, or `expansion path`;
- the matching ~~CRM opportunity;
- relevant ~~Meeting Transcripts.

Fetch the strongest anchor first. High-signal anchors contain the named customer, workflow, decision audience, commercial stakes, metrics, urgency, or caveats. Preserve commercial facts such as pilot amount, expansion path, target value, budget range, close timing, and paid-pilot terms; if ~~CRM is thin, keep the sourced fact and separately name the CRM gap.

Use adjacent sources only to validate material gaps such as workflow pain, approval path, budget ownership, timing, risks, or customer-facing follow-up. Stop the first pass once the core case is supported.

### Step 3: Run the public research pass

If a named public company is present and public research is not explicitly disabled, run a focused public research pass unless the account-native anchor already answers the material why-now question. Do not let this delay the first useful case.

Gather and synthesize, when available:

- investor relations materials
- 10-K, annual report, or quarterly filings
- earnings call commentary
- shareholder letters or quarterly results decks
- company website, product pages, and corporate pages
- recent material news that changes priorities or urgency

This step must answer:

- what the company says its priorities are
- what pressures are visible publicly
- what recent developments make the case more urgent now
- what business outcomes are visible in public company language

Operating rules:

- Do use company-controlled materials first, then recent material news.
- Do use public research to sharpen customer context, strategic initiatives, key challenges, and business-outcome translation.
- Do use concrete dates for recent developments when they materially affect urgency.
- Do not let public evidence override stronger customer, system, or conversation evidence.
- Do not use earnings rhetoric as proof of company-specific impact.
- Do not bloat the output with generic company background.

### Step 4: Understand the customer workflow

Before identifying use cases, understand the actual workflow, business process, or functional motion the customer is trying to improve.

Workflow examples:

- customer support
- claims processing
- underwriting
- billing operations
- document authoring
- software development
- internal research
- sales support
- onboarding
- knowledge management
- contact center operations

For each workflow, inspect:

- who is involved
- what the major steps are
- where bottlenecks exist
- what is manual today
- where delays occur
- where quality breaks down
- where handoffs happen
- what tools or systems are involved
- what KPIs matter
- what "good" looks like in that workflow

Key question:

`Which workflow or business process are we trying to improve, and where in that workflow does value exist?`

Operating rules:

- Do identify the specific workflow where value can actually be unlocked.
- Do use both internal evidence and public context where appropriate, while keeping internal evidence primary.
- Do describe the workflow in business language, not product language.
- Do not stay at the level of broad corporate transformation themes.

### Step 5: Identify the highest-priority use cases

Do not list every possible use case.

Prioritize the use cases most tied to the customer's actual goals and the workflows most in need of improvement.

Use-case examples:

- enterprise productivity platform for knowledge worker productivity
- developer productivity tooling for software development acceleration
- platform APIs for workflow automation
- support workflow optimization
- billing, claims, underwriting, authoring, or document review workflows
- internal research and knowledge workflows

Key question:

`Which use cases are most likely to matter to this customer right now, given their priorities and workflow constraints?`

Operating rules:

- Do prioritize one to three use cases.
- Do tie each use case to a specific workflow problem.
- Do not include attractive but weakly supported use cases.

### Step 6: Define the value drivers

For each prioritized use case, define what kind of business value it creates.

Use the standard value buckets:

- Enhanced Productivity
- Cost Reduction
- Risk Reduction
- Revenue Acceleration
- Time to Market

Key question:

`How exactly does this use case create business value?`

Operating rules:

- Do make the causal chain explicit.
- Do map each use case to the fewest value buckets needed to explain the business case clearly.
- Do not treat "value" as a vague synonym for "better."

### Step 7: Identify the metrics required

For each use case, identify what must be measured.

Common metrics:

- number of users
- number of workflows
- task volume
- time per task
- time saved per task
- frequency of task
- hourly labor cost
- adoption rate
- completion rate
- cycle time
- defect rate
- error rate
- cost per incident
- conversion rate
- revenue influenced
- launch speed
- external tool spend
- contractor spend
- output volume

Key question:

`What would we need to know to quantify this credibly?`

Operating rules:

- Do identify the minimum dataset needed for credible quantification.
- Do separate known metrics from missing metrics.
- Do not imply quantifiability when the required inputs are missing.

### Step 8: Quantify the value

Build directional or quantified value hypotheses.

When possible, show:

- low case
- base case
- high case

Use clear logic and separate:

- hard data
- customer-provided inputs
- assumptions
- external benchmarks

Key question:

`What measurable impact could this use case create?`

Operating rules:

- Do show formula logic when quantification is credible.
- Do use scenario ranges when uncertainty is meaningful.
- Do keep the case structural if customer data is weak.
- Do not fake precision.

### Step 9: Translate the impact into business outcomes

Operational improvements should be translated into business value.

Examples:

- time saved -> productivity gain or capacity unlocked
- fewer manual steps -> lower cost to serve
- faster coding -> faster release cycles
- better support workflows -> improved response times or lower support cost
- fewer errors -> reduced risk or reduced remediation cost
- faster launches -> earlier business impact

Key question:

`How does operational improvement become financial or strategic value?`

Operating rules:

- Do connect operational change to business effect.
- Do use public-company language and current public priorities when available to make the business outcome framing more executive-relevant.
- Do explain why the KPI matters economically.
- Do not leave the case stuck at the level of workflow efficiency.

### Step 10: Draft the business narrative

After the analysis, write the narrative in a way that an executive can understand.

The narrative must connect:

- customer priority
- customer challenge
- relevant workflow
- relevant use case
- expected business impact
- why the seller solution
- what assumptions matter
- what still needs validation

The narrative should sound:

- consultative
- outcome-oriented
- grounded
- tailored

The narrative should not sound like a product datasheet.

Operating rules:

- Do keep the story customer-led.
- Do make the decision usefulness visible.
- Do keep caveats and missing validation explicit.
- Do not turn the output into a feature list.