Prototype an AI Support Triage Copilot

Build and deploy a scripted AI support triage prototype with v0.

Introduction

30 Second Summary

Support teams face a stream of messages that range from obvious billing questions to vague cries for help. A fast wrong route can waste more time than a careful handoff.

In this project, you will build SupportSignal, a clickable AI support triage case study for five scripted customer messages. You will use v0 to reveal how product policy changes the outcome of the same ambiguous request.

What You'll Build

A reviewer can open your live Vercel link to watch SupportSignal choose a safe next state for each customer message.

By the end of this project, you'll have:

  • A clickable customer-support journey for testing five messages through to an observable routing decision.
  • A before-and-after policy demonstration that exposes an overconfident route before showing safe human review.
  • A portfolio-ready mini-PRD backed by acceptance criteria plus a scripted validation scorecard.
  • Secret Mission: A policy simulator that shows how confidence thresholds change automation coverage versus human-review volume.

Are there any prerequisites?

An internet connection plus an existing Vercel account are the only prerequisites. You do not need coding experience, local software, GitHub, an API key, or a paid upgrade.

Before We Start

Before you shape SupportSignal, lock in the support-routing problem it must solve. A clear outcome keeps every later product choice focused on safer decisions for incoming requests.

Open Your Browser-Based Product Studio

SupportSignal already has a clear outcome: safer routing decisions for support operations leads. The next risk is losing focus to local setup before the product behavior exists.

The browser-based v0 studio keeps your attention on user decisions. Your existing Vercel account gives you access without another account setup.

In this step, get ready to:
  • Sign in to v0 with your existing Vercel account.
  • Start a blank product conversation named SupportSignal.
  • Reserve your Free plan messages for functional work.
Sign in with your existing account

Your v0 access uses the same account as Vercel. This project stays within the Free plan.

You should see the v0 sign-in experience in your browser.

Your sign-in details stay inside the official v0 and Vercel flow. Keep your password out of screenshots or project notes.

  • Choose the sign-in option for your existing account.
  • Enter the same account details you use for Vercel.

You should arrive in the v0 workspace under your signed-in account.

No billing setup is required for this project. Your existing account is enough for the full workflow.

  • Skip any prompt to connect GitHub.
  • Skip any prompt to add a payment method.

You remain in the browser workspace without adding an integration or billing method.

Having trouble signing in?

  • Retry the sign-in flow with the same Vercel account.
  • Avoid creating a second account while troubleshooting.

Help me troubleshoot signing in to v0 with my existing Vercel account. If you still need help, ask the NextWork community.

Start a clean product conversation

A clean chat gives SupportSignal one focused place for every product decision. The empty prompt editor is the launch point for the first prototype.

  • Start a new chat from the v0 workspace.

You should see a blank prompt editor ready for a product description.

  • Keep the default browser preview available beside the conversation.
  • Set the working concept name to SupportSignal when v0 asks for or creates the project name.

You should see the SupportSignal name attached to the new conversation. The browser preview should remain available for the prototype.

Why keep the setup empty?

The blank chat is the complete setup for now. SupportSignal uses scripted browser behavior later.

  • GitHub stays disconnected.
  • External APIs stay disconnected.
  • Databases stay disconnected.
  • Authentication systems stay disconnected.
  • Live AI models stay disconnected.
Reserve your prompt budget

Each v0 message spends part of your daily iteration budget. The v0 Free plan has a 7 message/day limit.

The main path uses three build prompts. The optional simulator uses one more prompt.

  • Reserve three messages for the core build prompts.
  • Reserve one message for the optional simulator prompt.
  • Keep three messages available for focused corrections.
  • Delay cosmetic requests until the product states work.

Before you check your setup, which visible signs should prove that the studio is ready for the first build prompt?

  • Confirm that your existing Vercel account is signed in to v0.
  • Confirm that the new conversation is named SupportSignal.
  • Confirm that the browser preview is available.
  • Confirm that the prompt editor is empty and ready.

