assistant-skills/pov-doc/SKILL.md

name	description	version
pov-doc	This skill should be used when the user asks to "write a POV doc," "create a proof of value document," "POV criteria," "proof of concept criteria," "generate a POC document," or discusses creating a proof-of-value or proof-of-concept document for a Verkada customer evaluation. Generates a customer-facing POC/POV criteria document for Verkada physical security product evaluations.	1.0.0

POV Doc

Generate a proof-of-value (POV) / proof-of-concept (POC) criteria document for a Verkada customer. This document is shared with the customer to formalize the scope, success criteria, and schedule of a product evaluation.

Information Gathering

Before generating the document, gather the following from the user's notes and conversation:

1. Customer name and any relevant context (industry, size, location)
2. Which Verkada products are in scope for the POC (cameras, access control, visitor management, alarms, Command Connector, etc.)
3. Business challenge the customer faces with their current physical security setup
4. Key stakeholders (names, titles, organizations)
5. POC timeline (discovery date, install date, review dates, etc.)
6. Success criteria specific to this customer
7. Integration requirements (Azure AD, POS, third-party cameras, etc.)
8. What the customer will provide (badges, infrastructure, network, etc.)

Search ~/notes for account notes, meeting notes, and inbox items related to the customer to populate these fields. Use ripgrep to find relevant content across all note files.

Document Structure

The output document must follow this structure. Each section is required unless the user explicitly says it does not apply.

Header

• Document title: # **Verkada Proof of Concept Criteria**
• Customer logo placeholder: <!-- Image goes here: customer logo -->
• Verkada logo placeholder: <!-- Image goes here: Verkada logo -->
• Customer mission statement (if known), formatted as a blockquote: *"MISSION STATEMENT HERE"*
• Table of contents with anchor links to each numbered section

1. POC Goals and Overview

• Document Purpose - Standard boilerplate: "The document will serve as the agreement between Verkada and [Customer] as to the scope and measures of success for a proof of concept engagement to demonstrate and document the proposed physical security solution."
• Business Challenge - Summarize the customer's current pain points with their existing security infrastructure. Be specific, not generic.
• Objective - List the specific objectives of this POC. Use this opening: "Verkada will be working with [Customer] in conducting a Proof-of-Concept (POC) to demonstrate the capabilities of the Verkada Physical Security platform." Then list objectives as bullet points.

2. POC Site Design

• Describe the physical deployment plan: what doors, cameras, or locations are included
• Note any special configurations (identity sync, card format, badge compatibility, etc.)
• Reference specific Verkada product pages where appropriate (link to verkada.com product URLs)

3. Scope

Two subsections:

• Verkada will provide the following: List hardware and services by product category (Video Security, Access Control, etc.)
• [Customer] will provide the following: List what the customer is responsible for (badges, infrastructure, network, personnel)
• Optional: Discussion Items for integrations or features being evaluated but not formally in scope

4. Success Criteria

Group criteria into themed subsections with bold headings. Each criterion should be a clear, measurable statement the customer can evaluate. Common themes include:

• Unified/Scalable Platform
• AI Capabilities & Advanced Features
• Integration Capabilities (list specific third-party integrations)
• Simplified Management / Bulk Operations
• Identity Management Integration
• Hardware Compatibility
• Proactive Maintenance & Updates
• Reduction in Maintenance Costs
• Scalability Without Added Complexity

Tailor these to the customer's stated business challenge. Do not include criteria that are irrelevant to the products in scope.

5. Stakeholders

A markdown table with columns: Name, Title/Role, Organization. Populate with all known stakeholders from the account notes.

6. POC Schedule

A markdown table with columns: Activity, Start Date, End Date (optional), Required Personnel. Standard activities include: Discovery, Site Walk, Installation, Configuration, Admin Scenarios Review(s), Success Criteria Review, Executive Review, Obtain Executive Approval. Use [TBD] for dates and personnel that are not yet confirmed.

7. Next Steps

Numbered list of concrete next actions. Include any steps that have already been completed with a "(Completed)" notation.

Style Notes

• Keep verbiage general and boardroom-appropriate. Avoid colloquial phrases.
• Do not use exaggerated adjectives. Keep problem statements curt and factual.
• Do not surround words with quotation marks for emphasis.
• Use bold formatting sparingly: only for section sub-headings and table headers, not for emphasis within body text.
• Do not use em-dashes; use commas, colons, or parentheses instead.
• The document should read like a formal agreement between two organizations, not an internal memo.

Formatting Requirements

• Output valid GitHub-flavored markdown.
• Use ## for top-level sections within the document (numbered sections 1-7).
• Use bold with asterisks only for sub-headings within sections and table headers.
• Use markdown tables for Stakeholders and POC Schedule.
• Include <!-- Image goes here: description --> comments as placeholders for logos and diagrams.
• Do not include horizontal rules between sections.
• Do not wrap the output in a code block; output raw markdown.

Examples

Two example documents are provided in the examples/ folder:

• examples/City of El Paso POC Criteria.md - A completed POV document for a municipal access control evaluation
• examples/Proof of Concept Criteria - TEMPLATE.md - A template-style POV document for a retail environment

Review these examples to match tone, structure, and formatting conventions. The El Paso example shows how to write a finalized document with specific details filled in. The template example shows the structure with placeholder content for a broader product evaluation.

Output Location

Write the generated document to ~/notes/Inbox/ with the filename format [Customer Name] POC Criteria.md.