> ## Documentation Index
> Fetch the complete documentation index at: https://docs.minoa.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Use Cases

> Build your library of value-based calculations that turn product features into quantified business outcomes

Buyers don't purchase products—they buy solutions to problems. More precisely, they invest to reduce costs, increase revenue, or mitigate risk. Use cases are how you translate your product catalog into this value-based language.

Your Value Framework's use case library is the foundation of every business case your team creates. Each use case combines quantitative calculations with compelling qualitative content, making it easy for sellers to build credible, buyer-specific business cases without being finance experts.

<Tip>
  Think of use cases as reusable value stories. Build them once in your Value Framework, then every seller can apply
  them across dozens of deals with buyer-specific inputs.
</Tip>

## What Makes Up a Use Case

Every use case in your Value Framework includes both numbers and narrative. This combination makes your value quantification credible, compelling, and defensible.

### Name and Description

The name and description form your value narrative. Instead of "Feature X" or "Product Y," use cases speak in outcomes language:

* "Reduce Manual Data Entry Time"
* "Accelerate Deal Cycles"
* "Minimize Compliance Risk"

Your use case name appears throughout business cases, so make it buyer-friendly. The description expands on the value story, explaining how your solution drives this outcome.

<Info>
  Write names and descriptions in value-based language. Ask yourself: "What business outcome does this deliver?" not
  "What does our product do?"
</Info>

### Calculations

The calculation engine is where value gets quantified. Each use case includes:

* **Inputs** – Variables like employee count, hourly pay, time spent on tasks
* **Formulas** – Logic that combines inputs into calculated benefits
* **Time-based modeling** – How value materializes over months, quarters, or years

When sellers create business cases, they customize the inputs for their specific buyer. The formulas remain consistent, ensuring your ROI methodology stays standardized across all deals.

### Supporting Content

Numbers tell part of the story. Supporting content makes it believable:

* **Case studies** – Real customer examples demonstrating the value
* **Research and statistics** – Industry benchmarks and third-party validation
* **Resources** – Links to whitepapers, guides, or tools that address objections
* **Implementation notes** – Context about how customers realize this value

This qualitative content appears alongside the calculations in business cases, giving buyers the full picture.

<Tip>
  Strong supporting content turns skeptical buyers into believers. Include at least one customer example or industry
  stat for every use case.
</Tip>

## Use Case Variants (Optional)

Some use cases apply differently depending on the buyer's situation. Variants let you create multiple versions of the same core use case, each tailored to specific scenarios.

### When to Use Variants

Create variants when:

* **Different industries** realize value differently (healthcare vs. financial services)
* **Company sizes** have different cost structures (SMB vs. Enterprise)
* **Deployment models** change the value equation (cloud vs. on-premise)
* **User personas** care about different aspects of the same outcome

### How Variants Work

Each variant shares the same use case name but includes:

* Adjusted formulas or input defaults
* Persona-specific descriptions
* Industry-relevant case studies
* Customized supporting content

When sellers build business cases, AI can suggest the right variant based on deal context. This ensures every buyer sees value quantified in a way that resonates with their specific situation.

<Info>
  Variants are optional. Many use cases work universally across all buyers. Add variants only when customization
  genuinely improves relevance and credibility.
</Info>

## Building Your Use Case Library

### Start with Your Core Value Drivers

Identify the 5-10 most common ways your solution delivers value. These become your foundational use cases. Common patterns:

* **Efficiency gains** – Time saved on manual tasks
* **Cost reductions** – Headcount avoided, software consolidated
* **Revenue acceleration** – Faster sales cycles, improved close rates
* **Risk mitigation** – Compliance costs avoided, security improvements
* **Quality improvements** – Error reduction, customer satisfaction gains

<Tip>
  Review won deals to identify patterns. What value did buyers care most about? Those are your priority use cases.
</Tip>

### Involve Your Experts

Building strong use cases requires collaboration:

* **Product experts** – Ensure calculations reflect actual capabilities
* **Customer success** – Validate assumptions with real customer data
* **Finance or value engineering** – Review formulas for accuracy
* **Sales** – Confirm language resonates with buyers

The best use case libraries blend product knowledge, customer proof points, and finance rigor.

### Maintain and Evolve

Your use case library should grow with your business:

* Add new use cases when you launch products or enter new markets
* Refine calculations as you gather more customer data
* Update supporting content with fresh case studies
* Retire use cases that no longer apply