You should now see a signed-in SupportSignal workspace with a blank prompt editor and the browser preview available. No GitHub integration or payment method has been added.

Your product studio is ready with the right account and a protected message budget. Next, you will generate SupportSignal's first clickable routing experience.

Build the Naive Routing Experience

Your SupportSignal conversation in v0 is ready for its first product prompt. This step turns the empty preview into a clickable support-routing experience.

Automatic routing can look convincing before its decision policy is tested. You will build the simplest version first so one weak boundary becomes visible through use.

In this step, get ready to:
  • Define the reviewer and the first support-routing journey.
  • Generate the first SupportSignal prototype from one structured prompt.
  • Test clear requests before exposing the automatic-routing failure.
Define the first user journey

A user journey connects the reviewer's goal to the decisions shown on screen. Here, a support operations lead checks whether incoming requests reach a consistent destination.

  • Set the support operations lead as the primary reviewer.
  • Place customer message submission at the start of the journey.
  • Place request analysis after submission.
  • Place the proposed route after analysis.
  • Place the support team's action at the end.

What does this journey prove?

The reviewer needs to see how one customer message becomes one operational decision. Each visible state makes the proposed routing behavior easier to question.

This keeps the prototype focused on decision quality. Decorative details stay secondary to the route and next state.

Generate the baby version

v0 turns a natural-language product brief into an interactive browser preview. A structured prompt gives it the product surface plus the use context.

  • Click the prompt editor in the SupportSignal chat.
  • Paste this first build prompt:
Build a responsive interactive web prototype called SupportSignal.

Product surface:
- A header that explains this is an AI Customer Support Triage Copilot concept.
- A customer request panel with a text area, an Analyze request button, and four sample-message buttons.
- A routing result card that appears after analysis and shows Intent, Priority, Confidence, Destination, Decision explanation, and Next state.
- Sample 1: "I was charged twice for my subscription." Route to Billing.
- Sample 2: "I cannot reset my password." Route to Account Access.
- Sample 3: "The app crashes when I upload a file." Route to Technical Issue.
- Sample 4: "Something is wrong and I need help." Intentionally force this into Technical Issue with 86% confidence and auto-route it, even though the request is ambiguous.
- Add a visible badge that says "Scripted product prototype. No live AI model."

Context of use:
- Used by a support operations lead evaluating a proposed triage experience.
- The reviewer must be able to click every sample and see the result change without refreshing.

Constraints:
- Do not connect an API, database, authentication system, or external AI model.
- Use local scripted demo data only.
- Keep the interface professional, accessible, responsive, and suitable for a product-management portfolio.
- Make the routing decision and next state more visually prominent than decorative graphics.

What does this prompt do?

  • The Product surface section defines the controls and result fields the reviewer can use.
  • The Context of use section tells v0 who evaluates the experience.
  • The Constraints section keeps every result local and scripted.
  • The sample mappings give each button a repeatable result for later testing.

The first generation can take a few minutes while v0 assembles the interface. A quiet preview during that time does not mean the build has failed.

  • Submit the prompt using the send control beside the prompt editor.
  • Keep the browser preview available while v0 generates SupportSignal.
  • Confirm the header describes an AI Customer Support Triage Copilot concept.
  • Confirm the customer request panel contains a text area.
  • Confirm the panel contains the Analyze request button.
  • Confirm the panel contains four sample-message buttons.
  • Confirm the visible badge reads Scripted product prototype. No live AI model..

That is your first visible win: SupportSignal now has a clickable intake surface ready for routing tests.

Missing part of the intake experience?

  • Wait for v0 to finish generating before testing the sample controls.
  • Compare any missing control with the Product surface section of the prompt.
  • Check that the full prompt was submitted in the SupportSignal chat from earlier.

Ask for help diagnosing the generated preview without adding external services: Help me find why my SupportSignal preview is missing part of the scripted intake experience.

