Use a Claude Project to Turn Product Notes into an Escalation Matrix

A support team can have plenty of product notes and still lack a consistent answer to one question: when should a case move to a specialist?

This is an illustrative Claude Projects workflow with fictional notes. It is documentation based, not a captured Claude execution and not a claim that the resulting matrix is suitable for a real support policy.

What you will make

You will create an escalation matrix with these columns:

Issue type
Trigger stated in the notes
Suggested first team
Evidence source
Missing information
Human approval needed

The matrix is a draft for review. Claude should not decide that a real customer case is urgent or send a reply.

What you need

A Claude Project. The Claude Projects help page explains project knowledge and notes that enhanced project knowledge through retrieval is available on paid plans. Project features and access can vary, so check the current account surface.
A small set of approved product notes.
A named support owner who can review the matrix before use.

Create a project and add one file named product-notes.txt with this complete fictional input:

Product: Northstar Reports
Notes version: 2026-09-20
Owner: Support Operations

Export failures
Customers may retry an export after checking whether the selected date range contains data. The notes do not state how many retries are acceptable. If the export still fails, Support should collect the report name, date range, and error text before routing the case to Technical Support.

Unexpected totals
A total can differ from an earlier report when the underlying date range or filters changed. Support should compare the date range and filters first. The notes do not define a tolerance or a reconciliation procedure.

Access requests
Workspace access is managed by the customer's workspace administrator. Support can explain where the administrator changes access. The notes do not authorise Support to change a customer's permissions.

Possible data exposure
If a customer reports that another customer's information appeared in a report, stop normal troubleshooting and route the case to the security contact. The notes do not include a response deadline or the name of the security contact.

Known gaps
The product notes do not define severity levels, response times, an after-hours process, or a customer message template.

This file is fictional practice material. Do not upload real customer records or secrets just to try the workflow.

1. Add project instructions

In the project’s instructions, paste:

You are preparing a draft escalation matrix from the project knowledge.

Use only the product notes supplied in this project. For every proposed route, cite the exact note section or quote the supporting sentence.

Separate these fields:
- What the notes state
- Suggested routing based on the notes
- Missing policy detail
- Human approval needed

Rules:
- Do not invent severity, deadlines, names, permissions, legal conclusions, or customer promises.
- Do not turn a missing response time into a guessed SLA.
- Do not recommend that Support change permissions.
- Treat a possible data exposure report as a routing trigger described by the notes, not as a confirmed incident.
- If the notes do not answer a question, write NOT STATED.
- Do not draft or send a customer reply.

Project instructions are a boundary, not a replacement for a support policy. Claude’s project knowledge can make repeated work easier, but a reviewer still needs to check that the right notes are present.

2. Ask for the matrix

Start a project chat and paste:

Using only product-notes.txt, create a draft escalation matrix with these columns:

| Issue type | Trigger stated in notes | Suggested first team | Evidence quote | Missing information | Human approval needed |

Then add:
1. A list of statements that are directly supported by the notes.
2. A list of policy gaps that block a final operating procedure.
3. Five review questions for the Support Operations owner.

Keep possible data exposure as a routing concern, not a confirmed incident. Do not create severity levels, response times, contact names, permissions, or customer promises that the notes do not state.

3. Review the checkable artifact

For the fictional notes, a reasonable illustrative target includes these rows:

Issue type	Trigger stated in notes	Suggested first team	Missing information
Export failure	Retry after checking whether the date range contains data; collect report name, range, and error text if it still fails	Support first, then Technical Support	Retry limit and technical response process
Unexpected total	Compare date range and filters with the earlier report	Support first	Tolerance and reconciliation procedure
Access request	Customer’s workspace administrator manages access	Support can explain the administrator path	Product specific steps and any approved exception process
Possible data exposure	Stop normal troubleshooting and route to the security contact	Security contact	Contact name, severity, response time, and after hours route

This is an illustrative target written from the fictional notes. It is not captured Claude output. Check every row against product-notes.txt.

4. Run the acceptance checks

The draft passes when:

Every route has a matching sentence in the notes.
The security row does not claim that an incident is confirmed.
No row invents an SLA, contact name, severity, or permission.
Access requests are not turned into an instruction for Support to change permissions.
The missing policy details are visible in a separate column.
The owner receives review questions before the matrix is used in an operating procedure.

Troubleshooting

Claude uses an old note. Check the project’s knowledge files and remove or replace superseded material before asking for another draft. Do not solve conflicting sources by asking for a more confident answer.

It fills in a missing SLA. Repeat the NOT STATED rule and ask it to quote the exact note that supports each response time. If no quote exists, keep the field open.

It turns routing into a decision. Rename the column from Decision to Suggested first team and add Human approval needed. This keeps the draft from sounding like an approved policy.

The matrix cites no source. Ask for one evidence quote per row, then compare the quote with the project file. A project answer is not evidence by itself.

Limits and safer use

Project knowledge can contain sensitive operational information. Use approved notes, review who can access the project, and remove outdated files. Claude’s help documentation describes project sharing and knowledge controls, but the available controls depend on the plan and workspace.

TRY: a fictional or low risk product note with a named owner and four or fewer issue types.

SKIP: live incident handling, access changes, security response, or customer communication without an approved procedure and human owner.

USE: the matrix as a draft for policy review. Do not treat it as an escalation policy until the responsible team approves the missing fields.

For practical AI for work tasks with an honest TRY, SKIP, or USE decision, get The Weekly Verdict.