> ## Documentation Index
> Fetch the complete documentation index at: https://klarityai-add-transformation-playbook.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Set the objective

> Name the enterprise outcome in plain business terms before choosing any technology.

It's worth being deliberate about the objective before anything else. AI, agents, and skills are powerful means. The objective itself is an enterprise outcome: growing revenue, lowering cost, or reducing risk. Naming that outcome in plain business terms early gives the whole effort a clear yardstick and keeps the work pointed at results that matter to the business.

## What a well-formed objective does

**Leads with the outcome, not the means.** Start from the problem and the result you want rather than the technology. Say "our month-end close takes eight days and three late nights" rather than "we want a close agent." Keeping the objective means-agnostic lets the best solution emerge, whether that turns out to be a skill, an Integration Flow, an agent, a process change, or no build at all.

**Connects to a lever of enterprise value.** The clearest objectives ladder up to growing revenue, lowering cost, or reducing risk, the outcomes leadership is already working toward. Anchoring there keeps the effort focused on what moves the business.

**Is measurable, with a baseline and a target.** Name the metric, where it stands today, where you'd like it to be, and by when. "Cut the close from 8 days to 5 within two quarters." You'll quantify the baseline precisely in [Discover](/transformation/company-brain); it helps to commit to the metric now.

**Has an owner.** Tie the objective to the executive who owns the outcome, the CFO for the close, the CRO for pipeline, so it stays anchored as the work progresses.

**Is scoped to something winnable.** Bound it to a value stream, function, or process family. "Order-to-cash in the North America billing team" rather than "transform finance." Big enough to matter, small enough to show a result in a quarter.

**Names constraints up front.** Non-negotiables shape which solutions fit, so it helps to state them early: "no net-new engineering," "must run inside our existing stack," "human approval for anything customer-facing," along with any regulatory, data-residency, budget, or timeline limits. These become the guardrails the assistant works within.

**Stays separate from the use cases.** One objective usually points to several possible use cases, so there's no need to commit to a specific build yet. Selection comes later, in [Pick the right use case](/transformation/use-case-selection). The objective is the destination, the use cases are the route.

## A simple test

A good objective fits in one sentence.

```text theme={null}
[outcome + metric] for [scope], by [when], within [constraints], owned by [executive]
```

Vaguer:

> Deploy AI agents in finance this year.

Sharper:

> Cut month-end close from 8 days to 5 within two quarters, without adding headcount or net-new engineering. Owned by the Controller.

<Note>
  The [technical track](/transformation/technical-track) opens with this same step. If you're building in a coding harness, your assistant can help you frame the objective and its constraints before anything else happens.
</Note>