Experience the designed failure

The three clear samples establish whether the basic mappings behave consistently. The ambiguous sample tests whether the automatic-routing policy knows when evidence is weak.

  • Select I was charged twice for my subscription..
  • Activate Analyze request.

You'll see a result card containing Intent, Priority, Confidence, Destination, Decision explanation, and Next state. Its Intent value should be Billing.

  • Select I cannot reset my password..
  • Activate Analyze request.

You'll see the result change without a page refresh. Its Intent value should be Account Access.

  • Select The app crashes when I upload a file..
  • Activate Analyze request.

You'll see the third clear request route to Technical Issue.

Before you test the final message, do you think a vague request can justify automatic routing?

  • Select Something is wrong and I need help..
  • Activate Analyze request.

You'll see Technical Issue with 86% confidence. The request is auto-routed instead of being held for review.

You have now exposed the core product risk: polished automation can make an unsupported decision look settled.

Results not matching the scripted routes?

  • Confirm that you select a sample before activating Analyze request.
  • Compare the mismatched result with its sample mapping in the original prompt.
  • Keep any correction focused on the mismatched sample.

Get help diagnosing a mismatched scripted result: Help me correct a SupportSignal sample that produces the wrong scripted route.

Your prototype now demonstrates both plausible routing and overconfident automation. Next, you will turn that exposed gap into an explicit intent policy with human handoff.

Add the Intent Map and Human Handoff

Your first SupportSignal version exposed the central product risk. An ambiguous request received 86% confidence and was auto-routed.

A classification is only useful when a routing policy controls the next action. You will use v0 to make those decision boundaries visible.

In this step, get ready to:
  • Define a five-outcome intent map.
  • Add policy-based human handoff.
  • Verify each escalation path.
Define the routing policy

A routing policy connects each classification to a safe next action. Confidence measures certainty in the classification.

Risk policy determines whether the proposed action is safe.

  • Treat Billing as a routable intent.
  • Treat Account Access as a routable intent.
  • Treat Technical Issue as a routable intent.
  • Treat Cancellation as a routable intent.
  • Keep Unclear as a valid product state.
  • Apply a confidence threshold of 70% to require human review below that point.
  • Escalate suspected account compromise to human review at every confidence level.

Why use two escalation rules?

The 70% threshold is an illustrative product assumption. It gives the prototype a clear boundary for uncertain requests.

Critical risk acts as a separate safety override. A high-confidence classification can still require human judgment.

Repair the ambiguous route

The next prompt preserves the working prototype while adding explicit policy states. It also turns the earlier failure into a human-review journey.

  • In the SupportSignal prompt editor, preserve the current experience by pasting this follow-up prompt:
Preserve the existing SupportSignal experience and improve the routing policy.

Add an Intent Map panel that defines five outcomes:
1. Billing
2. Account Access
3. Technical Issue
4. Cancellation
5. Unclear

Change the ambiguous sample "Something is wrong and I need help." so it returns:
- Intent: Unclear
- Priority: Medium
- Confidence: 42%
- Destination: Human Triage Queue
- Next state: Needs Human Review
- Explanation: The request lacks enough detail for safe automatic routing.

Add a visible policy rule: requests below 70% confidence cannot be auto-routed.

Add a fifth sample: "I think someone accessed my account from a device I do not recognize."
Return Account Access with Critical priority and high confidence, but route it to Human Security Review because critical-risk requests must not be handled automatically.

For every result, show a state timeline: Submitted, Analyzed, then either Auto-routed or Awaiting human review.
Keep all behavior local and scripted. Do not connect a real model, API, database, or authentication system.