<Info>
  We recommend reviewing your use case library quarterly. Add new customer examples, update outdated stats, and refine
  based on seller feedback.
</Info>

## How Sellers Use Your Use Cases

Once you've built use cases in your Value Framework, sellers can apply them to any deal:

1. **AI suggests relevant use cases** based on deal context (industry, buyer role, discovery notes)
2. **Sellers select the use cases** that best match this buyer's priorities
3. **Sellers customize inputs** with buyer-specific numbers (their team size, current costs, etc.)
4. **Calculations auto-update** to show quantified value for this specific buyer
5. **Supporting content appears** alongside calculations in the business case

This flow means sellers spend time understanding buyers, not building spreadsheets. Learn more about [how sellers choose use cases](/pages/getting-started/choosing-use-cases) when creating business cases.

## Organizing Use Cases with Properties

As your library grows, properties become essential for helping sellers find the right use cases quickly. Properties let you categorize use cases by:

* Industry (Healthcare, Financial Services, Manufacturing)
* Buyer persona (CFO, CTO, VP Operations)
* Product line or solution area
* Value category (Cost Reduction, Revenue Growth, Risk Mitigation)

Learn more about [using properties to organize your Value Framework](/pages/value-framework/properties).

## Best Practices

<AccordionGroup>
  <Accordion title="Use outcome language, not feature language">
    "Reduce Time Spent on Manual Reporting" beats "Automated Reporting Feature." Speak to the outcome buyers care
    about.
  </Accordion>

  <Accordion title="Validate formulas with real customer data">
    Don't guess at ROI. Use actual customer results to build credible calculations that stand up to buyer scrutiny.
  </Accordion>

  <Accordion title="Include compelling proof points">
    Every use case needs at least one customer example or industry benchmark. Numbers without proof feel like
    guesswork.
  </Accordion>

  <Accordion title="Make inputs buyer-friendly">
    Use language buyers understand. "Monthly Transaction Volume" is clearer than "MTX\_VOL." Avoid internal jargon.
  </Accordion>

  <Accordion title="Start focused, expand gradually">
    Begin with 5-10 core use cases that cover your most common value drivers. Add more as patterns emerge, not
    preemptively.
  </Accordion>

  <Accordion title="Test with your sales team">
    Have sellers use your use cases on real deals. Their feedback reveals what's working and what needs refinement.
  </Accordion>
</AccordionGroup>

## Common Questions

<AccordionGroup>
  <Accordion title="How many use cases should we have?">
    Most companies start with 8-15 use cases and grow to 20-40 as they expand into new markets or product lines.
    Quality matters more than quantity—focus on your core value drivers first.
  </Accordion>

  <Accordion title="Can sellers edit use cases?">
    Sellers customize inputs for their specific buyers, but they can't change the underlying formulas or content.
    This ensures consistency while allowing personalization.
  </Accordion>

  <Accordion title="What if a use case doesn't fit a specific deal?">
    Sellers choose which use cases to include in each business case. If a use case isn't relevant to a particular
    buyer, they simply don't select it.
  </Accordion>

  <Accordion title="How do we update use cases across existing business cases?">
    Changes to use cases in your Value Framework don't automatically update existing business cases. This prevents
    disrupting deals in flight. New business cases will use the updated version.
  </Accordion>

  <Accordion title="Should we create variants for every scenario?">
    No. Only create variants when the calculation or narrative genuinely changes. If just the inputs differ (like
    team size), the base use case with customized inputs is enough.
  </Accordion>

  <Accordion title="Can we import use cases from spreadsheets?">
    Contact our support team for help migrating existing ROI models or business case templates into Minoa's use
    case format.
  </Accordion>
</AccordionGroup>

## Building Your First Use Case

Ready to start building? Here's a quick checklist:

* [ ] Identify a core value driver from recent won deals
* [ ] Write an outcome-focused name and description
* [ ] List the inputs needed to calculate this value (team size, time spent, etc.)
* [ ] Build the formula connecting inputs to value
* [ ] Add at least one customer example or proof point
* [ ] Set properties so sellers can find it easily
* [ ] Test it by creating a sample business case
* [ ] Gather feedback from sellers and refine

<Check>
  Once you've built a few core use cases, your team can start creating consistent, credible business cases in minutes
  instead of hours.
</Check>