---
title: "Define the App's Job"
description: "Keep a useful prototype from becoming an undefined platform by agreeing on what this release must prove and what it will not do."
canonical_url: "https://vercel.com/academy/enterprise-apps-agents/define-success"
md_url: "https://vercel.com/academy/enterprise-apps-agents/define-success.md"
docset_id: "vercel-academy"
doc_version: "1.0"
last_updated: "2026-09-14T22:07:15.754Z"
content_type: "lesson"
course: "enterprise-apps-agents"
course_title: "Enterprise Apps and Agents"
prerequisites:  []
---

<agent-instructions>
Vercel Academy — structured learning, not reference docs.
Lessons are sequenced.
Adapt commands to the human's actual environment (OS, package manager, shell, editor) — detect from project context or ask, don't assume.
The lesson shows one path; if the human's project diverges, adapt concepts to their setup.
Preserve the learning goal over literal steps.
Quizzes are pedagogical — engage, don't spoil.
Quiz answers are included for your reference.
</agent-instructions>

# Define the App's Job

# Define the app's job

Once people try Vendor Review, they may ask it to negotiate contracts, provision accounts, or monitor renewals. Each request adds work and requires different permissions. Decide which requests belong in the first release before extending the application.

## Decide what belongs in this release

Classify these requests as **now**, **later**, or **not this application**, then compare your choices with the answer below.

| Proposed behavior                                            | Your decision |
| ------------------------------------------------------------ | ------------- |
| Identify missing information in a vendor request             |               |
| Route requests involving restricted data to Security         |               |
| Purchase software under $1,000 automatically                 |               |
| Create employee accounts after approval                      |               |
| Follow up with an employee until missing information arrives |               |
| Sign the vendor's contract                                   |               |

Compare your decisions

**Now:** identify missing information and route requests using written policy. These behaviors prove the core review path.

**Later:** follow-up with employees. A scheduled reminder can use a fixed workflow. Letting a model choose when and how to follow up introduces agent behavior; that needs separate rules for tool access, retained context, and human approval.

**Not this application:** purchasing, provisioning, and signing. Those actions belong to systems and people with different authority.

Record your choices in the **Application job** section of `docs/readiness.md`.

## Purpose

Use one sentence:

> Help a small Procurement and Security review group identify incomplete or higher-risk software requests and route them to the right human.

Avoid claims such as “automate vendor approval.” The application does not have that authority.

## Business outcome

Name the pain in the current process before naming a product or feature. For Vendor Review, incomplete requests force Procurement and Security to gather missing context before they can make a decision.

Record one baseline and one target:

```text
Current process:
Business owner:
Baseline measure:
Target measure:
Review date:
```

A useful target might reduce the percentage of requests returned for missing information or shorten the time from a complete submission to a reviewer decision. The measure should describe the business process, not page views, model calls, or the number of features shipped.

## Include in this release

- Collect a consistent vendor request
- Identify missing information
- Apply written cost and data-handling policy
- Suggest a risk classification
- Route requests that require review
- Preserve the assessment and human decision

## Leave out of this release

- Purchasing software
- Signing contracts
- Provisioning employee accounts
- Making a final security or legal determination
- Replacing the source-of-truth procurement system

## Choose the first users and owners

Name a small test group and assign roles, even if one person fills several during the course:

- Application owner
- Technical owner
- Procurement reviewer
- Security reviewer
- Test group

## Evidence

Choose evidence before the dashboard exists:

- Completion rate for submitted requests
- Percentage returned for missing information
- Agreement between routing policy and human reviewers
- Time from submission to decision
- Model failures or invalid outputs
- Cost per assessment

The evidence should be capable of disproving the application’s value. “People liked it” is feedback. It does not prove that the review process improved.

## Defend the release scope

Ask another person to play a stakeholder and choose one excluded behavior. Give yourself sixty seconds to explain why it is excluded and what evidence would justify reconsidering it. If the answer depends on “we can probably add it,” the decision is not yet clear.

Commit the decision before implementation begins:

```bash
git add docs/readiness.md
git commit -m "docs: define the Vendor Review job"
```

## Summary

This release helps reviewers assess software requests; it does not purchase software or sign contracts. Its owners will judge it by measures such as fewer incomplete requests and shorter review times.

## Check your work

Give someone only the **Application job** section. Ask what Vendor Review may decide, what still belongs to a person, and who owns the result. If any answer requires you to explain what the document “really means,” revise the document.


---

[Full course index](/academy/llms.txt) · [Sitemap](/academy/sitemap.md)