What does this prompt change?

  • The Intent Map makes every supported outcome visible to the reviewer.
  • The confidence rule sends uncertain requests to a human queue.
  • The critical-risk rule protects suspicious account-access requests at every confidence level.
  • The timeline reveals whether each request was auto-routed or held for review.
  • The local scripted constraint keeps the prototype aligned with its visible no-model badge.
  • Submit the prompt from the editor.
  • Confirm the preview includes the Intent Map.
  • Confirm the map shows Billing, Account Access, Technical Issue, Cancellation, and Unclear.
  • Confirm the visible policy uses the 70% boundary.
  • Confirm the suspicious-access message appears as the fifth sample.
  • Confirm the result card includes a state timeline.

The policy layer is now visible beside the routing result. Each recommendation can show the decision path that produced it.

Missing a policy state?

  • Confirm you submitted the follow-up prompt inside the existing SupportSignal chat.
  • Check that the prompt begins with Preserve the existing SupportSignal experience and improve the routing policy..
  • Ask v0 to apply the exact missing requirement from the follow-up prompt.

If the generated preview still misses a requested state, help me compare my SupportSignal preview with the routing-policy prompt.

Validate both escalation paths

Before you test the ambiguous sample, do you expect its new confidence level to permit automatic routing?

  • Select Something is wrong and I need help..
  • Activate Analyze request.

What should the low-confidence path show?

  • Intent reads Unclear.
  • Priority reads Medium.
  • Confidence reads 42%.
  • Destination reads Human Triage Queue.
  • Next state reads Needs Human Review.
  • The explanation reads The request lacks enough detail for safe automatic routing..
  • The timeline ends at Awaiting human review.

Before you test the suspicious-access sample, do you expect high confidence to override a critical-risk rule?

  • Select I think someone accessed my account from a device I do not recognize..
  • Activate Analyze request.

What should the critical-risk path show?

  • Intent reads Account Access.
  • Priority reads Critical.
  • Confidence remains high.
  • Destination reads Human Security Review.
  • The request remains in human review because critical-risk requests cannot be automated.
  • The timeline ends at Awaiting human review.
  • Open NextWork's Your Work panel.
  • Describe how confidence measures classification certainty.
  • Describe how risk policy determines whether the proposed action is safe.

Strong work. SupportSignal now separates classification confidence from action safety. Next, you will turn this decision logic into a portfolio-ready PM case study.

Turn the Prototype into a PM Case Study

Your routing policy now separates clear requests from cases that need human judgment. The interactive journey proves that SupportSignal can expose uncertainty safely.

A working demo proves execution. You will now turn that demo into a case study that explains each product decision through requirements and scripted evidence.

In this step, get ready to:
  • Add a mini-PRD that explains the product decisions.
  • Run the five-case scripted acceptance test.
  • Record a business-value hypothesis with future pilot measures.
Add the mini-PRD and validation surface

The mini-PRD connects the interface to a defined user problem. The Validation tab turns the five journeys into repeatable scripted checks.

The next v0 update adds both surfaces while preserving the routing policy you already tested.

  • In the SupportSignal chat from earlier, select the prompt editor.
  • Give v0 the case-study requirements by pasting this follow-up prompt:
Keep the existing SupportSignal prototype and add two portfolio tabs: Product Case Study and Validation.

In Product Case Study, create a concise mini-PRD with these sections:
- Problem: Support teams lose time and consistency when requests are manually interpreted and routed.
- Target user: Support operations lead at a growing SaaS company.
- User job: When new requests arrive, identify the right queue and which requests require human judgment.
- Product goal: Reduce avoidable manual triage without automating uncertain or high-risk decisions.
- Primary journey: Submit, analyze, review recommendation, then auto-route or hand off.
- In scope: Scripted intent classification, priority, confidence, explanation, routing state, and human handoff.
- Non-goals: Live AI inference, production integrations, authentication, customer data storage, and autonomous resolution.
- Functional requirements: Five sample scenarios, visible intent map, confidence policy, critical-risk rule, and observable state transitions.
- Acceptance criteria: Three clear requests auto-route correctly; one ambiguous request enters human review; one critical-risk request enters human security review; every result includes an explanation.
- Risks and mitigations: Overconfidence, ambiguous language, unsafe automation, and misleading prototype metrics.
- Open questions: Real intent distribution, acceptable false-route rate, staffing impact, language coverage, and production latency.

