Active POV Deal Room

Inside this Project, Claude carries the evaluation state:

• Agreed success criteria and the status of each, with the evidence behind every status change.
• The stakeholder map — who is involved, what each cares about, and their stance as it moves.
• Technical objections and their resolutions, so the same concern is not relitigated in week five.
• The timeline against the close plan, including what has slipped.

Create one Project per active proof of value. The pattern is reusable; the workspace is per-evaluation, because mixing two evaluations makes the criteria scorecard meaningless.

Reach for this Project when:

• A deal has moved into a formal evaluation, pilot, or proof of value.
• Several stakeholders are evaluating against explicit criteria.
• You need to give an executive a short, honest status update on a recurring basis.
• Technical objections are accumulating and you need them tracked rather than remembered.

Use something else when:

• You are qualifying rather than proving — that is MEDDPICC Deal Strategy Workspace.
• You are answering formal written questions — that is RFP Response Assistant.

At setup, you provide the deal context block described in the setup steps. Then, continuously:

• The agreed success criteria, ideally with how each will be measured and by whom.
• The stakeholder list with roles, and who owns which criterion on the customer side.
• Technical requirements and any constraints raised.
• The evaluation timeline and the close plan.
• Notes from each evaluation session as it happens.

The lost-POV debrief is the more useful of the two. Evaluations usually fail for reasons that were visible early and unaddressed.

Claude accepts files up to 30MB each, and there is no fixed limit on how many you add, but everything in a Project's knowledge has to fit the context window. Fewer, sharper files beat a full archive.

Prepare files this way:

• Strip cover pages, legal boilerplate, and navigation chrome — they consume context and carry no signal.
• Prefer text formats. A clean export beats a scanned PDF.
• Name each file for what it contains, not when you exported it. Claude reads filenames.
• One subject per file. A merged reference document is harder to cite precisely.
• Date anything that goes stale, inside the file itself, so Claude can tell you when it is working from old material.

This Project is a reusable pattern. You create one workspace per active proof of value and fill the deal context block at setup — the block is a setup step, not part of the standing instructions.

1. Create one Project for this evaluation. Name it for the deal — for example POV — Halden Group.
2. Paste the Project Instructions.
3. Replace the four bracketed fields, which together form the deal context block: company, deal name, success criteria, and evaluation end date.
4. Upload the knowledge files, success-criteria template and technical requirements first.
5. Run the setup session using the starting prompt. Claude will test whether your criteria are actually measurable — expect it to push back on at least one. That pushback before the evaluation starts is the highest-value moment in this Project.
6. Update after every evaluation milestone, not weekly by habit. Milestones are what move criteria.

The bracketed fields below are placeholders you replace with your own details before you save the instructions. Leaving them unfilled produces generic output — that is the single most common reason a Project underperforms in its first week.

This Project has four, all new — the original hard-coded one deal's contacts into the instructions, which is why it could not be reused:

• [FILL IN: Company Name] — your employer.
• [FILL IN: Deal Name] — the account or opportunity this workspace covers. One per Project.
• [FILL IN: POV Success Criteria] — the criteria agreed with the customer. If you cannot fill this, you do not yet have an evaluation; you have a demo.
• [FILL IN: Evaluation End Date] — the agreed end date, which anchors every timeline judgement.

Role

You are a proof-of-value programme manager for [FILL IN: Company Name], running one active evaluation. You track agreed criteria against evidence, keep the risk register current, and write updates that are accurate rather than reassuring.

Operating rules

• Never mark a criterion met without the customer's confirmation. Name who confirmed it.
• Distinguish a technical blocker from a commercial one.
• Never draft a customer-facing claim the rep has not verified.
• Never assume silence is agreement.
• Flag early when remaining time cannot accommodate remaining criteria.

Status values, fixed

Met · In progress · Not started · Failed · Descoped. No informal alternatives, because ambiguity in a status is how a failing evaluation stays invisible until the last week.

The full instructions continue with the criteria module, stakeholder mapping, the risk register, executive update discipline, the five commands, output formats, and escalation.

This Project produces four deliverables:

• Criteria scorecard — every agreed criterion with status, evidence, and owner.
• Status summary — where the evaluation stands, for internal use.
• Risk register — open risks with owners, severity, and next action.
• Executive update — three lines an executive sponsor can read on a phone.

A mid-POV status summary. Halden Group is fictional.

POV status — Halden Group — day 22 of 45

Criteria

Two met, one in progress, one not started, at day 22 of 45.

Open risks

1. Security review has no date. Severity: high. SSO gates the workflow criterion, so a slip here compounds. Next action: ask the security lead for a date this week. Owner: us.
2. The workflow criterion depends on their team's availability in a week that overlaps their quarter close. Severity: medium. Next action: confirm resourcing now, or agree a revised date while there is still room. Owner: us.

Executive update

Two of four success criteria are met with the customer's own confirmation, at the halfway point. SSO is configured and waiting on their security review, which currently has no date and is the main schedule risk. The final criterion requires their team to rebuild two workflows in week five; we are confirming their availability now.

Note: no criterion has been marked met without the customer confirming it. The not-started criterion is the one the executive sponsor cares most about, and its status should not be softened in the next update.