> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usefluency.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Opportunity Prioritization
> Understand how Fluency recommends what to automate first, and how to override those recommendations when your context calls for it.
Fluency typically surfaces dozens (that quickly scales to hundreds, if not thousands as you expand) of opportunities across your organization. Rather than hand you a flat list and ask you to compare all of them, Fluency makes an opinionated first recommendation about what to do next, and lets you adjust it based on context we may not know.
This page explains how those recommendations are made, in three layers:
1. **The short version**: what you see in the product and how to act on it.
2. **The two scores**: how Fluency measures Value and Feasibility.
3. **The math**: the exact equations, for teams who want to understand the model.
## The short version
Every opportunity Fluency surfaces is scored on two things:
* **Value**: how much this opportunity is worth to your business.
* **Feasibility**: how realistically Fluency can ship and operate the automation today.
Plotting each opportunity on those two axes gives you four quadrants:
| | **High feasibility** | **Lower feasibility** |
| --------------- | --------------------------------------------------------- | -------------------------------------------------------------------------------- |
| **High value** | **Prime movers**: high impact, ready to ship. Start here. | **Strategic bets**: high impact, but need connectors, gates, or phased delivery. |
| **Lower value** | **Quick wins**: good momentum and pilot proof points. | **Backlog**: park, deprioritize, or standardize the process first. |
The raw dollar impact stays visible on every opportunity. The score helps you rank the work; the dollars help you sell the value internally.
### How to use the recommendation
* **Prime movers** are the default answer to *"what should we automate this quarter?"*
* **Strategic bets** belong on your roadmap, usually with a gating step such as a new connector, a compliance review, or a pilot.
* **Quick wins** are useful when you need to build internal momentum or prove the model to a skeptical stakeholder.
* **Backlog** items should be parked or flagged as *standardize first* before revisiting.
Every recommendation is editable. If you know something Fluency doesn't (a regulatory deadline, a leadership mandate, an upcoming system migration), you can promote, demote, or re-quadrant any opportunity, and Fluency will preserve your override.
## The two scores
### Value: what this opportunity is worth to you
The Value score answers a single question: *if we automated this tomorrow, how financially meaningful would it be?*
It goes up when the work:
* Takes more human time overall (a lot of annual hours)
* Happens frequently, so automating it removes a recurring drag on the team rather than a once-a-quarter push
* Is done by more expensive people
* Creates costly errors when it's done wrong
Annual hours and frequency answer different questions. Annual hours tells us *how much* time the process consumes in a year. Frequency tells us how that time is *distributed*. Two processes can burn the same 2,000 hours a year, but a daily process feels very different from a month-end crunch: automating the daily one removes a constant load from the team immediately, while automating the month-end one shows up as a single relief moment. Fluency weights daily, recurring work slightly higher because that's usually where teams feel the impact first.
Value is **customer-relative**. A "big" opportunity is defined against the rest of *your* portfolio, not against other Fluency customers. A \$400K opportunity might be a Prime Mover at one company and a Quick Win at another.
### Feasibility: how realistically we can ship it
The Feasibility score answers: *how confident are we that Fluency can deliver this reliably, today?*
It goes down when the work:
* Requires a lot of human judgement that's hard to verify
* Depends on systems we don't yet integrate with
* Is executed inconsistently across teams or regions
* Carries regulatory, compliance, or reputational risk
* Requires an agent pattern we haven't built before
Feasibility is **Fluency-relative**. A feasibility score of 85 means the same thing across every customer. It's a statement about our ability to deliver, not about your organization.
Feasibility improves over time. As Fluency's agent library grows, the same opportunity in your portfolio can become more feasible without anything in your process changing. Scores are recalculated continuously.
## The math
This section is for teams who want to audit, tune, or replicate the scoring. If you're just using the recommendations, you can stop reading here.
### Value
$$
V = H \cdot R \cdot \phi \cdot \epsilon
$$
| Variable | Name | What it captures |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- |
| Annual Hours | Total human time spent on the process over a year. | |
| Loaded Rate | Fully-loaded hourly cost: salary plus benefits, payroll tax, and overhead. Default: salary × 1.4. | |
| Frequency Weight | Modifier for how the annual hours are *distributed* across the year. Daily, recurring work ranks higher than a once-a-month or once-a-quarter push, even at the same total hours. | |
| Error Modifier | Modifier for the cost of getting the work wrong today. | |
**Frequency weight (**$\phi$**).** A reasonable default is $\log(\text{executions per year})$, clamped between 0.5 and 2.0. It's a modifier, not the main driver; hours and rate should still dominate.
$\phi$ intentionally does **not** double-count hours. $H$ already tells us the total annual time. $\phi$ captures the *shape* of that time: 2,000 hours spread across 250 daily runs is a heavier felt burden than the same 2,000 hours concentrated into 12 monthly runs, so the daily one gets a small uplift. If you'd rather rank strictly on dollars, set $\phi = 1$.
**Error modifier (**$\epsilon$**).** A simple form:
$$
\epsilon = 1 + (\text{rework rate}) \times (\text{rework cost factor})
$$
Use a rework cost factor of **1** for time-only rework, and a higher factor (e.g. **3**) when mistakes create cash impact such as wrong payments, missed discounts, or penalty exposure.
### Feasibility
$$
F = \frac{1}{C \cdot \iota \cdot \sigma \cdot \rho \cdot \alpha}
$$
| Variable | Name | What it captures |
| ------------------ | ------------------------------------------------------------------ | ---------------- |
| Complexity | How much judgement the process requires, and how verifiable it is. | |
| Integration Gap | How much technical plumbing is missing. | |
| Variance | How consistently the process is executed across runs. | |
| Risk Factor | Regulatory, compliance, reputation, or customer-impact risk. | |
| Agent Reuse Factor | Whether we've already built an agent for a similar process before. | |
#### Complexity ($C$)
The key question complexity measures is *"how do we know the agent got it right?"* (not *"does this feel hard?"*)
| Score | Type of work |
| ----- | --------------------------------------------------------------------------------------------------------- |
| 1.0 | Deterministic work, fixed inputs, fixed path. |
| 1.2 | Rule-based work with branching and auto-verifiable outputs (e.g. 3-way matching, routing). |
| 1.5 | Judgement work with verifiable outputs and reversible mistakes (e.g. vendor chasing, exception triage). |
| 2.5 | Judgement work where the outcome is consequential and hard to verify (e.g. claims adjudication, pricing). |
| 4.0 | Relationship or negotiation work. |
The small gap between 1.2 and 1.5 is intentional. It keeps agentic judgement work ranking well when the output can still be verified. Money touching the process does not automatically make it complex; the actual consequence is captured separately in $\rho$.
#### Integration Gap ($\iota$)
| Score | Situation |
| ----- | ------------------------------------------------------------------- |
| 1 | Systems already integrated with Fluency. |
| 3 | APIs exist, but new connectors need to be built. |
| 5 | Legacy systems, no APIs, screen scraping, or computer-use required. |
#### Variance ($\sigma$)
A useful proxy:
$$
\sigma = \frac{1}{\text{share of executions in the dominant cluster}}
$$
If the dominant execution pattern represents less than **30%** of runs, Fluency flags the opportunity as **standardize first** rather than automate immediately.
#### Risk Factor ($\rho$)
Score the *action the agent will take*, not the broad process area.
| Score | Action |
| ----- | ------------------------------------------------------------------------- |
| 1 | Internal, low-stakes action. |
| 3 | Customer-facing action or money movement. |
| 5 | Regulated activity, audit-trail requirement, or high human sign-off need. |
For example, *"recommend a match for approval"* may be a **1**, while *"auto-release the payment"* may be a **5**, even if both live inside the same underlying process.
#### Agent Reuse Factor ($\alpha$)
| Score | Situation |
| ----- | ------------------------------------------------------------- |
| 1.0 | Existing agent, only configuration or integration changes. |
| 1.3 | Existing agent, but meaningful adaptation is needed. |
| 1.7 | New agent, composed from existing capabilities we've shipped. |
| 2.2 | Net-new agent pattern and first build. |
$\alpha$ is the only variable that can change without *your* process changing. As Fluency ships more agents, the same opportunity in your portfolio can become more feasible over time. This also concentrates the agent library around patterns we've proven.
### Normalization
Both axes are normalized to a 0–100 scale, but differently, because they mean different things.
**Value** (customer-relative):
$$
V_{norm} = 100 \times \frac{\log V - \log V_{min}}{\log V_{max} - \log V_{min}}
$$
The log transform prevents a single very large process from making everything else look tiny. The min–max range is scoped to your portfolio.
If you have fewer than about 8–10 opportunities, min–max normalization can be unstable. In that case Fluency uses fixed dollar bands instead: $0–50K**, **$**50–250K**, $250K–1M**, and **$**1M+**.
**Feasibility** (Fluency-relative):
$$
F_{norm} = 100 \times \left(1 - \frac{\log D}{\log 120}\right), \quad D = C \cdot \iota \cdot \sigma \cdot \rho \cdot \alpha
$$
Feasibility uses fixed bounds (a realistic difficulty range is roughly **1 to 120**), so an 85 in feasibility means the same thing across every Fluency customer.
### Ranking into a single list
When you need one ordered list rather than a 2×2:
$$
\text{Priority} = w \cdot V_{norm} + (1 - w) \cdot F_{norm}, \quad \text{default } w = 0.6
$$
The default slightly favors value over feasibility. You can tune this in the product:
* Lower $w$ (e.g. **0.4**) when the mandate is *"quick wins to build momentum."*
* Higher $w$ (e.g. **0.75**) when the mandate is *"go after the biggest transformation bets."*
### Quadrant thresholds
Fluency uses **50** as the default threshold on both axes to split the four quadrants. You can move those thresholds on a per-portfolio basis; for example, raising the value threshold if your leadership has set a minimum-impact bar for this fiscal year.
## FAQ
They're related but not the same. **Annual hours** measures *how much* human time the process consumes over a year. **Frequency** measures *how that time is distributed*.
Two processes can consume the same 2,000 annual hours:
* One runs daily. Automating it removes a constant, visible load from the team, every day.
* One runs once a month with a hundred cases at month-end. Automating it removes a single spike.
Both save the same dollars on paper. But the daily one usually *feels* more impactful because the workload disappears immediately and stays gone. Fluency's Frequency Weight applies a small uplift to recurring, daily work to reflect that felt impact, without overriding the raw dollar value.
A single score hides the trade-off you're actually making. A $2M opportunity that needs a new legacy connector and a $200K opportunity that ships next week are both interesting, but for very different reasons. Splitting Value and Feasibility lets you see which is which, and pick the mix that fits your mandate this quarter.
Yes. Every quadrant assignment, weighting, and threshold is editable. If you know something Fluency doesn't (a regulatory deadline, an M\&A freeze, a leadership mandate), promote or demote any opportunity and Fluency will preserve your override on subsequent recalculations.
The Agent Reuse Factor ($\alpha$) improves as Fluency ships more agent patterns across the customer base. When we build a pattern that's a good fit for one of your opportunities, its feasibility goes up, sometimes moving it from Strategic Bet into Prime Mover, without you doing anything.
If a process is executed in many different ways across teams or regions (Variance $\sigma$ is high, and no single execution pattern dominates), automating it locks in the inconsistency. Fluency flags these as *standardize first*: pick a canonical version of the process, roll it out, then revisit the opportunity once the variance has dropped.