In Validation, add a five-row scripted test matrix with each sample message, expected intent, expected priority, expected next state, actual result, and pass or fail status.
Add a Run demo test set button that runs all five local scripted scenarios and calculates:
- Clear-intent routing success, target 3 of 3.
- Ambiguous-request escalation, target 1 of 1.
- Critical-risk escalation, target 1 of 1.
- End-to-end scripted journey completion, target 5 of 5.

Add a clear note: "These are prototype validation results from scripted cases, not model accuracy or production performance."
Do not add external services or a live model.

What does this prompt add?

  • The Product Case Study tab explains the problem behind SupportSignal.
  • The mini-PRD defines the prototype's scope and decision boundaries.
  • The Validation tab turns each scripted journey into an observable test.
  • The disclaimer keeps the results framed as scripted functional validation.
  • Submit the prompt using the control beside the prompt editor.

The browser preview should update with two new portfolio tabs while keeping the existing routing experience available.

  • Select Product Case Study in the updated browser preview.

You should see the support-routing problem at the top of the mini-PRD. The remaining sections should end with open questions.

  • Select Validation in the browser preview.

You should see a five-row scripted test matrix. You should also see a Run demo test set button.

Missing a case-study section?

  • Confirm that you submitted the follow-up prompt in the existing SupportSignal chat.
  • Submit one focused correction that names the missing section if the preview omits a requirement.

Help me identify why a required SupportSignal case-study section is missing.

Run the acceptance test

Acceptance criteria turn product requirements into observable pass or fail checks. These checks evaluate the scripted interaction logic only.

  • In the Validation tab from the previous substep, confirm that the matrix contains five sample rows.

Before you run the test set, do you expect every scripted journey to match the state defined in the mini-PRD?

  • Activate Run demo test set.

You should see an actual result for every sample row. Each row should also show a pass or fail status.

What should the scorecard show?

  • Clear-intent routing success has a target of 3 of 3.
  • Ambiguous-request escalation has a target of 1 of 1.
  • Critical-risk escalation has a target of 1 of 1.
  • End-to-end scripted journey completion has a target of 5 of 5.

The scorecard should include the note These are prototype validation results from scripted cases, not model accuracy or production performance.

✔️ All five rows pass

Strong work. Your five scripted journeys now satisfy the acceptance criteria defined in the mini-PRD.

ⓧ One or more rows fail

A failed row identifies a mismatch between the documented requirement and the generated behavior. Correct only that mismatch so the rest of the prototype stays stable.

  • Open the first row marked as failed.
  • Compare its actual state with the corresponding acceptance criterion.
  • Write one correction prompt that names only the failed sample.
  • State the expected intent in that correction prompt.
  • State the expected priority in that correction prompt.
  • State the expected next state in that correction prompt.
  • Submit the correction in the existing SupportSignal chat.
  • Activate Run demo test set again.

The corrected row should now match the expected state. The scorecard should show all five journeys passing.

Still seeing a failed row?

Help me compare the failed scripted result with its acceptance criterion.

Write the business-value hypothesis

Scripted results show that the prototype behaves as designed. They do not yet prove business value in a real support operation.

A business-value hypothesis links the current evidence to the product metrics that a future pilot should measure.

  • In the NextWork project workspace, select Your Work.
  • Record the hypothesis by pasting this text into a new note:
If SupportSignal routes clear requests while escalating ambiguous and critical-risk cases, then a support team could reduce avoidable triage effort without hiding uncertainty. In a real pilot, I would measure routing correction rate, human-review rate, time to correct queue, critical escalation recall, and cost per routed request. The current build validates the interaction and policy logic only.

