--- name: pov-doc description: 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. version: 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: `` - Verkada logo placeholder: `` - 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 `` 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`.