What does this hypothesis capture?

  • The opening claim connects safe routing with reduced manual triage.
  • The metric list defines what a real pilot would measure.
  • The final sentence limits the current evidence to interaction and policy logic.
  • Save the note in Your Work.

Good work. Your saved hypothesis now separates current prototype evidence from future business measures.

  • Return to the SupportSignal browser preview from earlier.
  • Select Product Case Study.

You should see the mini-PRD beginning with the support-routing problem. You should see open questions at the end.

  • Select Validation.

Before the final test run, do you expect the scorecard to claim model accuracy or scripted functional validation?

  • Activate Run demo test set.

You should see five completed rows with the scorecard targets 3 of 3, 1 of 1, 1 of 1, and 5 of 5.

You should also see These are prototype validation results from scripted cases, not model accuracy or production performance.

SupportSignal now explains both the product policy and the evidence behind it. Next, you will make that case study available through a live Vercel URL.

Publish and Record Your Evidence

SupportSignal now demonstrates a safer routing policy alongside the product reasoning behind it. A reviewer still needs a way to inspect those decisions without your guidance.

In this step, you'll publish the scripted prototype from v0 to Vercel. You'll also record the decisions and validation evidence in NextWork.

In this step, get ready to:
  • Complete a PM launch review of the scripted prototype.
  • Publish SupportSignal using the provided Vercel domain.
  • Record a Stage 1 portfolio entry with the live evidence.
Complete the PM launch review

A launch review checks that the demo still supports the claim you plan to share. It also catches scope drift before the prototype becomes public.

  • Switch back to the Validation tab in the v0 preview from earlier.
  • Activate Run demo test set.

What should I see?

Clear-intent routing success should read 3 of 3.

Ambiguous-request escalation should read 1 of 1.

Critical-risk escalation should read 1 of 1.

End-to-end scripted journey completion should read 5 of 5.

  • Confirm the badge still reads Scripted product prototype. No live AI model.
  • Select the Product Case Study tab.
  • Confirm In scope describes scripted routing behavior.
  • Confirm Non-goals excludes live AI inference.
  • Confirm Non-goals excludes customer data storage.

The prototype now states what the scripted evidence proves. Its scope boundaries are visible before anyone sees the public version.

Publish SupportSignal to Vercel

Publishing turns the browser preview into a link another person can test. The production version must preserve the same local scripted states.

Making the prototype public can feel like a big switch. Publishing only exposes scripted demo content.

  • In the SupportSignal chat from earlier, click Publish in the header.
  • Set the Vercel project name to SupportSignal.
  • Choose the deployment visibility that lets reviewers open the prototype.
  • Keep the provided Vercel domain.
  • Click Publish.

The production build can take a few minutes. A progress state means Vercel is still preparing the live version.

  • Wait for the production deployment to finish.

You should see a production URL for the SupportSignal deployment.

  • Record the production URL here: your Vercel production URL.

Your production deployment is live. SupportSignal now has a URL another reviewer can open.

GitHub stays disconnected throughout this flow. The deployment goes directly from v0 to Vercel.

Production URL not loading?

  • Return to the Publish flow.
  • Confirm the production deployment has finished.
  • Confirm the provided domain belongs to SupportSignal.

Help me diagnose why my SupportSignal production URL is not loading. If the deployment remains blocked, share the deployment stage with the NextWork community.

Create the Stage 1 portfolio record

A Stage 1 portfolio record connects the live interaction to your product decisions. The final field points to visual workflow orchestration in n8n.

  • Return to the Your Work panel from earlier.
  • Start a Stage 1 portfolio entry for SupportSignal.
  • Record Product: SupportSignal, AI Customer Support Triage Copilot.
  • Record Role: AI Product Manager and no-code prototyper.
  • Add Live prototype: your Vercel production URL.
  • Record Problem: Support operations leads need safer, more consistent routing decisions for incoming customer requests, including human review when automation is uncertain or unsafe.
  • Record Key decision: low-confidence and critical-risk requests require human review.

These lines identify the product problem alongside the policy decision you made.

  • Record Validation: 3 of 3 clear routes, 1 of 1 ambiguous escalation, and 1 of 1 critical escalation.
  • Record Limitation: scripted local logic, not a live model or production evaluation.
  • Record Next stage: visual workflow orchestration in n8n.

Before you test the live URL, do you think a reviewer can verify the uncertainty policy without your explanation?

  • Open your Vercel production URL in a new browser tab.
  • Select the sample labelled Something is wrong and I need help.
  • Activate Analyze request.

You should see Unclear with 42% confidence. The next state should read Needs Human Review.

  • Select the Product Case Study tab.
  • Confirm the mini-PRD sections are accessible.
  • Select the Validation tab.
  • Confirm the five-row scripted test matrix is accessible.
  • Confirm the Run demo test set button is visible.

The live deployment now exposes the complete Stage 1 evidence package.

That closes Stage 1: reviewers can test the routing policy from one live URL without your guidance.

Secret mission

Simulate the Confidence Trade-off

Turn SupportSignal's confidence policy into an interactive stakeholder tool. You will compare three thresholds, reveal the trade-off between automation coverage and human-review volume, and keep critical-risk cases protected at every setting.

Clean Up Your Resources

Clean Up Your Resources

Choose whether to keep SupportSignal live, pause public access for later, or delete the published project. Leaving the provided Vercel domain online adds no required ongoing project spend.

Resources you used:

  • The SupportSignal Vercel project, including its production deployment and live production URL.

Keep everything running

No action needed. Choose this if you want reviewers to keep accessing SupportSignal or plan to continue improving it.

  • Leave the SupportSignal Vercel project published so the production URL remains available.
  • Return to the SupportSignal chat in v0 when you want to refine the Policy Simulator.
  • Keep future v0 edits inside the Free plan's 7 message/day limit.
  • Continue using the provided Vercel domain to avoid a custom domain purchase.

Pause - I'll come back to this later

Pause public access while keeping the Vercel project in your account. Choose this if you plan to return later but do not want the production URL serving the prototype.

  • In the Vercel dashboard, select the SupportSignal project.
  • Open Settings.
  • Stay on General.
  • Find Pause Project.
  • Select Pause Project.
  • Enter SupportSignal to confirm the project name.
  • Open your saved production URL in a new browser tab.

You should see 503 DEPLOYMENT_PAUSED. This confirms that public access is paused.

Delete - I don't want to use this again

Remove the SupportSignal Vercel project from your account. Choose this if you no longer want to keep the hosted prototype or its production URL.

  • In the Vercel dashboard, select the SupportSignal project.
  • Open Settings.
  • Stay on General.
  • Find Delete Project.
  • Select Delete.
  • Enter SupportSignal as the requested project name.
  • Enter the requested confirmation prompt.
  • Select Continue.

The SupportSignal Vercel project and its production deployments are now removed.

Nice Work!

Nice Work!

You did it! Your live SupportSignal case study now demonstrates safer support routing through five scripted scenarios.

What you learned:

  • Created SupportSignal in v0 as a clickable user journey with five observable outcomes. Published the prototype through Vercel so reviewers can test the experience from a live URL.
  • Exposed an overconfident routing failure before defining a safer intent map. Set an illustrative 70% confidence threshold. Added a critical-risk rule. Routed uncertain or unsafe cases through a human handoff.
  • Embedded a mini-PRD that communicates the product problem and scope. Added acceptance criteria plus a five-case scripted validation scorecard. Recorded evidence without presenting scripted results as live-model accuracy.
  • Secret Mission: Added a Policy Simulator that compares 50%, 70%, and 90% thresholds. It reveals the trade-off between automation coverage and human-review volume. It keeps critical-risk requests in Human Security Review at every setting.

Ready to quiz yourself?