{ "name": "AI Revenue Workflow Dataset", "version": "2026-05-22", "description": "165 AI workflow records mapped by business function, buyer problem, baseline metric, AI role, human review point, risk boundary, deployability readiness, and pilot-readiness claim level.", "license": "Copyright AI Deployment Authority. Public citation permitted with attribution.", "claimBoundary": "Records are pilot-readiness and workflow-design records, not validated outcome benchmarks unless field evidence is separately attached.", "recordCount": 165, "sourceCount": 68, "records": [ { "id": "website-contact-form-routing", "name": "Website Contact Form Routing", "url": "/workflow-library/website-contact-form-routing", "businessFunction": "Lead capture", "department": "Marketing Ops", "revenueLeak": "Lead Capture", "kpi": "Qualified Lead Increase", "workflowType": "Routing", "riskLevel": "Low", "ownerRole": "Marketing Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 99, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Generic contact forms collect messy demand: sales inquiries, support issues, job seekers, vendors, existing customers, spam, and partner notes arrive through the same pipe. If the form record cannot be classified and assigned cleanly, response speed does not matter because the wrong person owns the wrong conversation.", "economicLogic": "The value is recovered attention. Clean routing reduces ignored sales inquiries, protects support and customer requests from sales automation, and gives marketing a better read on which pages create real commercial demand versus operational noise.", "baselineMetric": "contact_form_assignable_lead_rate", "baselineMetricDescription": "Share of website contact submissions that can be classified, deduplicated, matched to a customer or account if relevant, assigned to the correct owner, and given a next action without manual detective work.", "sourceSystem": "Website form submissions, CRM contact and company records, routing rules, suppression lists, support inbox", "collectionMethod": "Review each form submission for source page, request type, consent, duplicate match, account or customer status, assigned owner, and final disposition.", "leadingIndicators": [ "classification confidence", "duplicate match rate", "unassigned submission count", "existing-customer exception rate" ], "laggingIndicators": [ "sales accepted form rate", "support misroute rate", "time to correct owner" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "The workflow starts when a website form, landing page form, chat handoff, or inbound inquiry creates a new lead record that needs routing.", "requiredEvidence": [ "form submission details", "service or product requested", "location, territory, or market", "source page or campaign tag", "contact information", "consent status", "duplicate inquiry history", "routing rules and owner list" ], "aiRole": "AI classifies the submission, checks for duplicate or existing-customer context, recommends owner and path, summarizes the request, and flags consent or territory problems. It should not create customer-facing outreach until the record is safely assignable.", "humanReviewPoint": "Marketing ops or sales ops reviews low-confidence classification, duplicate conflicts, existing-customer requests, regulated language, and any routing rule that would change ownership or create a sales task.", "evidenceBoundary": "The evidence supports routing criteria, automation mechanics, and risk-managed review. It does not prove that every contact form submission is revenue-bearing.", "stopRules": [ "The workflow treats all contact submissions as leads.", "Duplicate or existing-account context is lost at intake." ], "notReadyIf": [ "The form does not capture source page.", "CRM duplicate matching is disabled or ignored.", "Request categories are not agreed." ], "pilotDuration": "21 days", "pilotSampleSize": "All website contact submissions from the top 5 commercial pages, minimum 75 submissions", "pilotOwner": "Demand generation manager", "pilotSuccessThreshold": "At least 85% of non-spam submissions are classified, assigned, and dispositioned with fewer than 5% confirmed sales/support misroutes.", "workflowDistinction": "Website contact form routing is an intake classification workflow. It determines whether a submission is a sales lead, support issue, customer request, vendor note, spam item, or exception before response workflows act on it. That makes it upstream of speed-to-lead and more concerned with correctness than speed alone.", "uniqueDataTest": "Sample contact submissions from the main website form and verify source page, request category, consent field, duplicate match, lifecycle status, assigned owner, first action, and disposition. The test should expose every case where a sales task was created from a non-sales request.", "duplicateGuard": "Keep this separate from landing page lead intake. Contact form routing handles broad, mixed-purpose demand from general pages; landing page intake preserves campaign, offer, and audience context from a specific acquisition path.", "sourceRefs": [ "hbr-online-leads", "hubspot-lead-routing", "hubspot-sales-automation", "nist-ai-rmf" ] }, { "id": "landing-page-lead-intake", "name": "Landing Page Lead Intake", "url": "/workflow-library/landing-page-lead-intake", "businessFunction": "Lead capture", "department": "Sales", "revenueLeak": "Lead Capture", "kpi": "Qualified Lead Increase", "workflowType": "Workflow Support", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Landing pages often create leads without preserving the reason the buyer converted. The CRM receives a name and email, but loses the offer, audience, ad group, UTM trail, promise, and intended follow-up path that made the response commercially meaningful.", "economicLogic": "The economic value is attribution and follow-up fit. When offer context survives intake, sales and marketing can separate demo demand from research interest, reduce poor handoffs, and learn which pages create qualified pipeline rather than raw lead volume.", "baselineMetric": "landing_page_offer_context_completion_rate", "baselineMetricDescription": "Share of landing page conversions with offer, campaign, UTM/source, audience, consent, CRM campaign, owner path, and intended follow-up motion captured before sales or nurture begins.", "sourceSystem": "Landing page platform, Google Ads lead forms, marketing automation, CRM campaigns, routing rules", "collectionMethod": "Trace each conversion from landing page or ad form through marketing automation, CRM campaign membership, owner assignment, and first follow-up disposition.", "leadingIndicators": [ "UTM capture rate", "offer field completion", "CRM campaign sync rate", "wrong-path correction count" ], "laggingIndicators": [ "campaign qualified lead rate", "sales accepted campaign leads", "landing-page sourced opportunity rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A visitor submits a landing page form, gated offer form, paid campaign form, quote request, or consultation request.", "requiredEvidence": [ "form submission fields", "landing page URL and offer name", "UTM parameters, referrer, and campaign source", "contact information and consent status", "company, service need, location, or market", "duplicate lead or customer history", "routing rules and owner availability", "approved first-response language" ], "aiRole": "AI checks the conversion record for campaign, source, audience, offer, consent, and fit, then recommends sales, nurture, partner, or reject path with a short reason. It should not erase source data or infer intent from a form fill alone.", "humanReviewPoint": "Demand generation reviews new offers, low-confidence intent classification, paid-source anomalies, and any rule that sends campaign leads directly to sales or suppresses them from follow-up.", "evidenceBoundary": "Sources support lead-form integration, routing, and automation mechanics. They do not prove that a specific landing page or offer will create qualified pipeline without campaign-level measurement.", "stopRules": [ "Offer context is overwritten by generic lead source fields.", "Low-intent conversions are pushed directly to sales." ], "notReadyIf": [ "UTM or campaign fields are not captured.", "Offer taxonomy is missing.", "Marketing and sales disagree on which offers create sales tasks." ], "pilotDuration": "30 days", "pilotSampleSize": "One active campaign or at least 100 landing page conversions across related offers", "pilotOwner": "Demand generation manager", "pilotSuccessThreshold": "At least 90% of conversions carry offer, source, audience, consent, campaign, and path fields into CRM; fewer than 5% need manual source repair.", "workflowDistinction": "Landing page lead intake is about campaign-context preservation. Its record should explain what offer the buyer responded to, which audience was targeted, and which follow-up path the offer implies. It is not broad contact-form triage and it is not merely fast response.", "uniqueDataTest": "Choose one active landing page campaign and trace conversions from click or form event to CRM record. Verify UTM fields, campaign membership, offer type, consent, owner path, follow-up motion, and sales disposition. Any lead without offer context fails the test.", "duplicateGuard": "Keep this separate from download-form lead capture and website contact routing. Landing page intake can include demo, quote, event, and paid-search offers; the defining asset is source and offer context, not the form component.", "sourceRefs": [ "google-lead-form-assets", "hubspot-sales-automation", "hubspot-lead-routing" ] }, { "id": "chatbot-lead-capture", "name": "Chatbot Lead Capture", "url": "/workflow-library/chatbot-lead-capture", "businessFunction": "Lead capture", "department": "Sales", "revenueLeak": "Lead Capture", "kpi": "Qualified Lead Increase", "workflowType": "Routing", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Chatbot lead capture stays weak when chat transcripts become leads without enough qualification, consent, contact data, source page, support-versus-sales routing, and transcript-risk review. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making chatbot lead capture measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "chat_lead_handoff_acceptance_rate", "baselineMetricDescription": "Share of chat-created leads accepted by sales with qualification fields, transcript summary, consent status, source page, owner, and exception decision.", "sourceSystem": "chat platform, CRM, consent field, routing rules, transcript archive, sales acceptance log", "collectionMethod": "Sample chat handoffs and compare qualification data, transcript summary, owner assignment, accepted/rejected status, and low-confidence exceptions.", "leadingIndicators": [ "conversation summary completeness", "contact capture rate", "consent capture rate", "handoff exception rate" ], "laggingIndicators": [ "chat-assisted meeting rate", "qualified opportunity rate", "sales accepted lead rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A visitor starts a website chat, asks a sales question, requests help choosing a service, shares contact details, or asks for human follow-up.", "requiredEvidence": [ "chat transcript and conversation path", "visitor question or stated need", "contact details and consent status", "page URL, source, and campaign context", "handoff signal or unresolved question", "qualification fields collected during the chat", "existing lead or customer match", "approved handoff and response language" ], "aiRole": "AI summarizes chat intent, extracts qualification fields, checks support-versus-sales routing, identifies missing contact or consent data, and prepares handoff briefs.", "humanReviewPoint": "Intake reviews vague intent, consent uncertainty, support issues, existing-customer conflicts, high-value inquiries, and any transcript language that creates a promise.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI treats a support or complaint transcript as a qualified sales lead.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Chat platform does not store transcript, qualification fields, consent, or CRM handoff status.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 150 chat sessions that create or update a CRM lead", "pilotOwner": "Sales development operations lead", "pilotSuccessThreshold": "85% of chat handoffs are accepted by the assigned owner and 100% of low-confidence or consent exceptions receive human review.", "workflowDistinction": "Chatbot lead capture handles turning chat transcripts into accepted sales handoffs with transcript and consent evidence. The audit sample checks review each chat lead for transcript, source page, qualification fields, consent, owner, sales/support route, and acceptance status. Keep separate from website form routing and inbound lead qualification. Chat capture starts with conversation evidence and transcript risk, not static form fields.", "uniqueDataTest": "Review each chat lead for transcript, source page, qualification fields, consent, owner, sales/support route, and acceptance status. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from website form routing and inbound lead qualification. Chat capture starts with conversation evidence and transcript risk, not static form fields.", "sourceRefs": [ "hubspot-sales-automation", "hubspot-lead-routing", "nist-ai-rmf" ] }, { "id": "missed-call-lead-capture", "name": "Missed Call Lead Capture", "url": "/workflow-library/missed-call-lead-capture", "businessFunction": "Lead capture", "department": "Sales", "revenueLeak": "Lead Capture", "kpi": "Qualified Lead Increase", "workflowType": "Workflow Support", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Missed calls often represent invisible demand. Phone logs show a number and timestamp, but the CRM may not know whether the caller is a prospect, customer, vendor, duplicate account, emergency request, or spam. Without identity matching, callbacks become random and hard to measure.", "economicLogic": "The value is recovering demand that never became a lead record. A good pilot should connect missed-call events to identity, account context, callback ownership, and disposition so the team can see which missed calls were recoverable opportunities.", "baselineMetric": "missed_call_recovery_disposition_rate", "baselineMetricDescription": "Share of missed inbound calls that are matched to a contact, account, or new lead path, assigned a callback owner, attempted, and dispositioned with outcome and reason.", "sourceSystem": "Phone system logs, CRM contacts and companies, call tracking numbers, sales engagement tasks, messaging consent logs", "collectionMethod": "Match missed-call events to CRM identity, source number, call tracking campaign, callback task, attempt timestamp, connected status, and disposition.", "leadingIndicators": [ "call identity match rate", "callback task creation rate", "first callback attempt time", "unknown caller exception rate" ], "laggingIndicators": [ "missed-call connection rate", "missed-call qualified lead rate", "recovered opportunity count" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "An inbound sales, service, or office call is missed, abandoned, received after hours, or sent to voicemail.", "requiredEvidence": [ "caller ID and phone number", "call timestamp and business-hours status", "voicemail recording or transcription", "call source, campaign, or tracking number", "existing customer or lead match", "location, service line, and urgency clues", "callback owner and availability", "approved call-back or SMS language" ], "aiRole": "AI matches missed-call numbers to CRM and call-tracking context, prepares callback tasks, flags customer or support conflicts, and summarizes voicemail where available. It does not decide legal contact permission or replace the human callback.", "humanReviewPoint": "Sales ops or front-office lead reviews unknown high-value callers, customer conflicts, repeat missed calls, consent-sensitive SMS fallback, and any call record that could create a service promise.", "evidenceBoundary": "The sources support lead response urgency and messaging guardrails. The workflow's commercial value depends on call mix, match quality, and callback execution.", "stopRules": [ "The workflow calls back existing customers as if they were new prospects.", "Unknown callers are overclassified as commercial demand." ], "notReadyIf": [ "Phone logs cannot be exported.", "CRM phone matching is unreliable.", "Callback dispositions are not logged." ], "pilotDuration": "30 days", "pilotSampleSize": "All missed calls from sales or website tracking numbers, minimum 100 call events", "pilotOwner": "Sales operations manager", "pilotSuccessThreshold": "At least 80% of non-spam missed calls receive identity match or new-lead path, callback owner, callback attempt, and disposition within the pilot SLA.", "workflowDistinction": "Missed-call capture starts from a failed inbound phone event. Its first job is identity matching and recovery disposition, not a generic lead response. That separates it from instant callback, where the buyer explicitly requested a callback through a form or button.", "uniqueDataTest": "Pull phone-system missed calls and match them against CRM, call tracking, voicemail, callback task, first attempt timestamp, connected status, and final disposition. The workflow is credible only if non-sales calls and existing customers are separated from new demand.", "duplicateGuard": "Do not merge this with instant callback or after-hours response. Missed-call capture is a phone-log recovery workflow with identity uncertainty and callback disposition as the core data test.", "sourceRefs": [ "hbr-online-leads", "twilio-messaging-policy", "hubspot-sales-automation" ] }, { "id": "event-lead-capture", "name": "Event Lead Capture", "url": "/workflow-library/event-lead-capture", "businessFunction": "Lead capture", "department": "Sales", "revenueLeak": "Lead Capture", "kpi": "Qualified Lead Increase", "workflowType": "Follow-Up", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Event Lead Capture is weak when lead capture teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Event Lead Capture comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Demand generation manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "event_lead_capture_review_ready_rate", "baselineMetricDescription": "Share of event lead capture records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce", "collectionMethod": "Sample event lead capture records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A badge scan, QR form, booth note, event app submission, meeting request, or session interaction creates a new event lead.", "requiredEvidence": [ "Contact and company information", "Event name, booth, session, campaign, or source", "Conversation note, interest area, and stated need", "Consent status and communication preference", "Lead rating, timeline, next step promised, and owner", "Duplicate CRM match and account context" ], "aiRole": "AI prepares the event lead capture record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Demand generation manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Demand generation manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances event lead capture from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Event Lead Capture does not have stable source records, owner fields, or status fields to sample.", "No accountable lead capture owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 event lead capture records, or all records from one lead capture segment over 45 days", "pilotOwner": "Demand generation manager", "pilotSuccessThreshold": "At least 90% of sampled event lead capture records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Event Lead Capture is the lead capture control for event_lead_capture_review_ready_rate, using hubspot-sales-automation, hubspot-lead-routing, salesforce-lead-management as its source boundary and the workflow terms event, lead, capture. Its audit packet should carry eventleadcaptureSourceRecord, eventleadcaptureOwnerDecision, eventleadcaptureExceptionQueue, eventleadcaptureReviewOutcome, and eventleadcaptureScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Demand generation manager, exception status, and a safe next action for event lead capture specifically.", "uniqueDataTest": "Audit 100 event lead capture records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep event lead capture separate from adjacent lead capture workflows by requiring event_lead_capture_review_ready_rate, the Demand generation manager review point, and the source boundary hubspot-sales-automation, hubspot-lead-routing, salesforce-lead-management. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-sales-automation", "hubspot-lead-routing", "salesforce-lead-management" ] }, { "id": "download-form-lead-capture", "name": "Download Form Lead Capture", "url": "/workflow-library/download-form-lead-capture", "businessFunction": "Lead capture", "department": "Sales", "revenueLeak": "Lead Capture", "kpi": "Qualified Lead Increase", "workflowType": "Follow-Up", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Download form lead capture stays weak when content downloads are treated as sales demand even when the asset topic, fit, repeat engagement, consent, and intent threshold are unclear. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making download form lead capture measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "download_lead_path_accuracy_rate", "baselineMetricDescription": "Share of download leads assigned to sales, nurture, suppress, or review path with asset topic, fit, engagement, consent, and outcome reason.", "sourceSystem": "marketing automation, CRM, form tool, content taxonomy, lead scoring rules, consent fields", "collectionMethod": "Compare download events to assigned path, sales acceptance, nurture enrollment, rejection reason, and later conversion outcome.", "leadingIndicators": [ "offer-to-path mapping rate", "required-field completeness", "repeat engagement count", "sales exception rate" ], "laggingIndicators": [ "MQL-to-SQL conversion rate", "nurture reply rate", "meeting booked rate from download leads" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A visitor submits a gated content form, guide download, checklist request, template request, or resource library form.", "requiredEvidence": [ "Contact, company, role, and email domain", "Downloaded asset, topic, page, campaign, and UTM source", "Consent status and communication preference", "Company fit, enrichment data, and existing CRM match", "Prior engagement and related content history", "Routing rules for nurture vs sales handoff" ], "aiRole": "AI classifies download intent using asset type, topic, account fit, repeat engagement, consent, and existing CRM status, then recommends sales, nurture, suppress, or review path.", "humanReviewPoint": "Marketing or sales ops reviews high-value accounts, unclear consent, suspicious data, existing-customer conflicts, and any path that triggers sales outreach.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI sends low-intent researchers to sales or contacts people without valid consent.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Content taxonomy, consent status, CRM status, or engagement history is missing.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 300 gated-content downloads from one content family over 45 days", "pilotOwner": "Marketing operations manager", "pilotSuccessThreshold": "90% of downloads receive a documented path and sales rejection from download-sourced leads stays below 15% during the pilot.", "workflowDistinction": "Download form lead capture handles classifying content-download intent into sales, nurture, suppress, or review paths. The audit sample checks map each download to asset topic, buyer stage, fit, repeat engagement, consent, crm status, assigned path, and sales disposition. Keep separate from landing-page lead intake and inbound lead qualification. Download capture is content-intent classification, not broad campaign intake or final sales qualification.", "uniqueDataTest": "Map each download to asset topic, buyer stage, fit, repeat engagement, consent, CRM status, assigned path, and sales disposition. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from landing-page lead intake and inbound lead qualification. Download capture is content-intent classification, not broad campaign intake or final sales qualification.", "sourceRefs": [ "hubspot-sales-automation", "hubspot-lead-routing" ] }, { "id": "social-inquiry-lead-capture", "name": "Social Inquiry Lead Capture", "url": "/workflow-library/social-inquiry-lead-capture", "businessFunction": "Lead capture", "department": "Sales", "revenueLeak": "Lead Capture", "kpi": "Qualified Lead Increase", "workflowType": "Follow-Up", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Social Inquiry Lead Capture is weak when lead capture teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Social Inquiry Lead Capture comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Demand generation manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "social_inquiry_lead_capture_review_ready_rate", "baselineMetricDescription": "Share of social inquiry lead capture records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, risk review notes", "collectionMethod": "Sample social inquiry lead capture records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "A social DM, comment, mention, profile inquiry, ad reply, or public thread indicates possible interest or need.", "requiredEvidence": [ "Platform, message, thread, and timestamp", "Profile, company, identity match, and prior interactions", "Topic, urgency, sentiment, and service fit", "Consent or permission to move channels", "Public vs private reply context", "Owner, routing rule, and CRM match" ], "aiRole": "AI prepares the social inquiry lead capture record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Demand generation manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Demand generation manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances social inquiry lead capture from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Social Inquiry Lead Capture does not have stable source records, owner fields, or status fields to sample.", "No accountable lead capture owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 social inquiry lead capture records, or all records from one lead capture segment over 45 days", "pilotOwner": "Demand generation manager", "pilotSuccessThreshold": "At least 90% of sampled social inquiry lead capture records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Social Inquiry Lead Capture is the lead capture control for social_inquiry_lead_capture_review_ready_rate, using hubspot-sales-automation, nist-ai-rmf as its source boundary and the workflow terms social, inquiry, lead, capture. Its audit packet should carry socialinquiryleadcaptureSourceRecord, socialinquiryleadcaptureOwnerDecision, socialinquiryleadcaptureExceptionQueue, socialinquiryleadcaptureReviewOutcome, and socialinquiryleadcaptureScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Demand generation manager, exception status, and a safe next action for social inquiry lead capture specifically.", "uniqueDataTest": "Audit 100 social inquiry lead capture records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep social inquiry lead capture separate from adjacent lead capture workflows by requiring social_inquiry_lead_capture_review_ready_rate, the Demand generation manager review point, and the source boundary hubspot-sales-automation, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-sales-automation", "nist-ai-rmf" ] }, { "id": "referral-form-intake", "name": "Referral Form Intake", "url": "/workflow-library/referral-form-intake", "businessFunction": "Lead capture", "department": "Sales", "revenueLeak": "Lead Capture", "kpi": "Qualified Lead Increase", "workflowType": "Follow-Up", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Referral Form Intake is weak when lead capture teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Referral Form Intake comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Demand generation manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "referral_form_intake_review_ready_rate", "baselineMetricDescription": "Share of referral form intake records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce, risk review notes", "collectionMethod": "Sample referral form intake records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A customer, partner, employee, or advocate submits a referral form or sends a referral message.", "requiredEvidence": [ "Referrer name, relationship, and contact details", "Referred person, company, role, and contact details", "Permission to contact and preferred introduction path", "Referral reason, need, urgency, and fit evidence", "Reward, attribution, partner, or source rules", "Duplicate account/contact match and assigned owner" ], "aiRole": "AI prepares the referral form intake record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Demand generation manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Demand generation manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances referral form intake from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Referral Form Intake does not have stable source records, owner fields, or status fields to sample.", "No accountable lead capture owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 referral form intake records, or all records from one lead capture segment over 45 days", "pilotOwner": "Demand generation manager", "pilotSuccessThreshold": "At least 90% of sampled referral form intake records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Referral Form Intake is the lead capture control for referral_form_intake_review_ready_rate, using hubspot-lead-routing, salesforce-lead-management, nist-ai-rmf as its source boundary and the workflow terms referral, form, intake. Its audit packet should carry referralformintakeSourceRecord, referralformintakeOwnerDecision, referralformintakeExceptionQueue, referralformintakeReviewOutcome, and referralformintakeScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Demand generation manager, exception status, and a safe next action for referral form intake specifically.", "uniqueDataTest": "Audit 100 referral form intake records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep referral form intake separate from adjacent lead capture workflows by requiring referral_form_intake_review_ready_rate, the Demand generation manager review point, and the source boundary hubspot-lead-routing, salesforce-lead-management, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-lead-routing", "salesforce-lead-management", "nist-ai-rmf" ] }, { "id": "inbound-lead-qualification", "name": "Inbound Lead Qualification", "url": "/workflow-library/inbound-lead-qualification", "businessFunction": "Lead qualification", "department": "Sales", "revenueLeak": "Poor Fit Leads", "kpi": "Sales Time Saved", "workflowType": "Routing", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Inbound qualification becomes political when marketing celebrates lead volume and sales sees inconsistent fit. Without clear disposition evidence, every rejected lead looks like a sales problem and every accepted lead lacks feedback that could improve routing, nurture, or acquisition spend.", "economicLogic": "The value is agreement on what deserves sales action. A qualification workflow should reduce noisy handoffs, expose rejection reasons, and show whether fit, intent, urgency, and source signals predict sales acceptance and opportunity creation.", "baselineMetric": "inbound_lead_sales_acceptance_evidence_rate", "baselineMetricDescription": "Share of inbound leads with qualification reason, fit and intent evidence, sales accepted/rejected status, rejection reason when relevant, and downstream opportunity or nurture path captured.", "sourceSystem": "CRM leads, marketing automation, lead scoring rules, sales dispositions, campaign/source records", "collectionMethod": "Compare AI qualification recommendation to sales acceptance, rejection reason, recycle/nurture path, opportunity creation, and source or campaign context.", "leadingIndicators": [ "qualification reason coverage", "sales rejection reason rate", "recycle path assignment", "low-confidence review count" ], "laggingIndicators": [ "sales accepted lead rate", "MQL-to-SQL conversion", "opportunity creation rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A new inbound inquiry, demo request, consultation request, referral, form submission, chat handoff, or sales email enters the pipeline.", "requiredEvidence": [ "lead source and conversion context", "company profile and market fit", "role, authority, and buying committee clues", "stated problem or desired outcome", "urgency, timing, and budget or ability-to-buy signal", "past activity, duplicate history, and existing account status", "qualification rubric and disqualification reasons", "sales owner rules and acceptance criteria" ], "aiRole": "AI reads fit, intent, source, company, activity, and prior CRM context, then recommends sales-ready, nurture, recycle, disqualify, or review with a reason. It does not override sales acceptance or hide the evidence behind a score.", "humanReviewPoint": "Revenue operations reviews low-confidence recommendations, rule changes, rejection clusters, enterprise exceptions, and any workflow that would suppress or accelerate sales follow-up.", "evidenceBoundary": "CRM and routing sources support lead status, source, and automation mechanics. Qualification accuracy must be tested against sales acceptance and opportunity outcomes.", "stopRules": [ "AI over-qualifies leads from weak fit signals because engagement looks strong.", "Sales rejects leads without feedback, so the model cannot improve." ], "notReadyIf": [ "Sales acceptance status is not captured.", "Rejection reasons are missing.", "Marketing and sales have no shared fit/intent criteria." ], "pilotDuration": "30 days", "pilotSampleSize": "First 200 inbound leads from the main commercial sources or one complete MQL cohort", "pilotOwner": "Revenue operations manager", "pilotSuccessThreshold": "At least 90% of leads receive a disposition with reason; sales rejection reasons are captured for 85% of rejected leads and reviewed before changing qualification rules.", "workflowDistinction": "Inbound lead qualification is the sales-readiness bridge. It translates fit, intent, urgency, and source evidence into a disposition that sales can accept or reject with feedback. It is broader than priority routing and more explainable than a score alone.", "uniqueDataTest": "Take one inbound cohort and compare AI-recommended disposition to sales acceptance, rejection reason, nurture assignment, opportunity creation, and source quality. The workflow passes only if rejection feedback is structured enough to update rules.", "duplicateGuard": "Keep this separate from lead scoring and priority routing. Lead scoring produces a signal; priority routing allocates attention; inbound qualification creates the disposition and feedback loop between marketing and sales.", "sourceRefs": [ "hubspot-lead-routing", "hubspot-sales-automation", "salesforce-lead-management" ] }, { "id": "website-demo-request-qualification", "name": "Website Demo Request Qualification", "url": "/workflow-library/website-demo-request-qualification", "businessFunction": "Lead qualification", "department": "Sales", "revenueLeak": "Poor Fit Leads", "kpi": "Sales Time Saved", "workflowType": "Routing", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Demo requests feel high-intent, but calendar time is still easy to waste. A form can hide poor fit, student/vendor requests, existing-customer issues, wrong product interest, or an account that should route to a named owner instead of a round-robin calendar.", "economicLogic": "The value is calendar quality. The workflow should protect rep time, improve buyer handoff, and make sure high-fit demo requests book with the right context instead of creating a generic meeting that sales has to requalify from scratch.", "baselineMetric": "demo_request_calendar_quality_rate", "baselineMetricDescription": "Share of demo requests that are qualified, matched to account or owner when relevant, routed to the right calendar path, and dispositioned with show/no-show and opportunity outcome.", "sourceSystem": "Website demo form, CRM accounts and leads, calendar routing tool, sales engagement tasks, opportunity records", "collectionMethod": "Trace demo form answers to account match, routing path, calendar booking, meeting attendance, sales disposition, and opportunity creation.", "leadingIndicators": [ "calendar route accuracy", "account-owner match rate", "poor-fit booking rate", "demo no-show rate" ], "laggingIndicators": [ "demo-to-opportunity rate", "sales accepted demo rate", "meeting show rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A visitor submits a demo request, books a demo, starts but abandons a demo form, or requests a sales conversation through the website.", "requiredEvidence": [ "Name, work email, company, role, and website", "Use case, company size, industry, source page, and UTM data", "Enrichment data, account match, and duplicate status", "Booking status, preferred time, and no-show risk signals", "Routing rules for owner, calendar, segment, or nurture", "Disqualification and review rules" ], "aiRole": "AI reviews demo answers, source page, account match, segment, ownership, and fit signals, then recommends direct booking, owner route, qualify-first, nurture, or exception review. It should explain the route rather than silently changing calendar access.", "humanReviewPoint": "Sales ops reviews low-confidence demo requests, enterprise or existing-customer conflicts, poor-fit rules, and any change to calendar routing logic. Reps still own qualification on the live call.", "evidenceBoundary": "Routing and automation sources support the mechanics. Demo quality and opportunity impact require pilot measurement by source, segment, and meeting outcome.", "stopRules": [ "The workflow blocks or delays legitimate high-intent buyers with over-screening.", "Existing accounts or enterprise leads route to the wrong calendar." ], "notReadyIf": [ "Demo form lacks qualification fields.", "Account ownership cannot be matched.", "Meeting outcomes are not logged." ], "pilotDuration": "30 days", "pilotSampleSize": "First 100 demo requests or all demo requests from one product line for 30 days", "pilotOwner": "Sales operations manager", "pilotSuccessThreshold": "At least 90% of demo requests have qualification reason, account match, route path, meeting status, and sales disposition; poor-fit booked demos fall below 10%.", "workflowDistinction": "Website demo request qualification is a calendar-quality workflow for high-intent website demand. It differs from general inbound qualification because the immediate decision is whether and where to book a meeting, not just whether a lead is sales-ready.", "uniqueDataTest": "Trace demo requests from form submission to CRM match, route decision, calendar booking, meeting status, sales disposition, and opportunity creation. The workflow is ready if poor-fit demos, wrong-owner bookings, and unexplained denials are visible.", "duplicateGuard": "Do not merge with consultation screening. Demo requests usually imply product evaluation and calendar routing; consultation requests often require expert fit, scope, and service qualification before booking.", "sourceRefs": [ "hubspot-lead-routing", "hubspot-sales-automation" ] }, { "id": "consultation-request-screening", "name": "Consultation Request Screening", "url": "/workflow-library/consultation-request-screening", "businessFunction": "Lead qualification", "department": "Sales", "revenueLeak": "Poor Fit Leads", "kpi": "Sales Time Saved", "workflowType": "Routing", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Consultation Request Screening is weak when lead qualification teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Consultation Request Screening comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales development manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "consultation_request_screening_review_ready_rate", "baselineMetricDescription": "Share of consultation request screening records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, risk review notes", "collectionMethod": "Sample consultation request screening records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A website consultation form, calendar request, email inquiry, or paid consultation request enters the intake queue.", "requiredEvidence": [ "Contact, company, role, and source page", "Problem, desired outcome, timeline, and urgency", "Budget range, decision-maker status, and service fit", "Consent, communication preference, and booking status", "Existing CRM record and prior interactions", "Routing rules and disqualification criteria" ], "aiRole": "AI prepares the consultation request screening record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales development manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales development manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances consultation request screening from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Consultation Request Screening does not have stable source records, owner fields, or status fields to sample.", "No accountable lead qualification owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 consultation request screening records, or all records from one lead qualification segment over 45 days", "pilotOwner": "Sales development manager", "pilotSuccessThreshold": "At least 90% of sampled consultation request screening records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Consultation Request Screening is the lead qualification control for consultation_request_screening_review_ready_rate, using hubspot-sales-automation, nist-ai-rmf as its source boundary and the workflow terms consultation, request, screening. Its audit packet should carry consultationrequestscreeningSourceRecord, consultationrequestscreeningOwnerDecision, consultationrequestscreeningExceptionQueue, consultationrequestscreeningReviewOutcome, and consultationrequestscreeningScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales development manager, exception status, and a safe next action for consultation request screening specifically.", "uniqueDataTest": "Audit 100 consultation request screening records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep consultation request screening separate from adjacent lead qualification workflows by requiring consultation_request_screening_review_ready_rate, the Sales development manager review point, and the source boundary hubspot-sales-automation, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-sales-automation", "nist-ai-rmf" ] }, { "id": "b2b-lead-scoring", "name": "B2B Lead Scoring", "url": "/workflow-library/b2b-lead-scoring", "businessFunction": "Lead qualification", "department": "Sales", "revenueLeak": "Poor Fit Leads", "kpi": "Sales Time Saved", "workflowType": "Scoring", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "B2B Lead Scoring is weak when lead qualification teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of B2B Lead Scoring comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales development manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "b2b_lead_scoring_review_ready_rate", "baselineMetricDescription": "Share of b2b lead scoring records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce", "collectionMethod": "Sample b2b lead scoring records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "The workflow starts when a new inbound lead, demo request, consultation request, enrichment update, or high-intent engagement signal needs qualification.", "requiredEvidence": [ "company name and domain", "industry or service category", "company size or revenue range", "buyer role or seniority", "stated need or form response", "source and campaign", "engagement history", "negative-fit criteria", "sales acceptance rules" ], "aiRole": "AI prepares the b2b lead scoring record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales development manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales development manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances b2b lead scoring from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "B2B Lead Scoring does not have stable source records, owner fields, or status fields to sample.", "No accountable lead qualification owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 b2b lead scoring records, or all records from one lead qualification segment over 45 days", "pilotOwner": "Sales development manager", "pilotSuccessThreshold": "At least 90% of sampled b2b lead scoring records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "B2B Lead Scoring is the lead qualification control for b2b_lead_scoring_review_ready_rate, using hubspot-lead-routing, hubspot-sales-automation, salesforce-lead-management as its source boundary and the workflow terms b2b, lead, scoring. Its audit packet should carry b2bleadscoringSourceRecord, b2bleadscoringOwnerDecision, b2bleadscoringExceptionQueue, b2bleadscoringReviewOutcome, and b2bleadscoringScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales development manager, exception status, and a safe next action for b2b lead scoring specifically.", "uniqueDataTest": "Audit 100 b2b lead scoring records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep b2b lead scoring separate from adjacent lead qualification workflows by requiring b2b_lead_scoring_review_ready_rate, the Sales development manager review point, and the source boundary hubspot-lead-routing, hubspot-sales-automation, salesforce-lead-management. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-lead-routing", "hubspot-sales-automation", "salesforce-lead-management" ] }, { "id": "local-service-lead-qualification", "name": "Local Service Lead Qualification", "url": "/workflow-library/local-service-lead-qualification", "businessFunction": "Lead qualification", "department": "Sales", "revenueLeak": "Poor Fit Leads", "kpi": "Sales Time Saved", "workflowType": "Review", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Local Service Lead Qualification is weak when lead qualification teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Local Service Lead Qualification comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales development manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "local_service_lead_qualification_review_ready_rate", "baselineMetricDescription": "Share of local service lead qualification records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot", "collectionMethod": "Sample local service lead qualification records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A form, call, SMS, chat, or missed-call response creates a new local service inquiry.", "requiredEvidence": [ "Name, phone, address or service area, and contact permission", "Service needed, job type, urgency, and preferred timing", "Photos, description, access notes, and property or site details", "Existing customer or duplicate record", "Service-area rules, availability, and minimum job criteria", "Safety, warranty, and pricing exception rules" ], "aiRole": "AI prepares the local service lead qualification record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales development manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales development manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances local service lead qualification from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Local Service Lead Qualification does not have stable source records, owner fields, or status fields to sample.", "No accountable lead qualification owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 local service lead qualification records, or all records from one lead qualification segment over 45 days", "pilotOwner": "Sales development manager", "pilotSuccessThreshold": "At least 90% of sampled local service lead qualification records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Local Service Lead Qualification is the lead qualification control for local_service_lead_qualification_review_ready_rate, using hbr-online-leads, hubspot-lead-routing as its source boundary and the workflow terms local, service, lead, qualification. Its audit packet should carry localserviceleadqualificationSourceRecord, localserviceleadqualificationOwnerDecision, localserviceleadqualificationExceptionQueue, localserviceleadqualificationReviewOutcome, and localserviceleadqualificationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales development manager, exception status, and a safe next action for local service lead qualification specifically.", "uniqueDataTest": "Audit 100 local service lead qualification records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep local service lead qualification separate from adjacent lead qualification workflows by requiring local_service_lead_qualification_review_ready_rate, the Sales development manager review point, and the source boundary hbr-online-leads, hubspot-lead-routing. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hbr-online-leads", "hubspot-lead-routing" ] }, { "id": "agency-prospect-qualification", "name": "Agency Prospect Qualification", "url": "/workflow-library/agency-prospect-qualification", "businessFunction": "Lead qualification", "department": "Sales", "revenueLeak": "Poor Fit Leads", "kpi": "Sales Time Saved", "workflowType": "Review", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Agency Prospect Qualification is weak when lead qualification teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Agency Prospect Qualification comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales development manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "agency_prospect_qualification_review_ready_rate", "baselineMetricDescription": "Share of agency prospect qualification records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, risk review notes", "collectionMethod": "Sample agency prospect qualification records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A prospect submits an agency inquiry, books a discovery call, asks for a proposal, or requests strategy help.", "requiredEvidence": [ "Company, role, service need, and source", "Goal, problem, timeline, and success criteria", "Budget range, decision-maker status, and buying process", "Prior agency history, expectations, and requested scope", "Red flags, speculative work requests, and communication notes", "Minimum-fit rules and proposal eligibility criteria" ], "aiRole": "AI prepares the agency prospect qualification record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales development manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales development manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances agency prospect qualification from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Agency Prospect Qualification does not have stable source records, owner fields, or status fields to sample.", "No accountable lead qualification owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 agency prospect qualification records, or all records from one lead qualification segment over 45 days", "pilotOwner": "Sales development manager", "pilotSuccessThreshold": "At least 90% of sampled agency prospect qualification records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Agency Prospect Qualification is the lead qualification control for agency_prospect_qualification_review_ready_rate, using hubspot-sales-automation, nist-ai-rmf as its source boundary and the workflow terms agency, prospect, qualification. Its audit packet should carry agencyprospectqualificationSourceRecord, agencyprospectqualificationOwnerDecision, agencyprospectqualificationExceptionQueue, agencyprospectqualificationReviewOutcome, and agencyprospectqualificationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales development manager, exception status, and a safe next action for agency prospect qualification specifically.", "uniqueDataTest": "Audit 100 agency prospect qualification records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep agency prospect qualification separate from adjacent lead qualification workflows by requiring agency_prospect_qualification_review_ready_rate, the Sales development manager review point, and the source boundary hubspot-sales-automation, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-sales-automation", "nist-ai-rmf" ] }, { "id": "partner-lead-qualification", "name": "Partner Lead Qualification", "url": "/workflow-library/partner-lead-qualification", "businessFunction": "Lead qualification", "department": "Sales", "revenueLeak": "Poor Fit Leads", "kpi": "Sales Time Saved", "workflowType": "Review", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Partner Lead Qualification is weak when lead qualification teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Partner Lead Qualification comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales development manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "partner_lead_qualification_review_ready_rate", "baselineMetricDescription": "Share of partner lead qualification records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce, risk review notes", "collectionMethod": "Sample partner lead qualification records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A partner, reseller, channel source, or referral partner submits a lead or requests deal registration.", "requiredEvidence": [ "Partner name, tier, program status, and source", "End customer, contact, company, need, and urgency", "Partner relationship, notes, and introduction path", "Duplicate lead, account, opportunity, or partner submission status", "Attribution, compensation, and acceptance rules", "Sales owner and partner owner" ], "aiRole": "AI prepares the partner lead qualification record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales development manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales development manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances partner lead qualification from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Partner Lead Qualification does not have stable source records, owner fields, or status fields to sample.", "No accountable lead qualification owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 partner lead qualification records, or all records from one lead qualification segment over 45 days", "pilotOwner": "Sales development manager", "pilotSuccessThreshold": "At least 90% of sampled partner lead qualification records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Partner Lead Qualification is the lead qualification control for partner_lead_qualification_review_ready_rate, using hubspot-lead-routing, salesforce-lead-management, nist-ai-rmf as its source boundary and the workflow terms partner, lead, qualification. Its audit packet should carry partnerleadqualificationSourceRecord, partnerleadqualificationOwnerDecision, partnerleadqualificationExceptionQueue, partnerleadqualificationReviewOutcome, and partnerleadqualificationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales development manager, exception status, and a safe next action for partner lead qualification specifically.", "uniqueDataTest": "Audit 100 partner lead qualification records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep partner lead qualification separate from adjacent lead qualification workflows by requiring partner_lead_qualification_review_ready_rate, the Sales development manager review point, and the source boundary hubspot-lead-routing, salesforce-lead-management, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-lead-routing", "salesforce-lead-management", "nist-ai-rmf" ] }, { "id": "enterprise-inquiry-qualification", "name": "Enterprise Inquiry Qualification", "url": "/workflow-library/enterprise-inquiry-qualification", "businessFunction": "Lead qualification", "department": "Sales", "revenueLeak": "Poor Fit Leads", "kpi": "Sales Time Saved", "workflowType": "Routing", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Enterprise Inquiry Qualification is weak when lead qualification teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Enterprise Inquiry Qualification comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales development manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "enterprise_inquiry_qualification_review_ready_rate", "baselineMetricDescription": "Share of enterprise inquiry qualification records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce", "collectionMethod": "Sample enterprise inquiry qualification records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A large company submits a form, asks for information, requests a demo, sends an RFP, or contacts the company through a partner or executive channel.", "requiredEvidence": [ "Company, domain, size, industry, region, and account ownership", "Requester role, stakeholder clues, and buying committee signals", "Use case, business problem, urgency, and timeline evidence", "Procurement, legal, security, and decision-process clues", "Existing account history, partner source, and duplicate status", "Strategic account routing and senior-owner rules" ], "aiRole": "AI prepares the enterprise inquiry qualification record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales development manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales development manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances enterprise inquiry qualification from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Enterprise Inquiry Qualification does not have stable source records, owner fields, or status fields to sample.", "No accountable lead qualification owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 enterprise inquiry qualification records, or all records from one lead qualification segment over 45 days", "pilotOwner": "Sales development manager", "pilotSuccessThreshold": "At least 90% of sampled enterprise inquiry qualification records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Enterprise Inquiry Qualification is the lead qualification control for enterprise_inquiry_qualification_review_ready_rate, using hubspot-lead-routing, salesforce-lead-management as its source boundary and the workflow terms enterprise, inquiry, qualification. Its audit packet should carry enterpriseinquiryqualificationSourceRecord, enterpriseinquiryqualificationOwnerDecision, enterpriseinquiryqualificationExceptionQueue, enterpriseinquiryqualificationReviewOutcome, and enterpriseinquiryqualificationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales development manager, exception status, and a safe next action for enterprise inquiry qualification specifically.", "uniqueDataTest": "Audit 100 enterprise inquiry qualification records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep enterprise inquiry qualification separate from adjacent lead qualification workflows by requiring enterprise_inquiry_qualification_review_ready_rate, the Sales development manager review point, and the source boundary hubspot-lead-routing, salesforce-lead-management. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-lead-routing", "salesforce-lead-management" ] }, { "id": "speed-to-lead-response", "name": "Speed To Lead Response", "url": "/workflow-library/speed-to-lead-response", "businessFunction": "Speed-to-lead", "department": "Sales", "revenueLeak": "Lead Response", "kpi": "Conversion Rate", "workflowType": "Routing + Follow-Up", "riskLevel": "Medium", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Inbound leads decay when the first response depends on a rep noticing a notification, guessing priority, or manually stitching source context together. The buyer has already raised a hand; the weak point is the gap between capture, owner assignment, approved reply, and a logged disposition.", "economicLogic": "The economic case is not a blanket promise that faster is always better. It is that high-intent demand should not sit unowned while competitors respond, and sales leaders should be able to see which leads missed the response SLA, why they missed, and whether the delay affected conversion or meeting creation.", "baselineMetric": "qualified_lead_first_response_sla_rate", "baselineMetricDescription": "Share of qualified inbound leads that receive an owner-confirmed first response inside the team's SLA, with source, priority, owner, first-touch timestamp, and disposition captured for later conversion review.", "sourceSystem": "CRM lead records, form submissions, routing rules, sales engagement tasks, email/calendar activity", "collectionMethod": "Compare capture timestamp, qualification rule, owner assignment, first sales activity, meeting outcome, and disposition for every qualified inbound lead in the pilot segment.", "leadingIndicators": [ "lead-to-owner time", "first response SLA hit rate", "unowned qualified lead count", "low-confidence routing exceptions" ], "laggingIndicators": [ "meeting booked rate", "qualified lead conversion rate", "sales accepted lead rate" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A new lead, form submission, demo request, chat handoff, missed call, or high-intent inquiry arrives.", "requiredEvidence": [ "inquiry timestamp and channel", "source, page, offer, or campaign", "contact details and consent status", "lead urgency and stated request", "owner routing rules and availability", "approved first-response templates", "existing lead, customer, or opportunity status", "SLA thresholds and escalation rules" ], "aiRole": "AI reads the new lead record, source page, campaign, firmographic context, and routing criteria, then drafts a response brief, recommends priority, assigns the next task, and flags exceptions. It does not send unreviewed messages for high-value, duplicate, customer, or policy-sensitive records.", "humanReviewPoint": "Sales ops reviews routing exceptions, low-confidence matches, existing-customer conflicts, unusually large accounts, and any draft that changes commercial expectations. Reps still own the live buyer conversation and final disposition.", "evidenceBoundary": "External sources support the urgency and mechanics of lead response and routing. They do not prove a fixed conversion lift for ADA; that must be measured in the pilot by source and segment.", "stopRules": [ "The workflow optimizes for speed while sending weak or wrong-context replies.", "High-value or ambiguous leads route directly to automation instead of review." ], "notReadyIf": [ "Lead capture timestamp is not reliable.", "Qualified lead definition is unclear.", "Owner assignment rules are not documented." ], "pilotDuration": "14 days", "pilotSampleSize": "First 100 qualified inbound leads from one high-intent source or segment", "pilotOwner": "Sales operations manager", "pilotSuccessThreshold": "At least 90% of qualified leads have owner, response timestamp, disposition, and exception reason logged; response SLA improves without increasing misroutes above 5%.", "workflowDistinction": "Speed-to-lead response is a timing and ownership workflow. It begins after a lead is captured and qualified enough to deserve action, then measures whether the first response happened inside the agreed SLA with the right owner and context. It is not the same as form routing, which decides whether a record is assignable in the first place.", "uniqueDataTest": "Take 100 qualified inbound leads from one source. For each lead, verify capture timestamp, qualification reason, source page, owner assignment timestamp, first response timestamp, reply channel, disposition, and meeting or opportunity outcome. The workflow is ready only if missed SLA cases have reviewable reasons.", "duplicateGuard": "Do not merge this with website contact form routing or priority lead routing. This record owns first-response timing after a lead is actionable; routing records own assignment criteria and exception handling before the clock can be trusted.", "sourceRefs": [ "hbr-online-leads", "hubspot-sales-automation", "hubspot-lead-routing" ] }, { "id": "instant-lead-callback", "name": "Instant Lead Callback", "url": "/workflow-library/instant-lead-callback", "businessFunction": "Speed-to-lead", "department": "Sales", "revenueLeak": "Lead Response", "kpi": "Conversion Rate", "workflowType": "Workflow Support", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 96, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Callback requests are high-intent but fragile. A buyer expects a person soon, yet the team may lack verified phone consent, ownership, urgency, account context, and a script that matches the request. A fast bad callback can be as damaging as no callback.", "economicLogic": "The value is in capturing moments where the buyer explicitly asks for contact and making sure the callback is legal, owned, timely, and logged. The pilot should measure callback completion and disposition, not pretend every callback request is qualified revenue.", "baselineMetric": "callback_request_completion_with_context_rate", "baselineMetricDescription": "Share of explicit callback requests with consent, source, urgency, owner, attempted callback timestamp, completed callback or reason missed, and CRM disposition captured.", "sourceSystem": "Website forms, phone system, CRM lead records, messaging consent logs, sales engagement tasks", "collectionMethod": "Compare callback request timestamp to owner assignment, consent status, first call attempt, call completion, voicemail/SMS fallback, and disposition.", "leadingIndicators": [ "callback assignment time", "consent verification rate", "first-attempt completion rate", "missed callback exception count" ], "laggingIndicators": [ "callback-to-meeting rate", "callback connected rate", "qualified opportunity creation" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A high-intent lead requests a call, submits a phone number, misses a callback, starts a demo request, or asks for urgent contact.", "requiredEvidence": [ "lead source and inquiry timestamp", "phone number, validity check, timezone, and callback window", "contact consent and preferred channel", "stated need and urgency", "existing lead or customer match", "owner availability and backup owner", "call attempt history", "approved call notes or voicemail language" ], "aiRole": "AI validates the callback request, checks consent and account context, creates a call brief, prioritizes urgency, and logs missing fields or fallback path. It does not place calls, send SMS, or make promises without human-owned rules.", "humanReviewPoint": "Sales ops reviews consent exceptions, high-value accounts, existing-customer conflicts, and any fallback message. The rep owns the actual call, qualification, and next-step commitment.", "evidenceBoundary": "Lead-response research supports urgency and Twilio supports messaging guardrails. Neither source validates a universal callback conversion rate.", "stopRules": [ "AI triggers SMS or call follow-up without confirmed consent or opt-out handling.", "The callback brief ignores the page or offer that created the request." ], "notReadyIf": [ "Phone consent and SMS consent are not distinguished.", "Callback request timestamp is unreliable.", "No owner is accountable for missed callbacks." ], "pilotDuration": "14 days", "pilotSampleSize": "First 75 explicit callback requests or all requests from two high-intent pages", "pilotOwner": "Sales operations manager", "pilotSuccessThreshold": "At least 90% of callback requests show consent, owner, first attempt, and disposition; no customer-visible SMS is sent without opt-out and consent controls.", "workflowDistinction": "Instant lead callback starts from a buyer's explicit request to be contacted. It is different from missed-call capture, which begins after a failed inbound phone event, and different from speed-to-lead response, which may use email or rep outreach for broader inbound leads.", "uniqueDataTest": "Audit callback requests for request timestamp, source page, phone number, consent evidence, owner assignment, first attempt time, connected or missed status, fallback communication, and CRM disposition. Any automated SMS without consent evidence fails the test.", "duplicateGuard": "Keep this record separate from missed-call lead capture. Callback requests are opt-in demand events; missed calls are incomplete contact attempts that need identity matching and recovery.", "sourceRefs": [ "hbr-online-leads", "twilio-messaging-policy", "hubspot-sales-automation" ] }, { "id": "after-hours-lead-response", "name": "After-Hours Lead Response", "url": "/workflow-library/after-hours-lead-response", "businessFunction": "Speed-to-lead", "department": "Sales", "revenueLeak": "Lead Response", "kpi": "Conversion Rate", "workflowType": "Workflow Support", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "After-hours inquiries expose a coverage gap. Buyers submit forms, callback requests, or chat messages when the sales team is offline, and the next business day starts with stale, unprioritized demand and unclear expectations about what was promised overnight.", "economicLogic": "The value is not replacing humans after hours. It is triaging demand, setting appropriate expectations, protecting urgent opportunities, and giving the morning team a clean queue ranked by fit, urgency, source, and risk.", "baselineMetric": "after_hours_lead_triage_ready_rate", "baselineMetricDescription": "Share of after-hours inbound inquiries with source, urgency, fit signal, consent, expected response message, morning owner, and exception status ready before the next business day.", "sourceSystem": "CRM lead records, website forms, chat transcripts, phone/SMS logs, routing calendar, sales engagement queue", "collectionMethod": "Filter inquiries outside business hours and compare intake fields, automated acknowledgement, owner assignment, exception flags, first human response, and disposition.", "leadingIndicators": [ "after-hours acknowledgement coverage", "morning owner assignment rate", "urgent exception count", "consent-safe fallback rate" ], "laggingIndicators": [ "after-hours meeting booked rate", "next-day response SLA", "after-hours sales accepted lead rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A form, chat, call, voicemail, email, or demo request arrives outside the team's defined business hours.", "requiredEvidence": [ "inquiry timestamp and business-hours rule", "source, channel, and offer context", "contact details and consent status", "stated need and urgency language", "emergency or complaint keywords", "existing customer or lead match", "next-business-day owner and backup owner", "approved after-hours acknowledgment" ], "aiRole": "AI classifies after-hours inquiries, sends or prepares only approved expectation-setting messages, ranks the morning queue, and flags urgent, high-value, customer, or consent-sensitive records. It does not negotiate, promise availability, or replace on-call escalation.", "humanReviewPoint": "Revenue operations reviews acknowledgement templates, urgent exceptions, enterprise or customer records, and morning queue rules. Sales owners handle the first human response and final qualification.", "evidenceBoundary": "Sources support lead response urgency, automation mechanics, and messaging policy. The after-hours business impact has to be measured from the company's own inquiry mix.", "stopRules": [ "The system makes service or sales promises while no human is available.", "After-hours demand is treated as low-quality by default." ], "notReadyIf": [ "Business hours are not encoded.", "Approved acknowledgement copy does not exist.", "No morning queue owner is assigned." ], "pilotDuration": "30 days", "pilotSampleSize": "All after-hours inbound inquiries for 30 days or first 100 after-hours records", "pilotOwner": "Revenue operations manager", "pilotSuccessThreshold": "At least 90% of after-hours inquiries have a safe acknowledgement, morning owner, and disposition path; no urgent or high-value exception remains unreviewed past the next business morning.", "workflowDistinction": "After-hours lead response is a coverage workflow. It handles the gap between inquiry time and staffed sales hours, then prepares a prioritized morning queue. That is different from ordinary speed-to-lead, where reps are assumed available, and from callback workflows, where phone consent is the central issue.", "uniqueDataTest": "Audit inquiries submitted outside business hours for source, request type, urgency, acknowledgement copy, owner assignment, first human response time, exception status, and disposition. Separate urgent exceptions from normal next-day queue items.", "duplicateGuard": "Keep this separate from speed-to-lead response and instant callback. The unique operating constraint is lack of live coverage, so the artifact is a safe overnight triage and morning handoff record.", "sourceRefs": [ "hbr-online-leads", "hubspot-sales-automation", "twilio-messaging-policy" ] }, { "id": "high-intent-lead-alerting", "name": "High-Intent Lead Alerting", "url": "/workflow-library/high-intent-lead-alerting", "businessFunction": "Speed-to-lead", "department": "Sales", "revenueLeak": "Lead Response", "kpi": "Conversion Rate", "workflowType": "Workflow Support", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "High-intent lead alerting is weak when buying-signal alerts fire from isolated page views or clicks without fit, consent, duplicate status, owner, or false-positive review. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in high-intent lead alerting. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "high_intent_alert_acceptance_rate", "baselineMetricDescription": "Share of high-intent alerts accepted by sales or marketing ops after fit, source behavior, consent, duplicate, owner, and next-action evidence are reviewed.", "sourceSystem": "marketing automation, CRM, website analytics, lead scoring rules, email engagement logs, routing rules", "collectionMethod": "Compare generated alerts to accepted, rejected, duplicate, suppressed, and converted outcomes with reason codes.", "leadingIndicators": [ "alert precision by source", "owner action rate", "false-positive dismissal rate", "time to action" ], "laggingIndicators": [ "meeting booked from alerts", "opportunity creation from alerts", "pipeline influenced by alerts" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A lead views a pricing or demo page, submits a high-intent form, returns after prior contact, clicks a key email, or matches a defined buying-signal rule.", "requiredEvidence": [ "high-intent event and timestamp", "page, offer, campaign, or email context", "lead or account identity", "existing opportunity or customer status", "owner and territory rules", "suppression and frequency rules", "recent activity history", "approved outreach guidance" ], "aiRole": "AI evaluates buying signals against fit, source behavior, recency, consent, duplicate status, and owner rules, then creates alert briefs or suppresses low-confidence cases.", "humanReviewPoint": "Sales ops reviews alert rules, high-value accounts, duplicate or existing-customer matches, consent issues, and signals that would trigger outreach.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI treats isolated behavior as sales-ready intent and triggers intrusive outreach.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "Website events, CRM identity, scoring rules, or consent status are not connected.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 150 high-intent alerts or all alerts from one segment over 30 days", "pilotOwner": "Revenue operations manager", "pilotSuccessThreshold": "At least 80% of alerts are accepted by the owner or correctly suppressed, with false-positive reasons reviewed weekly.", "workflowDistinction": "High-intent lead alerting owns creating accepted buying-signal alerts with false-positive controls, not general lead scoring or speed-to-lead routing. Its proof object is high_intent_alert_acceptance_rate from marketing automation, CRM, website analytics, lead scoring rules, email engagement logs, routing rules, with Revenue operations manager accountable for review. Do not merge with B2B lead scoring or priority lead routing. Alerting detects time-sensitive buying signals; scoring ranks leads and routing assigns owners.", "uniqueDataTest": "Sample alerts for triggering signal, fit score, consent, duplicate status, owner, next action, acceptance decision, and outcome reason. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Do not merge with B2B lead scoring or priority lead routing. Alerting detects time-sensitive buying signals; scoring ranks leads and routing assigns owners.", "sourceRefs": [ "hubspot-sales-automation", "hubspot-lead-routing", "hubspot-lead-scoring" ] }, { "id": "new-form-submission-response", "name": "New Form Submission Response", "url": "/workflow-library/new-form-submission-response", "businessFunction": "Speed-to-lead", "department": "Sales", "revenueLeak": "Lead Response", "kpi": "Conversion Rate", "workflowType": "Routing", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "New Form Submission Response is weak when speed-to-lead teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of New Form Submission Response comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales operations manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "new_form_submission_response_review_ready_rate", "baselineMetricDescription": "Share of new form submission response records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot", "collectionMethod": "Sample new form submission response records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A website form, quote request, consultation request, demo form, gated download, or contact form is submitted.", "requiredEvidence": [ "form submission and required field status", "source page, offer, campaign, and referrer", "contact details and consent language", "stated need and urgency", "validation errors or missing fields", "duplicate lead or customer match", "owner assignment rule", "approved acknowledgment and follow-up language" ], "aiRole": "AI prepares the new form submission response record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales operations manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales operations manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances new form submission response from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "New Form Submission Response does not have stable source records, owner fields, or status fields to sample.", "No accountable speed-to-lead owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 new form submission response records, or all records from one speed-to-lead segment over 45 days", "pilotOwner": "Sales operations manager", "pilotSuccessThreshold": "At least 90% of sampled new form submission response records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "New Form Submission Response is the speed-to-lead control for new_form_submission_response_review_ready_rate, using hubspot-sales-automation, google-lead-form-assets as its source boundary and the workflow terms new, form, submission, response. Its audit packet should carry newformsubmissionresponseSourceRecord, newformsubmissionresponseOwnerDecision, newformsubmissionresponseExceptionQueue, newformsubmissionresponseReviewOutcome, and newformsubmissionresponseScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales operations manager, exception status, and a safe next action for new form submission response specifically.", "uniqueDataTest": "Audit 100 new form submission response records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep new form submission response separate from adjacent speed-to-lead workflows by requiring new_form_submission_response_review_ready_rate, the Sales operations manager review point, and the source boundary hubspot-sales-automation, google-lead-form-assets. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-sales-automation", "google-lead-form-assets" ] }, { "id": "sms-lead-response", "name": "SMS Lead Response", "url": "/workflow-library/sms-lead-response", "businessFunction": "Speed-to-lead", "department": "Sales", "revenueLeak": "Lead Response", "kpi": "Conversion Rate", "workflowType": "Follow-Up", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 96, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "SMS lead response is weak when teams text leads quickly but fail to prove consent, identity, routing owner, opt-out handling, and message safety. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in SMS lead response. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "sms_response_compliance_ready_rate", "baselineMetricDescription": "Share of SMS lead responses with consent evidence, owner assignment, identity match, approved message path, opt-out handling, and response-time event.", "sourceSystem": "SMS platform, CRM lead record, consent field, phone log, routing rules, opt-out log", "collectionMethod": "Sample SMS responses and compare timestamp, consent source, owner, message template, opt-out handling, escalation, and CRM outcome.", "leadingIndicators": [ "SMS eligibility completeness", "opt-out processing rate", "message logging rate", "reply detection rate" ], "laggingIndicators": [ "SMS reply rate", "meeting booked rate from SMS", "opt-out or complaint rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A lead requests text follow-up, submits a phone number with SMS consent, replies by text, misses a call, or asks for a quick callback by SMS.", "requiredEvidence": [ "SMS consent and opt-out status", "phone number and timezone", "lead source and stated request", "channel preference", "message purpose and approved copy", "owner assignment and handoff trigger", "conversation history", "sensitive-topic and complaint indicators" ], "aiRole": "AI drafts or selects SMS response options only after checking consent, routing owner, duplicate match, inquiry context, and escalation rules; uncertain cases become review tasks.", "humanReviewPoint": "Intake or sales ops reviews unclear consent, existing-customer conflicts, high-value inquiries, promise language, opt-out exceptions, and first-message edge cases.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI sends a text without valid consent or makes an unsupported customer promise.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "SMS consent, opt-out status, and approved templates are not captured in the CRM or SMS platform.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 SMS-eligible inbound leads or all SMS responses over 30 days", "pilotOwner": "Sales operations manager", "pilotSuccessThreshold": "100% of sent SMS responses have consent evidence and 90% receive an owner-approved path or documented exception within the SLA.", "workflowDistinction": "SMS lead response owns controlling SMS response safety and routing, not general speed-to-lead or phone callback handling. Its proof object is sms_response_compliance_ready_rate from SMS platform, CRM lead record, consent field, phone log, routing rules, opt-out log, with Sales operations manager accountable for review. Do not merge with speed-to-lead response or missed-call capture. SMS lead response has consent and opt-out controls that other first-response workflows do not require.", "uniqueDataTest": "Audit each SMS event for consent source, opt-out state, CRM owner, duplicate match, message template, response timestamp, and exception outcome. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Do not merge with speed-to-lead response or missed-call capture. SMS lead response has consent and opt-out controls that other first-response workflows do not require.", "sourceRefs": [ "twilio-messaging-policy", "hubspot-sales-automation", "nist-ai-rmf" ] }, { "id": "lead-response-sla-monitoring", "name": "Lead Response SLA Monitoring", "url": "/workflow-library/lead-response-sla-monitoring", "businessFunction": "Speed-to-lead", "department": "Sales", "revenueLeak": "Lead Response", "kpi": "Conversion Rate", "workflowType": "Follow-Up", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Lead Response SLA Monitoring is weak when speed-to-lead teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Lead Response SLA Monitoring comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales operations manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "lead_response_sla_monitoring_review_ready_rate", "baselineMetricDescription": "Share of lead response sla monitoring records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot", "collectionMethod": "Sample lead response sla monitoring records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A new lead enters the CRM, form queue, chat handoff, missed call queue, demo request queue, or high-intent alert queue.", "requiredEvidence": [ "lead creation timestamp and source", "meaningful-response definition", "assigned owner and backup owner", "SLA threshold by source or priority", "current response status", "autoresponder or acknowledgment status", "lead urgency and customer status", "breach reason and escalation rule" ], "aiRole": "AI prepares the lead response sla monitoring record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales operations manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales operations manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances lead response sla monitoring from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Lead Response SLA Monitoring does not have stable source records, owner fields, or status fields to sample.", "No accountable speed-to-lead owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 lead response sla monitoring records, or all records from one speed-to-lead segment over 45 days", "pilotOwner": "Sales operations manager", "pilotSuccessThreshold": "At least 90% of sampled lead response sla monitoring records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Lead Response SLA Monitoring is the speed-to-lead control for lead_response_sla_monitoring_review_ready_rate, using hbr-online-leads, hubspot-sales-automation as its source boundary and the workflow terms lead, response, sla, monitoring. Its audit packet should carry leadresponseslamonitoringSourceRecord, leadresponseslamonitoringOwnerDecision, leadresponseslamonitoringExceptionQueue, leadresponseslamonitoringReviewOutcome, and leadresponseslamonitoringScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales operations manager, exception status, and a safe next action for lead response sla monitoring specifically.", "uniqueDataTest": "Audit 100 lead response sla monitoring records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep lead response sla monitoring separate from adjacent speed-to-lead workflows by requiring lead_response_sla_monitoring_review_ready_rate, the Sales operations manager review point, and the source boundary hbr-online-leads, hubspot-sales-automation. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hbr-online-leads", "hubspot-sales-automation" ] }, { "id": "priority-lead-routing", "name": "Priority Lead Routing", "url": "/workflow-library/priority-lead-routing", "businessFunction": "Speed-to-lead", "department": "Sales", "revenueLeak": "Lead Response", "kpi": "Conversion Rate", "workflowType": "Routing", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Priority routing breaks when every scoring signal is treated as equal. High-fit accounts, urgent requests, existing opportunities, low-quality content downloads, and partner conflicts can all look like hot leads unless routing rules explain why a record deserves scarce rep attention.", "economicLogic": "The value is allocation of sales capacity. The workflow should prove that high-priority leads reach the right owner faster while false positives, owner overload, and territory conflicts stay visible enough to correct.", "baselineMetric": "priority_route_acceptance_rate", "baselineMetricDescription": "Share of priority-routed leads accepted by the assigned owner with priority reason, routing criteria, territory/account check, first action, and rejection reason captured.", "sourceSystem": "CRM lead records, lead scoring rules, routing rules, territory assignments, sales engagement tasks", "collectionMethod": "Compare priority recommendation, route owner, account or territory check, first action, sales acceptance, rejection reason, and downstream conversion.", "leadingIndicators": [ "priority route time", "owner acceptance rate", "false-priority rejection rate", "territory exception count" ], "laggingIndicators": [ "priority lead meeting rate", "opportunity creation rate", "rep capacity impact" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A new lead meets a priority rule, high-intent signal, fit threshold, urgency marker, service-line rule, territory rule, or strategic account rule.", "requiredEvidence": [ "lead source and priority signal", "service line, location, territory, or segment", "company fit and urgency evidence", "current account or opportunity owner", "owner capacity and availability", "routing rule and fallback owner", "assignment conflict history", "approved escalation criteria" ], "aiRole": "AI combines fit, behavior, source, urgency, account context, and routing rules to recommend priority and owner. It explains the priority reason and flags territory, account, partner, or confidence exceptions rather than silently assigning every high score.", "humanReviewPoint": "Revenue ops reviews priority thresholds, false-positive clusters, owner overload, enterprise exceptions, and account conflicts. Sales managers approve any rule that changes territory or named-account ownership.", "evidenceBoundary": "Sources support lead routing and sales automation mechanics, but priority model lift requires company-specific acceptance and conversion data.", "stopRules": [ "Priority scores overload top reps with noisy leads.", "Routing ignores account ownership or open opportunity context." ], "notReadyIf": [ "Priority reasons are not stored.", "Sales acceptance and rejection reasons are not tracked.", "Territory or account ownership is unreliable." ], "pilotDuration": "30 days", "pilotSampleSize": "First 150 priority-qualified leads or one full month of priority-routed records", "pilotOwner": "Revenue operations manager", "pilotSuccessThreshold": "At least 85% of priority routes are accepted or rejected with reason, and confirmed false-priority routes remain below 10% after rule adjustments.", "workflowDistinction": "Priority lead routing is an allocation workflow. It decides which qualified leads deserve faster or different owner attention based on explicit reasons. It is not the same as lead scoring, which creates a signal, or speed-to-lead, which measures first response after a route exists.", "uniqueDataTest": "Review priority-routed leads for priority reason, source, fit signal, score band, account ownership, territory match, owner acceptance, first action, rejection reason, and conversion. The test should identify which rules create false urgency.", "duplicateGuard": "Keep this separate from B2B lead scoring and inbound qualification. Scoring ranks likelihood or fit; qualification decides sales readiness; priority routing allocates scarce owner attention and must show acceptance evidence.", "sourceRefs": [ "hubspot-lead-routing", "hubspot-sales-automation" ] }, { "id": "lead-follow-up", "name": "Lead Follow-Up", "url": "/workflow-library/lead-follow-up", "businessFunction": "Follow-up", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Follow-Up", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Lead Follow-Up is weak when follow-up teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Lead Follow-Up comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales development manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "lead_follow_up_review_ready_rate", "baselineMetricDescription": "Share of lead follow-up records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot", "collectionMethod": "Sample lead follow-up records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A qualified lead has a promised next step, open question, stalled deal, completed consultation, quote, demo, or follow-up due date.", "requiredEvidence": [ "last interaction and channel", "promised next step", "lead status and deal stage", "open objection or unresolved question", "owner and due date", "prior follow-up attempts", "approved message templates", "stop condition or suppression reason" ], "aiRole": "AI prepares the lead follow-up record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales development manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales development manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances lead follow-up from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Lead Follow-Up does not have stable source records, owner fields, or status fields to sample.", "No accountable follow-up owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 lead follow-up records, or all records from one follow-up segment over 45 days", "pilotOwner": "Sales development manager", "pilotSuccessThreshold": "At least 90% of sampled lead follow-up records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Lead Follow-Up is the follow-up control for lead_follow_up_review_ready_rate, using hubspot-sales-automation, hubspot-lead-routing as its source boundary and the workflow terms lead, follow, up. Its audit packet should carry leadfollowupSourceRecord, leadfollowupOwnerDecision, leadfollowupExceptionQueue, leadfollowupReviewOutcome, and leadfollowupScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales development manager, exception status, and a safe next action for lead follow-up specifically.", "uniqueDataTest": "Audit 100 lead follow-up records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep lead follow-up separate from adjacent follow-up workflows by requiring lead_follow_up_review_ready_rate, the Sales development manager review point, and the source boundary hubspot-sales-automation, hubspot-lead-routing. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-sales-automation", "hubspot-lead-routing" ] }, { "id": "post-consultation-follow-up", "name": "Post-Consultation Follow-Up", "url": "/workflow-library/post-consultation-follow-up", "businessFunction": "Follow-up", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Follow-Up", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Post-Consultation Follow-Up is weak when follow-up teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Post-Consultation Follow-Up comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales development manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "post_consultation_follow_up_review_ready_rate", "baselineMetricDescription": "Share of post-consultation follow-up records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, risk review notes", "collectionMethod": "Sample post-consultation follow-up records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A consultation, discovery call, strategy session, site visit, audit call, or advisory meeting ends and requires a next-step message.", "requiredEvidence": [ "call notes or transcript", "problem statement and desired outcome", "agreed next step and due date", "budget readiness and decision timeline", "open objection or unresolved question", "stakeholders and account owner", "prior context and promised materials", "approved recap and next-step language" ], "aiRole": "AI prepares the post-consultation follow-up record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales development manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales development manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances post-consultation follow-up from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Post-Consultation Follow-Up does not have stable source records, owner fields, or status fields to sample.", "No accountable follow-up owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 post-consultation follow-up records, or all records from one follow-up segment over 45 days", "pilotOwner": "Sales development manager", "pilotSuccessThreshold": "At least 90% of sampled post-consultation follow-up records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Post-Consultation Follow-Up is the follow-up control for post_consultation_follow_up_review_ready_rate, using hubspot-sales-automation, nist-ai-rmf as its source boundary and the workflow terms post, consultation, follow, up. Its audit packet should carry postconsultationfollowupSourceRecord, postconsultationfollowupOwnerDecision, postconsultationfollowupExceptionQueue, postconsultationfollowupReviewOutcome, and postconsultationfollowupScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales development manager, exception status, and a safe next action for post-consultation follow-up specifically.", "uniqueDataTest": "Audit 100 post-consultation follow-up records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep post-consultation follow-up separate from adjacent follow-up workflows by requiring post_consultation_follow_up_review_ready_rate, the Sales development manager review point, and the source boundary hubspot-sales-automation, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-sales-automation", "nist-ai-rmf" ] }, { "id": "no-response-follow-up", "name": "No-Response Follow-Up", "url": "/workflow-library/no-response-follow-up", "businessFunction": "Follow-up", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Follow-Up", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "No-response follow-up stays weak when follow-up continues after silence without checking prior message, buyer context, consent, channel, timing, and suppression rules. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making no-response follow-up measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "no_response_follow_up_rule_adherence_rate", "baselineMetricDescription": "Share of no-response follow-ups with prior touch history, channel consent, suppression status, timing rule, owner review, and reply or disposition outcome.", "sourceSystem": "CRM activity history, email sequencing tool, SMS platform, consent fields, sales engagement rules", "collectionMethod": "Compare follow-up recommendations to sent messages, replies, opt-outs, suppression reasons, owner edits, and opportunity dispositions.", "leadingIndicators": [ "no-response threshold accuracy", "sequence exit rate", "stale task rate", "recycle reason completeness" ], "laggingIndicators": [ "re-engagement reply rate", "meeting booked from re-engagement", "stale pipeline reduction" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A qualified lead has not replied after a defined wait period, missed next step, unanswered quote, quiet proposal, or stalled sales conversation.", "requiredEvidence": [ "last interaction and last touch date", "number of prior attempts", "engagement status and channel history", "deal stage and lead priority", "opt-out, explicit no, or complaint status", "next useful reason to follow up", "owner and cadence rule", "approved close-loop language" ], "aiRole": "AI prepares follow-up options based on prior messages, last buyer action, consent, channel rules, and suppression status, then flags cases that should stop or switch path.", "humanReviewPoint": "Sales owner reviews high-value accounts, sensitive context, unclear consent, repeated silence, promise language, and any message that changes commercial commitment.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI sends unwanted or inappropriate follow-up after silence, opt-out, or contextual stop signal.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Activity history, sequence rules, opt-out status, or suppression reasons are not reliable.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 250 no-response follow-up candidates from one sequence or sales team", "pilotOwner": "Sales development manager", "pilotSuccessThreshold": "95% of follow-ups follow timing, consent, and suppression rules, and opt-out or complaint exceptions remain at 0 during the pilot.", "workflowDistinction": "No-response follow-up handles controlling follow-up after silence with timing, consent, suppression, and context rules. The audit sample checks audit each candidate for last touch, channel, consent, suppression state, sequence rule, owner edit, sent status, and reply or disposition. Keep separate from proposal follow-up and abandoned inquiry follow-up. No-response follow-up starts after a completed outreach attempt and is governed by silence and suppression logic.", "uniqueDataTest": "Audit each candidate for last touch, channel, consent, suppression state, sequence rule, owner edit, sent status, and reply or disposition. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from proposal follow-up and abandoned inquiry follow-up. No-response follow-up starts after a completed outreach attempt and is governed by silence and suppression logic.", "sourceRefs": [ "hubspot-sales-automation", "twilio-messaging-policy" ] }, { "id": "quote-follow-up", "name": "Quote Follow-Up", "url": "/workflow-library/quote-follow-up", "businessFunction": "Follow-up", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Follow-Up", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Quotes are commercial artifacts, not simple reminders. Buyers may be waiting on price, availability, expiration, shipping, scope, or approval, while reps follow up with generic messages that miss the commercial risk or accidentally change the offer.", "economicLogic": "The value is faster quote disposition with tighter control of price and terms. The workflow should reveal which quotes need a reminder, which need clarification, which are expired, and which require human review before any commercial statement goes out.", "baselineMetric": "quote_status_disposition_rate", "baselineMetricDescription": "Share of sent quotes with quote status, expiration, buyer question, follow-up owner, commercial-term review status, response, and won/lost/no-decision disposition captured.", "sourceSystem": "CRM opportunities, quoting tool, CPQ or proposal tool, email/calendar activity, order records", "collectionMethod": "Compare quote sent date, expiration date, quote status, buyer response, follow-up task, commercial-term changes, order or close outcome, and lost reason.", "leadingIndicators": [ "quote follow-up SLA", "expired quote count", "commercial-term exception rate", "buyer question capture" ], "laggingIndicators": [ "quote-to-order rate", "average days quote outstanding", "closed-lost price or no-response reasons" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A quote, estimate, pricing sheet, or proposal has been sent and the buyer has not accepted, declined, asked a question, or reached the next decision milestone.", "requiredEvidence": [ "quote sent date and delivery channel", "quoted scope and line items", "price basis, assumptions, and expiration date", "buyer objection or open question", "decision date or expected timeline", "prior follow-up attempts", "account owner and approval rules", "approved message and discount boundaries" ], "aiRole": "AI checks quote status, expiration, buyer activity, prior messages, and CRM stage, then drafts an internal follow-up brief or safe message. It must not revise price, discount, availability, or terms without an approved source.", "humanReviewPoint": "The quote owner reviews any customer-facing follow-up that mentions price, discount, expiration extension, delivery, availability, legal terms, or scope. Sales ops reviews recurring quote aging and exception patterns.", "evidenceBoundary": "Automation and risk sources support process mechanics and review boundaries. Quote outcome impact must be measured from the company's own quote cohorts.", "stopRules": [ "AI changes commercial meaning while trying to personalize follow-up.", "Expired or superseded quotes receive normal follow-up." ], "notReadyIf": [ "Quote expiration and status are not tracked.", "Pricing approval rules are unclear.", "Quote outcomes are not logged." ], "pilotDuration": "30 days", "pilotSampleSize": "First 75 sent quotes or all quotes from one sales team for 30 days", "pilotOwner": "Sales operations manager", "pilotSuccessThreshold": "At least 90% of quotes have status, expiration, follow-up, and disposition; no draft with price, discount, availability, or term changes is sent without review.", "workflowDistinction": "Quote follow-up centers on priced offers, status, expiration, and commercial-term safety. That makes it different from proposal follow-up, where stakeholder process and objections may matter more than a fixed quote artifact.", "uniqueDataTest": "Audit sent quotes for status, expiration date, superseded quote link, buyer question, follow-up task, commercial exception, response, order conversion, and close-out reason. Any unreviewed term change fails the workflow.", "duplicateGuard": "Keep this separate from proposal follow-up and deal desk review. Quote follow-up governs open priced artifacts; deal desk review approves complex exceptions before or during quote creation.", "sourceRefs": [ "hubspot-sales-automation", "nist-ai-rmf" ] }, { "id": "proposal-follow-up", "name": "Proposal Follow-Up", "url": "/workflow-library/proposal-follow-up", "businessFunction": "Follow-up", "department": "Sales", "revenueLeak": "Deal Follow-Up", "kpi": "Win Rate", "workflowType": "Follow-Up", "riskLevel": "Medium", "ownerRole": "Sales Enablement", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Proposals stall when the team treats send date as the finish line. The buyer still has stakeholders, objections, procurement steps, open questions, and timing risk, but follow-up often becomes a generic nudge with no link to the decision process.", "economicLogic": "The value is late-stage pipeline discipline. Better proposal follow-up should make next steps, decision dates, unresolved objections, and stakeholder gaps visible early enough for the seller to act before a deal quietly becomes no-decision.", "baselineMetric": "proposal_next_step_integrity_rate", "baselineMetricDescription": "Share of sent proposals with decision date, stakeholder map, open objections, follow-up owner, next action, buyer response, and stage disposition captured before the forecast period closes.", "sourceSystem": "CRM opportunities, proposal tool, email/calendar activity, call notes, sales engagement tasks", "collectionMethod": "Compare proposal sent date to next-step task, buyer response, stakeholder or objection evidence, stage movement, close/lost reason, and forecast update.", "leadingIndicators": [ "next-step logged rate", "proposal follow-up completion", "open objection count", "decision date coverage" ], "laggingIndicators": [ "proposal-to-close rate", "no-decision closed-lost rate", "sales cycle after proposal" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A proposal has been sent and the buyer has not accepted, declined, asked a question, reached a decision date, or completed the next milestone.", "requiredEvidence": [ "proposal sent date and delivery channel", "scope, assumptions, exclusions, and pricing basis", "proposal viewed or engagement signal", "buyer objection or open question", "decision date and stakeholder status", "prior follow-up attempts", "account owner and approval rules", "approved follow-up language and commercial boundaries" ], "aiRole": "AI reads the proposal, opportunity stage, prior call notes, stakeholders, open objections, and agreed next step, then drafts a follow-up brief and task. It should not send customer-facing language that changes terms or claims approval.", "humanReviewPoint": "The seller or sales manager reviews customer-facing follow-up, commercial language, scope, legal terms, discount references, and any escalation for stalled high-value deals.", "evidenceBoundary": "Sources support sales automation and human risk controls. Proposal follow-up impact must be measured by proposal cohort, deal size, and sales cycle stage.", "stopRules": [ "AI sends a pleasant but commercially empty nudge.", "The draft changes scope, discount, legal language, or delivery commitments." ], "notReadyIf": [ "Proposal sent dates are not tracked.", "Opportunity stages do not distinguish proposal sent.", "Close-lost/no-decision reasons are blank." ], "pilotDuration": "30 days", "pilotSampleSize": "First 50 sent proposals from one sales segment or all proposals in one monthly cohort", "pilotOwner": "Sales manager", "pilotSuccessThreshold": "At least 90% of sent proposals have next action, decision date or reason absent, stakeholder context, and disposition before aging past the follow-up SLA.", "workflowDistinction": "Proposal follow-up manages decision-process momentum after a proposal is delivered. It focuses on stakeholders, objections, decision date, and stage evidence. Quote follow-up is narrower around price, expiration, and commercial terms.", "uniqueDataTest": "Audit sent proposals for proposal sent date, next-step task, decision date, stakeholder list, open objections, buyer response, follow-up content, stage movement, and close/lost reason. The workflow should separate active deals from no-decision drift.", "duplicateGuard": "Do not merge with quote follow-up or post-consultation follow-up. Proposal follow-up owns stakeholder, objection, decision-date, and stage-movement evidence after a formal proposal is sent, while the adjacent workflows handle priced quote status or meeting recap next steps.", "sourceRefs": [ "hubspot-sales-automation", "nist-ai-rmf" ] }, { "id": "webinar-attendee-follow-up", "name": "Webinar Attendee Follow-Up", "url": "/workflow-library/webinar-attendee-follow-up", "businessFunction": "Follow-up", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Follow-Up", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Webinar Attendee Follow-Up is weak when follow-up teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Webinar Attendee Follow-Up comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales development manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "webinar_attendee_follow_up_review_ready_rate", "baselineMetricDescription": "Share of webinar attendee follow-up records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot", "collectionMethod": "Sample webinar attendee follow-up records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A live webinar, virtual event, workshop, or on-demand session ends and attendance or engagement data becomes available.", "requiredEvidence": [ "registration and attendance status", "attended, no-show, early-leaver, or replay viewer segment", "questions asked and poll responses", "CTA clicks, resource downloads, and engagement score", "company fit and account status", "consent and unsubscribe status", "sales owner and nurture path", "approved asset and follow-up language" ], "aiRole": "AI prepares the webinar attendee follow-up record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales development manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales development manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances webinar attendee follow-up from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Webinar Attendee Follow-Up does not have stable source records, owner fields, or status fields to sample.", "No accountable follow-up owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 webinar attendee follow-up records, or all records from one follow-up segment over 45 days", "pilotOwner": "Sales development manager", "pilotSuccessThreshold": "At least 90% of sampled webinar attendee follow-up records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Webinar Attendee Follow-Up is the follow-up control for webinar_attendee_follow_up_review_ready_rate, using hubspot-sales-automation, hubspot-lead-routing as its source boundary and the workflow terms webinar, attendee, follow, up. Its audit packet should carry webinarattendeefollowupSourceRecord, webinarattendeefollowupOwnerDecision, webinarattendeefollowupExceptionQueue, webinarattendeefollowupReviewOutcome, and webinarattendeefollowupScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales development manager, exception status, and a safe next action for webinar attendee follow-up specifically.", "uniqueDataTest": "Audit 100 webinar attendee follow-up records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep webinar attendee follow-up separate from adjacent follow-up workflows by requiring webinar_attendee_follow_up_review_ready_rate, the Sales development manager review point, and the source boundary hubspot-sales-automation, hubspot-lead-routing. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-sales-automation", "hubspot-lead-routing" ] }, { "id": "abandoned-inquiry-follow-up", "name": "Abandoned Inquiry Follow-Up", "url": "/workflow-library/abandoned-inquiry-follow-up", "businessFunction": "Follow-up", "department": "Operations", "revenueLeak": "Poor Fit Leads", "kpi": "Capacity Recovered", "workflowType": "Follow-Up", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Abandoned inquiry follow-up is weak when partially completed forms and booking flows create tempting recovery opportunities without clear consent, identity, or abandonment reason. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in abandoned inquiry follow-up. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "abandoned_inquiry_recovery_review_rate", "baselineMetricDescription": "Share of abandoned inquiries reviewed for consent, identity, source step, friction reason, duplicate status, recovery message path, and outcome.", "sourceSystem": "form analytics, booking tool, CRM, consent field, email or SMS platform, website event log", "collectionMethod": "Compare abandoned flow events to CRM matches, consent evidence, recovery attempts, replies, suppression reasons, and form-friction notes.", "leadingIndicators": [ "known-contact match rate", "safe recovery eligibility", "abandonment step distribution", "recovery task completion" ], "laggingIndicators": [ "recovered reply rate", "recovered meeting rate", "unwanted contact complaint rate" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "A form, quote request, booking flow, consultation request, or inquiry process is started but not completed, while enough permitted data exists to consider follow-up.", "requiredEvidence": [ "partial submission fields", "contact details and consent status", "source page, offer, and campaign", "field where the person stopped", "timestamp and session context", "sensitive-field indicator", "duplicate lead or customer history", "approved recovery message and stop rule" ], "aiRole": "AI identifies recoverable abandoned inquiries, summarizes the abandonment context, checks consent and duplicate status, and drafts a safe recovery message when rules allow.", "humanReviewPoint": "Intake reviews unclear consent, sensitive form content, existing-customer matches, high-value leads, duplicate records, and any recovery message with promise language.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI follows up on a partially completed inquiry without valid consent or with sensitive inferred context.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "The form or booking flow does not capture abandoned step, consent, timestamp, or stable identity evidence.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "All abandoned inquiry events from one form or booking flow over 30 days", "pilotOwner": "Demand generation manager", "pilotSuccessThreshold": "Classify 90% of abandoned inquiries into recover, suppress, or fix-flow paths and keep consent exceptions at 0 sent messages.", "workflowDistinction": "Abandoned inquiry follow-up owns recovering incomplete inquiries with consent and friction evidence, not sending generic no-response follow-up after a completed inquiry. Its proof object is abandoned_inquiry_recovery_review_rate from form analytics, booking tool, CRM, consent field, email or SMS platform, website event log, with Demand generation manager accountable for review. Keep separate from no-response follow-up and website form routing. Abandoned inquiry follow-up starts before submission is complete and must prove recoverability.", "uniqueDataTest": "Trace each abandoned event to form step, consent field, identity match, recovery decision, message path, and outcome or suppression reason. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Keep separate from no-response follow-up and website form routing. Abandoned inquiry follow-up starts before submission is complete and must prove recoverability.", "sourceRefs": [ "hubspot-sales-automation", "twilio-messaging-policy", "nist-ai-rmf" ] }, { "id": "long-cycle-sales-follow-up", "name": "Long-Cycle Sales Follow-Up", "url": "/workflow-library/long-cycle-sales-follow-up", "businessFunction": "Follow-up", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Follow-Up", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Long-Cycle Sales Follow-Up is weak when follow-up teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Long-Cycle Sales Follow-Up comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales development manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "long_cycle_sales_follow_up_review_ready_rate", "baselineMetricDescription": "Share of long-cycle sales follow-up records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce", "collectionMethod": "Sample long-cycle sales follow-up records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A complex opportunity has a long buying timeline, multiple stakeholders, a future decision window, stalled milestone, procurement step, or re-engagement signal.", "requiredEvidence": [ "buying stage and next milestone", "stakeholder map and champion status", "last interaction and last value sent", "decision process and budget window", "engagement signal or re-entry reason", "procurement, legal, or approval step", "account owner and executive sponsor", "approved nurture and follow-up language" ], "aiRole": "AI prepares the long-cycle sales follow-up record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales development manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales development manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances long-cycle sales follow-up from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Long-Cycle Sales Follow-Up does not have stable source records, owner fields, or status fields to sample.", "No accountable follow-up owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 long-cycle sales follow-up records, or all records from one follow-up segment over 45 days", "pilotOwner": "Sales development manager", "pilotSuccessThreshold": "At least 90% of sampled long-cycle sales follow-up records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Long-Cycle Sales Follow-Up is the follow-up control for long_cycle_sales_follow_up_review_ready_rate, using hubspot-sequences, salesforce-pipeline-inspection, hubspot-stage-calculated-properties as its source boundary and the workflow terms long, cycle, sales, follow, up. Its audit packet should carry longcyclesalesfollowupSourceRecord, longcyclesalesfollowupOwnerDecision, longcyclesalesfollowupExceptionQueue, longcyclesalesfollowupReviewOutcome, and longcyclesalesfollowupScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales development manager, exception status, and a safe next action for long-cycle sales follow-up specifically.", "uniqueDataTest": "Audit 100 long-cycle sales follow-up records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep long-cycle sales follow-up separate from adjacent follow-up workflows by requiring long_cycle_sales_follow_up_review_ready_rate, the Sales development manager review point, and the source boundary hubspot-sequences, salesforce-pipeline-inspection, hubspot-stage-calculated-properties. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-sequences", "salesforce-pipeline-inspection", "hubspot-stage-calculated-properties" ] }, { "id": "sales-call-summaries", "name": "Sales Call Summaries", "url": "/workflow-library/sales-call-summaries", "businessFunction": "Sales enablement", "department": "Sales", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Follow-Up", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Sales Call Summaries is weak when sales enablement teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Sales Call Summaries comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales enablement manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "sales_call_summaries_review_ready_rate", "baselineMetricDescription": "Share of sales call summaries records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, call intelligence, HubSpot, risk review notes", "collectionMethod": "Sample sales call summaries records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, call intelligence, HubSpot, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A sales call, discovery call, demo, consultation, or negotiation ends and needs a CRM note, follow-up task, or manager review.", "requiredEvidence": [ "call transcript or notes", "attendees and roles", "account and opportunity record", "buyer problem and desired outcome", "objections and risks", "commitments made by either side", "next steps and due dates", "CRM fields allowed for update" ], "aiRole": "AI prepares the sales call summaries record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales enablement manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales enablement manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances sales call summaries from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Sales Call Summaries does not have stable source records, owner fields, or status fields to sample.", "No accountable sales enablement owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 sales call summaries records, or all records from one sales enablement segment over 45 days", "pilotOwner": "Sales enablement manager", "pilotSuccessThreshold": "At least 90% of sampled sales call summaries records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Sales Call Summaries is the sales enablement control for sales_call_summaries_review_ready_rate, using gong-call-intelligence, hubspot-sales-automation, nist-ai-rmf as its source boundary and the workflow terms sales, call, summaries. Its audit packet should carry salescallsummariesSourceRecord, salescallsummariesOwnerDecision, salescallsummariesExceptionQueue, salescallsummariesReviewOutcome, and salescallsummariesScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales enablement manager, exception status, and a safe next action for sales call summaries specifically.", "uniqueDataTest": "Audit 100 sales call summaries records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep sales call summaries separate from adjacent sales enablement workflows by requiring sales_call_summaries_review_ready_rate, the Sales enablement manager review point, and the source boundary gong-call-intelligence, hubspot-sales-automation, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "gong-call-intelligence", "hubspot-sales-automation", "nist-ai-rmf" ] }, { "id": "sales-meeting-preparation", "name": "Sales Meeting Preparation", "url": "/workflow-library/sales-meeting-preparation", "businessFunction": "Sales enablement", "department": "Sales", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Sales Meeting Preparation is weak when sales enablement teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Sales Meeting Preparation comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales enablement manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "sales_meeting_preparation_review_ready_rate", "baselineMetricDescription": "Share of sales meeting preparation records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, call intelligence, Salesforce, HubSpot", "collectionMethod": "Sample sales meeting preparation records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, call intelligence, Salesforce, HubSpot.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A sales meeting, discovery call, demo, renewal discussion, consultation, or executive conversation is scheduled.", "requiredEvidence": [ "meeting date and objective", "account history and opportunity stage", "attendees, roles, and stakeholder notes", "last interaction and promised next step", "verified account signals and source links", "open discovery gaps", "approved talk tracks and assets", "pricing, scope, and competitor boundaries" ], "aiRole": "AI prepares the sales meeting preparation record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales enablement manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales enablement manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances sales meeting preparation from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Sales Meeting Preparation does not have stable source records, owner fields, or status fields to sample.", "No accountable sales enablement owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 sales meeting preparation records, or all records from one sales enablement segment over 45 days", "pilotOwner": "Sales enablement manager", "pilotSuccessThreshold": "At least 90% of sampled sales meeting preparation records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Sales Meeting Preparation is the sales enablement control for sales_meeting_preparation_review_ready_rate, using gong-call-intelligence, salesforce-lead-management, hubspot-sales-automation as its source boundary and the workflow terms sales, meeting, preparation. Its audit packet should carry salesmeetingpreparationSourceRecord, salesmeetingpreparationOwnerDecision, salesmeetingpreparationExceptionQueue, salesmeetingpreparationReviewOutcome, and salesmeetingpreparationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales enablement manager, exception status, and a safe next action for sales meeting preparation specifically.", "uniqueDataTest": "Audit 100 sales meeting preparation records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep sales meeting preparation separate from adjacent sales enablement workflows by requiring sales_meeting_preparation_review_ready_rate, the Sales enablement manager review point, and the source boundary gong-call-intelligence, salesforce-lead-management, hubspot-sales-automation. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "gong-call-intelligence", "salesforce-lead-management", "hubspot-sales-automation" ] }, { "id": "objection-handling-notes", "name": "Objection Handling Notes", "url": "/workflow-library/objection-handling-notes", "businessFunction": "Sales enablement", "department": "Sales", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Workflow Support", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Objection handling notes stays weak when objections from calls become scattered anecdotes instead of structured reasons, source quotes, answer options, and follow-up tasks. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making objection handling notes measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "objection_note_resolution_rate", "baselineMetricDescription": "Share of captured objections with source quote, objection type, buyer context, approved response, follow-up task, and outcome status.", "sourceSystem": "call intelligence transcripts, CRM notes, sales enablement repository, opportunity fields", "collectionMethod": "Sample objections from calls and compare extraction, response recommendation, owner approval, follow-up completion, and deal outcome.", "leadingIndicators": [ "objection category coverage", "source quote attached", "response note present", "enablement feedback count" ], "laggingIndicators": [ "objection-to-next-step conversion", "loss reason quality", "collateral gap closure" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "A buyer raises an objection during a call, email thread, proposal review, demo, negotiation, or follow-up conversation.", "requiredEvidence": [ "buyer quote or objection text", "deal stage and account context", "objection type and likely root concern", "supporting evidence from call notes or email", "approved response guidance", "proof assets or references", "owner and escalation path", "pricing, legal, security, or competitor risk flags" ], "aiRole": "AI extracts objections, buyer context, source quotes, potential responses, and follow-up tasks from calls or notes while flagging unsupported or sensitive response suggestions.", "humanReviewPoint": "Sales owner or enablement reviews response accuracy, pricing or legal sensitivity, competitive claims, and any follow-up sent to the buyer.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI gives reps unsupported answers to legal, pricing, security, or competitor objections.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Calls or notes do not capture objections, source quotes, or follow-up status.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "200 objections from recorded sales calls or CRM notes in one segment", "pilotOwner": "Sales enablement manager", "pilotSuccessThreshold": "85% of captured objections receive type, source quote, approved response path, and follow-up status within 7 days.", "workflowDistinction": "Objection handling notes handles structuring buyer objections into source-backed notes, response paths, and follow-up tasks. The audit sample checks trace each objection to call quote, type, buyer context, approved response, follow-up task, and outcome. Keep separate from sales call summaries and discovery question preparation. Objection notes focus on resistance and response control, not general call recap or prep.", "uniqueDataTest": "Trace each objection to call quote, type, buyer context, approved response, follow-up task, and outcome. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from sales call summaries and discovery question preparation. Objection notes focus on resistance and response control, not general call recap or prep.", "sourceRefs": [ "gong-call-intelligence", "hubspot-sales-automation", "nist-ai-rmf" ] }, { "id": "deal-desk-review", "name": "Deal Desk Review", "url": "/workflow-library/deal-desk-review", "businessFunction": "Sales enablement", "department": "Sales", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Routing", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Deal Desk Review is weak when sales enablement teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Deal Desk Review comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales enablement manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "deal_desk_review_review_ready_rate", "baselineMetricDescription": "Share of deal desk review records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, Salesforce, proposal tool, CLM", "collectionMethod": "Sample deal desk review records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, Salesforce, proposal tool, CLM.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "High", "dataReadiness": "Mixed", "trigger": "A deal includes a discount, custom term, non-standard scope, legal/security request, payment exception, multi-year structure, or verbal promise outside standard policy.", "requiredEvidence": [ "deal summary and account context", "requested exception type", "pricing, discount, and margin details", "contract or legal term changes", "security or compliance request", "scope or delivery exception", "required approver and approval threshold", "rep promise and supporting evidence" ], "aiRole": "AI prepares the deal desk review record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales enablement manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales enablement manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances deal desk review from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Deal Desk Review does not have stable source records, owner fields, or status fields to sample.", "No accountable sales enablement owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 deal desk review records, or all records from one sales enablement segment over 45 days", "pilotOwner": "Sales enablement manager", "pilotSuccessThreshold": "At least 90% of sampled deal desk review records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Deal Desk Review is the sales enablement control for deal_desk_review_review_ready_rate, using salesforce-deal-desk, pandadoc-conditional-approvals, docusign-clm as its source boundary and the workflow terms deal, desk, review. Its audit packet should carry dealdeskreviewSourceRecord, dealdeskreviewOwnerDecision, dealdeskreviewExceptionQueue, dealdeskreviewReviewOutcome, and dealdeskreviewScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales enablement manager, exception status, and a safe next action for deal desk review specifically.", "uniqueDataTest": "Audit 100 deal desk review records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep deal desk review separate from adjacent sales enablement workflows by requiring deal_desk_review_review_ready_rate, the Sales enablement manager review point, and the source boundary salesforce-deal-desk, pandadoc-conditional-approvals, docusign-clm. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "salesforce-deal-desk", "pandadoc-conditional-approvals", "docusign-clm" ] }, { "id": "sales-handoffs", "name": "Sales Handoffs", "url": "/workflow-library/sales-handoffs", "businessFunction": "Sales enablement", "department": "Sales", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Sales Handoffs is weak when sales enablement teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Sales Handoffs comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales enablement manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "sales_handoffs_review_ready_rate", "baselineMetricDescription": "Share of sales handoffs records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, call intelligence, HubSpot, risk review notes", "collectionMethod": "Sample sales handoffs records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, call intelligence, HubSpot, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A deal moves from sales to onboarding, customer success, implementation, delivery, account management, or a new internal owner.", "requiredEvidence": [ "closed or advancing deal record", "customer goals and success criteria", "stakeholders and decision roles", "proposal, contract, and scope notes", "promises, exclusions, and custom terms", "open risks and blockers", "implementation requirements", "handoff owner and first milestone" ], "aiRole": "AI prepares the sales handoffs record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales enablement manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales enablement manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances sales handoffs from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Sales Handoffs does not have stable source records, owner fields, or status fields to sample.", "No accountable sales enablement owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 sales handoffs records, or all records from one sales enablement segment over 45 days", "pilotOwner": "Sales enablement manager", "pilotSuccessThreshold": "At least 90% of sampled sales handoffs records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Sales Handoffs is the sales enablement control for sales_handoffs_review_ready_rate, using gong-call-intelligence, hubspot-sales-automation, nist-ai-rmf as its source boundary and the workflow terms sales, handoffs. Its audit packet should carry saleshandoffsSourceRecord, saleshandoffsOwnerDecision, saleshandoffsExceptionQueue, saleshandoffsReviewOutcome, and saleshandoffsScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales enablement manager, exception status, and a safe next action for sales handoffs specifically.", "uniqueDataTest": "Audit 100 sales handoffs records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep sales handoffs separate from adjacent sales enablement workflows by requiring sales_handoffs_review_ready_rate, the Sales enablement manager review point, and the source boundary gong-call-intelligence, hubspot-sales-automation, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "gong-call-intelligence", "hubspot-sales-automation", "nist-ai-rmf" ] }, { "id": "account-research-briefs", "name": "Account Research Briefs", "url": "/workflow-library/account-research-briefs", "businessFunction": "Sales enablement", "department": "Sales", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Account Research Briefs is weak when sales enablement teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Account Research Briefs comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales enablement manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "account_research_briefs_review_ready_rate", "baselineMetricDescription": "Share of account research briefs records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, call intelligence, HubSpot, risk review notes", "collectionMethod": "Sample account research briefs records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, call intelligence, HubSpot, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A rep prepares for prospecting, discovery, proposal review, renewal, expansion, account planning, or executive conversation.", "requiredEvidence": [ "account record and deal stage", "company website and public profile", "news, filings, job posts, or other source-cited signals", "stakeholder notes and prior activity", "known initiatives and risks", "industry or segment context", "meeting objective and discovery gaps", "approved proof points and claim boundaries" ], "aiRole": "AI prepares the account research briefs record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales enablement manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales enablement manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances account research briefs from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Account Research Briefs does not have stable source records, owner fields, or status fields to sample.", "No accountable sales enablement owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 account research briefs records, or all records from one sales enablement segment over 45 days", "pilotOwner": "Sales enablement manager", "pilotSuccessThreshold": "At least 90% of sampled account research briefs records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Account Research Briefs is the sales enablement control for account_research_briefs_review_ready_rate, using gong-call-intelligence, hubspot-sales-automation, nist-ai-rmf as its source boundary and the workflow terms account, research, briefs. Its audit packet should carry accountresearchbriefsSourceRecord, accountresearchbriefsOwnerDecision, accountresearchbriefsExceptionQueue, accountresearchbriefsReviewOutcome, and accountresearchbriefsScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales enablement manager, exception status, and a safe next action for account research briefs specifically.", "uniqueDataTest": "Audit 100 account research briefs records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep account research briefs separate from adjacent sales enablement workflows by requiring account_research_briefs_review_ready_rate, the Sales enablement manager review point, and the source boundary gong-call-intelligence, hubspot-sales-automation, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "gong-call-intelligence", "hubspot-sales-automation", "nist-ai-rmf" ] }, { "id": "sales-collateral-recommendations", "name": "Sales Collateral Recommendations", "url": "/workflow-library/sales-collateral-recommendations", "businessFunction": "Sales enablement", "department": "Sales", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Sales collateral recommendations stays weak when reps send collateral based on habit instead of buyer stage, objection, industry, use case, approved asset status, and next-step context. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making sales collateral recommendations measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "collateral_recommendation_acceptance_rate", "baselineMetricDescription": "Share of recommended collateral accepted by reps with buyer stage, use case, objection, approved asset status, send context, and outcome reason.", "sourceSystem": "CRM opportunity, sales content library, proposal tool, call notes, email engagement logs", "collectionMethod": "Compare collateral recommendations to rep selection, buyer engagement, stage context, asset approval status, and follow-up outcome.", "leadingIndicators": [ "asset-stage match rate", "seller acceptance rate", "outdated asset flag rate", "content gap submissions" ], "laggingIndicators": [ "asset engagement rate", "objection resolution rate", "sales cycle movement after asset send" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A rep prepares for a call, responds to an objection, follows up after a meeting, or needs buyer-facing proof for a specific deal stage.", "requiredEvidence": [ "deal stage and buyer question", "industry, segment, and account context", "objection or proof need", "approved collateral library", "asset freshness and owner", "external-use status", "prior assets already sent", "sales owner and next step" ], "aiRole": "AI suggests approved collateral based on buyer stage, industry, objection, use case, and recent conversation context, while suppressing outdated or unapproved assets.", "humanReviewPoint": "Sales owner or enablement reviews strategic accounts, sensitive claims, outdated assets, competitor claims, and any collateral sent with a customer-specific message.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI recommends outdated, unsupported, or wrong-stage collateral that weakens the sales motion.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Collateral library lacks owner, approval status, audience, use case, or freshness metadata.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 200 collateral recommendation moments in one sales segment", "pilotOwner": "Sales enablement manager", "pilotSuccessThreshold": "80% of recommendations are accepted or correctly suppressed by reps, and 100% of restricted or outdated assets are blocked.", "workflowDistinction": "Sales collateral recommendations handles matching approved collateral to buyer stage, objection, and use case with asset governance. The audit sample checks audit recommendation moment, asset status, buyer stage, objection, use case, rep acceptance, send status, and outcome. Keep separate from sales page offer review and RFP response drafting. Collateral recommendations choose existing assets for a deal; the others review public pages or draft formal responses.", "uniqueDataTest": "Audit recommendation moment, asset status, buyer stage, objection, use case, rep acceptance, send status, and outcome. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from sales page offer review and RFP response drafting. Collateral recommendations choose existing assets for a deal; the others review public pages or draft formal responses.", "sourceRefs": [ "hubspot-sales-automation", "pandadoc-rfp" ] }, { "id": "discovery-question-preparation", "name": "Discovery Question Preparation", "url": "/workflow-library/discovery-question-preparation", "businessFunction": "Sales enablement", "department": "Sales", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Discovery Question Preparation is weak when sales enablement teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Discovery Question Preparation comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales enablement manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "discovery_question_preparation_review_ready_rate", "baselineMetricDescription": "Share of discovery question preparation records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, call intelligence, HubSpot", "collectionMethod": "Sample discovery question preparation records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, call intelligence, HubSpot.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A discovery call, consultation, demo, renewal conversation, or sales meeting is scheduled and the rep needs an account-specific question set.", "requiredEvidence": [ "meeting objective", "account history and source context", "known buyer problem", "prior answers and open gaps", "stakeholder roles", "deal stage and qualification rubric", "approved discovery framework", "sensitive-topic boundaries" ], "aiRole": "AI prepares the discovery question preparation record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales enablement manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales enablement manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances discovery question preparation from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Discovery Question Preparation does not have stable source records, owner fields, or status fields to sample.", "No accountable sales enablement owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 discovery question preparation records, or all records from one sales enablement segment over 45 days", "pilotOwner": "Sales enablement manager", "pilotSuccessThreshold": "At least 90% of sampled discovery question preparation records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Discovery Question Preparation is the sales enablement control for discovery_question_preparation_review_ready_rate, using gong-call-intelligence, hubspot-sales-automation as its source boundary and the workflow terms discovery, question, preparation. Its audit packet should carry discoveryquestionpreparationSourceRecord, discoveryquestionpreparationOwnerDecision, discoveryquestionpreparationExceptionQueue, discoveryquestionpreparationReviewOutcome, and discoveryquestionpreparationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales enablement manager, exception status, and a safe next action for discovery question preparation specifically.", "uniqueDataTest": "Audit 100 discovery question preparation records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep discovery question preparation separate from adjacent sales enablement workflows by requiring discovery_question_preparation_review_ready_rate, the Sales enablement manager review point, and the source boundary gong-call-intelligence, hubspot-sales-automation. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "gong-call-intelligence", "hubspot-sales-automation" ] }, { "id": "proposal-creation", "name": "Proposal Creation", "url": "/workflow-library/proposal-creation", "businessFunction": "Proposal creation", "department": "Sales", "revenueLeak": "Proposal Delay", "kpi": "Win Rate", "workflowType": "Drafting", "riskLevel": "Medium", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Proposal creation is slow because sellers assemble scope, proof, pricing context, customer language, and approvals from scattered places. The bigger risk is not a blank page; it is a polished proposal that includes unsupported claims, stale scope, or unapproved terms.", "economicLogic": "The value is cycle-time reduction with approval discipline. A good workflow should create a better draft packet for review, reduce missing inputs, and keep legal, commercial, and delivery promises inside approved boundaries.", "baselineMetric": "proposal_review_ready_draft_rate", "baselineMetricDescription": "Share of proposal drafts that reach review with required scope, buyer problem, proof, pricing inputs, approved clauses, delivery assumptions, and owner decisions present.", "sourceSystem": "CRM opportunities, proposal tool, approved content library, pricing/CPQ, delivery templates, legal clause library", "collectionMethod": "Compare draft proposal sections to opportunity data, approved content, pricing inputs, delivery assumptions, review comments, revision count, and send approval.", "leadingIndicators": [ "required input completion", "unsupported claim count", "approval rework count", "draft cycle time" ], "laggingIndicators": [ "proposal send cycle time", "proposal approval rework", "proposal-to-close rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "Discovery is complete enough to create a proposal, estimate, commercial draft, or buyer-facing recommendation.", "requiredEvidence": [ "discovery notes and buyer priorities", "approved scope and deliverables", "pricing table or approved estimate", "assumptions and exclusions", "timeline and dependencies", "proof assets and claims", "terms or legal boundaries", "proposal owner and approval checklist" ], "aiRole": "AI assembles a review-ready draft from opportunity context, approved content, pricing inputs, delivery assumptions, and prior notes, then flags missing inputs and unsupported claims. It does not approve the proposal or invent proof.", "humanReviewPoint": "Sales, legal, pricing, and delivery owners review sections tied to scope, claims, terms, discounts, implementation, and delivery capacity before the proposal is sent.", "evidenceBoundary": "Proposal and CLM sources support approval workflow mechanics. They do not validate proposal quality or win-rate gains for ADA.", "stopRules": [ "AI creates persuasive but unsupported proof or capability claims.", "Proposal language conflicts with pricing, legal, or delivery assumptions." ], "notReadyIf": [ "Approved content library is missing.", "Proposal inputs are not structured in CRM.", "Approval owners for legal, pricing, and delivery are unclear." ], "pilotDuration": "30 days", "pilotSampleSize": "First 30 proposal drafts from one sales segment or service line", "pilotOwner": "Sales enablement lead", "pilotSuccessThreshold": "At least 85% of drafts reach first review with required inputs and source links; unsupported claim or unapproved-term defects fall below 10% of reviewed drafts.", "workflowDistinction": "Proposal creation is a draft assembly and approval workflow. It happens before send and focuses on content completeness, source-backed claims, and approval readiness. Proposal follow-up happens after send and focuses on buyer response and decision process.", "uniqueDataTest": "Review proposal drafts against opportunity fields, approved proof assets, pricing inputs, delivery assumptions, legal clauses, comments, revision count, and final approval. The workflow fails if reviewers cannot trace key claims to approved sources.", "duplicateGuard": "Do not merge with proposal compliance review. Creation assembles a draft; compliance review checks whether the draft violates legal, regulatory, brand, scope, or approval rules before release.", "sourceRefs": [ "pandadoc-approvals", "docusign-clm", "nist-ai-rmf" ] }, { "id": "statement-of-work-creation", "name": "Statement Of Work Creation", "url": "/workflow-library/statement-of-work-creation", "businessFunction": "Proposal creation", "department": "Sales", "revenueLeak": "Proposal Delay", "kpi": "Win Rate", "workflowType": "Drafting", "riskLevel": "Medium", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Statement Of Work Creation is weak when proposal creation teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Statement Of Work Creation comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Proposal operations owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "statement_of_work_creation_review_ready_rate", "baselineMetricDescription": "Share of statement of work creation records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, CLM, proposal tool, risk review notes", "collectionMethod": "Sample statement of work creation records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, CLM, proposal tool, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "High", "dataReadiness": "Mixed", "trigger": "A proposal, estimate, signed deal, or implementation plan needs a formal statement of work before delivery begins.", "requiredEvidence": [ "approved proposal or deal summary", "deliverables and quantities", "in-scope and out-of-scope boundaries", "assumptions and dependencies", "acceptance criteria", "timeline and milestones", "pricing and change-order rules", "legal or contract boundaries" ], "aiRole": "AI prepares the statement of work creation record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Proposal operations owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Proposal operations owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances statement of work creation from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Statement Of Work Creation does not have stable source records, owner fields, or status fields to sample.", "No accountable proposal creation owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 statement of work creation records, or all records from one proposal creation segment over 45 days", "pilotOwner": "Proposal operations owner", "pilotSuccessThreshold": "At least 90% of sampled statement of work creation records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Statement Of Work Creation is the proposal creation control for statement_of_work_creation_review_ready_rate, using docusign-clm, pandadoc-approvals, nist-ai-rmf as its source boundary and the workflow terms statement, of, work, creation. Its audit packet should carry statementofworkcreationSourceRecord, statementofworkcreationOwnerDecision, statementofworkcreationExceptionQueue, statementofworkcreationReviewOutcome, and statementofworkcreationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Proposal operations owner, exception status, and a safe next action for statement of work creation specifically.", "uniqueDataTest": "Audit 100 statement of work creation records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep statement of work creation separate from adjacent proposal creation workflows by requiring statement_of_work_creation_review_ready_rate, the Proposal operations owner review point, and the source boundary docusign-clm, pandadoc-approvals, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "docusign-clm", "pandadoc-approvals", "nist-ai-rmf" ] }, { "id": "estimate-generation", "name": "Estimate Generation", "url": "/workflow-library/estimate-generation", "businessFunction": "Proposal creation", "department": "Sales", "revenueLeak": "Proposal Delay", "kpi": "Win Rate", "workflowType": "Drafting", "riskLevel": "Medium", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Estimate generation is weak when rough estimates become customer-visible numbers before assumptions, exclusions, approval thresholds, and delivery capacity are reviewed. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in estimate generation. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "estimate_assumption_review_rate", "baselineMetricDescription": "Share of estimates with source request, assumption list, exclusion notes, approval threshold, margin or capacity flag, and final owner decision.", "sourceSystem": "proposal tool, CPQ or pricing sheet, CRM opportunity, historical estimates, delivery capacity plan, approval workflow", "collectionMethod": "Compare generated estimates to source assumptions, approval status, revision count, quote acceptance, and post-sale scope exceptions.", "leadingIndicators": [ "required assumption coverage", "review edit count", "pricing exception rate", "missing input exception count" ], "laggingIndicators": [ "estimate-to-actual variance", "quote acceptance rate", "margin exception rate" ], "implementationEffort": "High", "dataReadiness": "Messy", "trigger": "A buyer requests an estimate, quote, or budget range after enough discovery, site, service, or project information has been collected.", "requiredEvidence": [ "job details and buyer request", "approved scope and deliverables", "pricing basis or rate card", "site constraints and access notes", "assumptions and exclusions", "material, labor, or vendor inputs", "margin guardrails and approval threshold", "estimate owner and review checklist" ], "aiRole": "AI drafts estimate components from request details, historical work, templates, and pricing rules, then flags assumptions, exclusions, and approval thresholds for review.", "humanReviewPoint": "Sales, finance, or delivery owner reviews price, margin, scope, exclusions, delivery assumptions, discount, and any customer-visible estimate.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI produces a price or timeline that sales treats as approved.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "Pricing rules, approval thresholds, historical estimate records, or delivery assumptions are unavailable.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 50 estimates or all estimates from one sales segment over 45 days", "pilotOwner": "Deal desk owner", "pilotSuccessThreshold": "95% of estimates include approved assumptions and exclusions before sending, with fewer than 10% returned for missing scope or price rationale.", "workflowDistinction": "Estimate generation owns drafting estimate assumptions and approval packets, not creating full proposals, SOWs, or quote follow-up. Its proof object is estimate_assumption_review_rate from proposal tool, CPQ or pricing sheet, CRM opportunity, historical estimates, delivery capacity plan, approval workflow, with Deal desk owner accountable for review. Do not merge with proposal creation or statement of work creation. Estimate generation is centered on assumptions, price, and approval before a broader proposal document exists.", "uniqueDataTest": "Trace each estimate to source request, pricing rule, assumption, exclusion, approval threshold, approver, and sent-versus-revised status. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Do not merge with proposal creation or statement of work creation. Estimate generation is centered on assumptions, price, and approval before a broader proposal document exists.", "sourceRefs": [ "pandadoc-conditional-approvals", "salesforce-deal-desk", "nist-ai-rmf" ] }, { "id": "rfp-response-drafting", "name": "RFP Response Drafting", "url": "/workflow-library/rfp-response-drafting", "businessFunction": "Proposal creation", "department": "Sales", "revenueLeak": "Proposal Delay", "kpi": "Win Rate", "workflowType": "Drafting", "riskLevel": "Medium", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "RFP response drafting stays weak when RFP answers are drafted without a requirement matrix, evidence links, answer owner, compliance status, and deadline risk controls. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making RFP response drafting measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "rfp_answer_evidence_completion_rate", "baselineMetricDescription": "Share of RFP requirements with mapped answer, evidence link, owner, compliance status, review decision, attachment need, and deadline risk.", "sourceSystem": "RFP document, proposal tool, content library, CLM, approval workflow, evidence repository", "collectionMethod": "Compare requirement matrix to drafted answers, owner comments, evidence links, compliance review, submitted response, and post-submission corrections.", "leadingIndicators": [ "approved-answer match rate", "SME assignment completion", "compliance gap count", "review cycle completion" ], "laggingIndicators": [ "RFP response turnaround time", "submission defect count", "shortlist or win rate by response type" ], "implementationEffort": "High", "dataReadiness": "Mixed", "trigger": "An RFP, RFQ, security questionnaire, procurement questionnaire, or formal buyer request is received and the team decides to respond.", "requiredEvidence": [ "RFP document and deadline", "requirement matrix and evaluation criteria", "section owners and internal deadlines", "approved answer library", "evidence links and mandatory attachments", "pricing and commercial inputs", "legal, security, and compliance requirements", "final reviewer and submission owner" ], "aiRole": "AI decomposes RFP requirements, drafts answer candidates from approved content, flags missing evidence, and creates owner review tasks by section and deadline.", "humanReviewPoint": "Proposal owner, SME, legal, or security reviewer approves answer accuracy, proof claims, compliance language, attachments, and submission readiness.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI invents product capability, compliance posture, customer proof, or delivery commitment.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Approved content library, requirement matrix, reviewer owners, or evidence repository is unavailable.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "One RFP response with at least 50 requirements or the first 5 RFPs in one quarter", "pilotOwner": "Proposal manager", "pilotSuccessThreshold": "95% of requirements have owner-reviewed answer and evidence status before submission, with 0 unsupported compliance claims.", "workflowDistinction": "RFP response drafting handles drafting RFP answers against a requirement matrix with evidence and reviewer ownership. The audit sample checks trace each requirement to drafted answer, content source, evidence link, reviewer, compliance status, attachment, and submission decision. Keep separate from proposal creation and proposal compliance review. RFP drafting is requirement-matrix driven; proposal creation is broader, and compliance review checks risk before send.", "uniqueDataTest": "Trace each requirement to drafted answer, content source, evidence link, reviewer, compliance status, attachment, and submission decision. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from proposal creation and proposal compliance review. RFP drafting is requirement-matrix driven; proposal creation is broader, and compliance review checks risk before send.", "sourceRefs": [ "pandadoc-rfp", "pandadoc-approvals", "docusign-clm" ] }, { "id": "scope-of-work-review", "name": "Scope Of Work Review", "url": "/workflow-library/scope-of-work-review", "businessFunction": "Proposal creation", "department": "Sales", "revenueLeak": "Proposal Delay", "kpi": "Win Rate", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Scope of work review stays weak when SOWs leave ambiguity around deliverables, exclusions, assumptions, acceptance criteria, dates, dependencies, and customer responsibilities. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making scope of work review measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "sow_scope_exception_resolution_rate", "baselineMetricDescription": "Share of SOWs with resolved exceptions for deliverables, exclusions, assumptions, acceptance criteria, dates, dependencies, and approval status.", "sourceSystem": "SOW draft, CLM, proposal, delivery playbook, approval workflow, project plan", "collectionMethod": "Review SOW drafts against required scope fields, exception list, approver comments, kickoff readiness, and post-signature scope issues.", "leadingIndicators": [ "ambiguous deliverable count", "missing exclusion count", "dependency gap count", "delivery owner approval" ], "laggingIndicators": [ "scope change requests", "delivery kickoff exceptions", "margin variance due to scope" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A SOW, proposal, quote, or implementation scope is ready for review before signature, kickoff, or delivery handoff.", "requiredEvidence": [ "draft scope or SOW", "deliverables and quantities", "in-scope and out-of-scope boundaries", "assumptions and dependencies", "acceptance criteria", "timeline and milestones", "pricing and change-order language", "delivery, legal, and owner review rules" ], "aiRole": "AI checks SOW drafts for ambiguous deliverables, missing exclusions, assumptions, dependencies, acceptance criteria, and approval triggers.", "humanReviewPoint": "Proposal, legal, and delivery owners review scope, acceptance criteria, exclusions, dependencies, dates, and customer-visible commitments before signature or kickoff.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI normalizes ambiguous scope into a customer commitment.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "No standard SOW template, approval thresholds, or delivery owner review exists.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 40 SOWs or all SOWs from one service line over 60 days", "pilotOwner": "Delivery operations lead", "pilotSuccessThreshold": "95% of SOWs resolve critical scope exceptions before signature and 0 kickoff blockers come from unreviewed acceptance criteria or exclusions.", "workflowDistinction": "Scope of work review handles reviewing delivery scope and acceptance criteria before signature or kickoff. The audit sample checks trace each sow exception to draft section, source proposal, approver, revision, kickoff readiness, and post-signature issue status. Keep separate from proposal compliance review and statement of work creation. SOW review validates delivery scope; compliance review screens proposal risk, and creation drafts initial structure.", "uniqueDataTest": "Trace each SOW exception to draft section, source proposal, approver, revision, kickoff readiness, and post-signature issue status. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from proposal compliance review and statement of work creation. SOW review validates delivery scope; compliance review screens proposal risk, and creation drafts initial structure.", "sourceRefs": [ "docusign-clm", "pandadoc-approvals", "nist-ai-rmf" ] }, { "id": "pricing-approval-routing", "name": "Pricing Approval Routing", "url": "/workflow-library/pricing-approval-routing", "businessFunction": "Proposal creation", "department": "Sales", "revenueLeak": "Proposal Delay", "kpi": "Win Rate", "workflowType": "Routing", "riskLevel": "Medium", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Pricing Approval Routing is weak when proposal creation teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Pricing Approval Routing comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Proposal operations owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "pricing_approval_routing_review_ready_rate", "baselineMetricDescription": "Share of pricing approval routing records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, proposal tool, Salesforce", "collectionMethod": "Sample pricing approval routing records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, proposal tool, Salesforce.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A rep requests a discount, custom pricing, non-standard payment terms, low-margin deal, strategic account exception, or pricing promise outside approved authority.", "requiredEvidence": [ "pricing request and deal context", "discount level and margin impact", "pricing authority matrix", "product or service line", "payment terms and contract length", "strategic account or competitive context", "approver and timeout rule", "customer promise and supporting evidence" ], "aiRole": "AI prepares the pricing approval routing record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Proposal operations owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Proposal operations owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances pricing approval routing from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Pricing Approval Routing does not have stable source records, owner fields, or status fields to sample.", "No accountable proposal creation owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 pricing approval routing records, or all records from one proposal creation segment over 45 days", "pilotOwner": "Proposal operations owner", "pilotSuccessThreshold": "At least 90% of sampled pricing approval routing records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Pricing Approval Routing is the proposal creation control for pricing_approval_routing_review_ready_rate, using pandadoc-conditional-approvals, salesforce-deal-desk as its source boundary and the workflow terms pricing, approval, routing. Its audit packet should carry pricingapprovalroutingSourceRecord, pricingapprovalroutingOwnerDecision, pricingapprovalroutingExceptionQueue, pricingapprovalroutingReviewOutcome, and pricingapprovalroutingScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Proposal operations owner, exception status, and a safe next action for pricing approval routing specifically.", "uniqueDataTest": "Audit 100 pricing approval routing records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep pricing approval routing separate from adjacent proposal creation workflows by requiring pricing_approval_routing_review_ready_rate, the Proposal operations owner review point, and the source boundary pandadoc-conditional-approvals, salesforce-deal-desk. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "pandadoc-conditional-approvals", "salesforce-deal-desk" ] }, { "id": "proposal-personalization", "name": "Proposal Personalization", "url": "/workflow-library/proposal-personalization", "businessFunction": "Proposal creation", "department": "Sales", "revenueLeak": "Proposal Delay", "kpi": "Win Rate", "workflowType": "Drafting", "riskLevel": "Medium", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Proposal Personalization is weak when proposal creation teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Proposal Personalization comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Proposal operations owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "proposal_personalization_review_ready_rate", "baselineMetricDescription": "Share of proposal personalization records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, proposal tool, call intelligence, risk review notes", "collectionMethod": "Sample proposal personalization records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, proposal tool, call intelligence, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A proposal draft exists and needs buyer-specific framing before it is reviewed or sent.", "requiredEvidence": [ "proposal draft", "buyer priorities and discovery notes", "industry or segment context", "approved proof points and assets", "stakeholder concerns", "competitor or alternative context", "scope, pricing, and timeline boundaries", "proposal owner approval checklist" ], "aiRole": "AI prepares the proposal personalization record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Proposal operations owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Proposal operations owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances proposal personalization from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Proposal Personalization does not have stable source records, owner fields, or status fields to sample.", "No accountable proposal creation owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 proposal personalization records, or all records from one proposal creation segment over 45 days", "pilotOwner": "Proposal operations owner", "pilotSuccessThreshold": "At least 90% of sampled proposal personalization records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Proposal Personalization is the proposal creation control for proposal_personalization_review_ready_rate, using pandadoc-approvals, gong-call-intelligence, nist-ai-rmf as its source boundary and the workflow terms proposal, personalization. Its audit packet should carry proposalpersonalizationSourceRecord, proposalpersonalizationOwnerDecision, proposalpersonalizationExceptionQueue, proposalpersonalizationReviewOutcome, and proposalpersonalizationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Proposal operations owner, exception status, and a safe next action for proposal personalization specifically.", "uniqueDataTest": "Audit 100 proposal personalization records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep proposal personalization separate from adjacent proposal creation workflows by requiring proposal_personalization_review_ready_rate, the Proposal operations owner review point, and the source boundary pandadoc-approvals, gong-call-intelligence, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "pandadoc-approvals", "gong-call-intelligence", "nist-ai-rmf" ] }, { "id": "proposal-compliance-review", "name": "Proposal Compliance Review", "url": "/workflow-library/proposal-compliance-review", "businessFunction": "Proposal creation", "department": "Sales", "revenueLeak": "Proposal Delay", "kpi": "Win Rate", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 98, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Proposal review often happens too late, after a seller has already shaped buyer expectations. Legal, brand, procurement, privacy, and delivery risks sit inside a document that looks ready to send, but exceptions are buried in wording instead of exposed as review items.", "economicLogic": "The value is risk containment and cycle-time discipline. The workflow should catch proposal exceptions earlier, route them to the right approver, and reduce late rework without letting AI become the approval authority.", "baselineMetric": "proposal_exception_review_completion_rate", "baselineMetricDescription": "Share of proposal drafts with compliance, legal, privacy, brand, pricing, scope, and delivery exceptions identified, assigned, reviewed, and resolved before customer send.", "sourceSystem": "Proposal tool, CLM, approved clause library, pricing/CPQ, CRM opportunity fields, review comments", "collectionMethod": "Scan each draft against approved clauses, required disclosures, pricing rules, scope assumptions, comments, reviewer decisions, and send approval status.", "leadingIndicators": [ "exception detection rate", "review owner assignment", "late-stage rework count", "unresolved exception age" ], "laggingIndicators": [ "proposal approval cycle time", "post-send correction count", "legal or delivery escalation rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "The workflow starts when a proposal, quote, statement of work, RFP response, or renewal offer is ready for internal review before it is sent.", "requiredEvidence": [ "proposal draft", "source notes or discovery summary", "scope of work", "assumptions and exclusions", "pricing table", "payment terms", "delivery timeline", "client responsibilities", "approved template or policy" ], "aiRole": "AI reviews drafts for missing clauses, unsupported claims, regulated language, pricing exceptions, scope conflicts, and approval triggers, then routes exceptions by severity and owner. It does not mark a proposal approved.", "humanReviewPoint": "Legal, finance, delivery, brand, or sales leadership approves the specific exception type before the proposal can be sent, especially for critical legal, pricing, privacy, scope, or delivery commitments.", "evidenceBoundary": "Approval workflow sources support mechanics for routing and review. Compliance correctness depends on the company's policies, contracts, and regulated context.", "stopRules": [ "AI treats compliance review as approval.", "Rules are too broad and create review fatigue." ], "notReadyIf": [ "Approved clauses or review rules are not documented.", "Proposal send approval is not controlled.", "Reviewer decisions are not captured." ], "pilotDuration": "30 days", "pilotSampleSize": "First 30 proposal drafts requiring review or all proposals above the review threshold", "pilotOwner": "Revenue operations manager", "pilotSuccessThreshold": "At least 90% of flagged exceptions have owner, decision, and resolution before send; zero proposals are sent with unresolved critical exceptions in the pilot.", "workflowDistinction": "Proposal compliance review is a pre-send risk workflow. It evaluates a draft against approval and policy boundaries, rather than creating the proposal or following up after it is sent. The record should show exception type, severity, owner, and final human decision.", "uniqueDataTest": "Select proposals above the review threshold and verify each flagged exception has document location, rule source, severity, owner, decision, resolution, and send approval. Any critical exception without a human decision fails the pilot.", "duplicateGuard": "Keep this separate from proposal creation and offer alignment. Compliance review owns policy, clause, scope, and approval exceptions in a drafted proposal; creation owns draft assembly and offer alignment owns consistency with the commercial offer.", "sourceRefs": [ "pandadoc-approvals", "docusign-clm", "nist-ai-rmf" ] }, { "id": "crm-cleanup", "name": "CRM Cleanup", "url": "/workflow-library/crm-cleanup", "businessFunction": "CRM hygiene", "department": "Revenue Ops", "revenueLeak": "Pipeline Slippage", "kpi": "Pipeline Hygiene", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "RevOps", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "CRM cleanup is weak when duplicates, stale fields, owner drift, lifecycle errors, and consent issues make routing, reporting, and automation unreliable. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in CRM cleanup. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "crm_cleanup_approved_change_rate", "baselineMetricDescription": "Share of proposed CRM cleanup changes that include duplicate evidence, protected-field status, owner review, approval outcome, and post-change rework result.", "sourceSystem": "CRM duplicate jobs, data quality dashboard, automation logs, lifecycle fields, consent fields, owner history", "collectionMethod": "Sample proposed cleanup actions and compare source evidence to approval, change log, rejected changes, and downstream routing or report errors.", "leadingIndicators": [ "duplicate candidate count", "missing required field rate", "stale lifecycle status rate", "unused property count" ], "laggingIndicators": [ "routing exception reduction", "report trust score", "automation failure reduction" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "A weekly CRM hygiene review, migration prep, reporting issue, routing failure, or automation-readiness check finds records that may need cleanup.", "requiredEvidence": [ "CRM data standard", "record type and source system", "duplicate-risk signal", "missing critical fields", "last activity and last updated date", "record owner and lifecycle stage", "protected field list", "cleanup approver and change log" ], "aiRole": "AI builds a cleanup queue by finding duplicates, missing required fields, stale lifecycle values, owner conflicts, and automation-breaking records with evidence for each proposed correction.", "humanReviewPoint": "The CRM owner approves merges, deletes, owner changes, consent-sensitive updates, lifecycle changes, and any correction that affects reporting or routing.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI merges, deletes, or changes protected CRM fields without owner approval.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "CRM has no duplicate rules, protected-field list, or owner for data governance decisions.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "500 CRM records or all records flagged by one weekly data-quality job", "pilotOwner": "CRM operations owner", "pilotSuccessThreshold": "At least 95% of approved cleanup actions include source evidence and fewer than 5% require rollback or manual rework.", "workflowDistinction": "CRM cleanup owns cleaning CRM records with approval and rollback controls, not enriching accounts, normalizing one field, or logging rep activity. Its proof object is crm_cleanup_approved_change_rate from CRM duplicate jobs, data quality dashboard, automation logs, lifecycle fields, consent fields, owner history, with CRM operations owner accountable for review. Do not merge with duplicate contact cleanup or CRM field normalization. CRM cleanup is the broader controlled queue; those workflows address narrower duplicate or field-standardization motions.", "uniqueDataTest": "Trace each cleanup recommendation to duplicate evidence, field history, owner review, approval log, and post-change routing or reporting result. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Do not merge with duplicate contact cleanup or CRM field normalization. CRM cleanup is the broader controlled queue; those workflows address narrower duplicate or field-standardization motions.", "sourceRefs": [ "hubspot-data-quality", "salesforce-duplicate-management" ] }, { "id": "duplicate-contact-cleanup", "name": "Duplicate Contact Cleanup", "url": "/workflow-library/duplicate-contact-cleanup", "businessFunction": "CRM hygiene", "department": "Revenue Ops", "revenueLeak": "Pipeline Slippage", "kpi": "Pipeline Hygiene", "workflowType": "Workflow Support", "riskLevel": "Medium", "ownerRole": "RevOps", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Duplicate contact cleanup stays weak when duplicate contacts split activity, consent, ownership, lifecycle state, and attribution until routing and reporting become unreliable. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making duplicate contact cleanup measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "duplicate_contact_merge_approval_rate", "baselineMetricDescription": "Share of duplicate contact candidates with match evidence, protected fields, consent status, owner review, merge decision, and rollback or rework outcome.", "sourceSystem": "CRM duplicate rules, matching jobs, contact activity history, consent fields, owner history, merge log", "collectionMethod": "Sample duplicate candidates and compare suggested merge to approved merge, blocked merge, field conflict, rollback, and downstream routing result.", "leadingIndicators": [ "duplicate candidate volume", "high-confidence match rate", "owner conflict rate", "merge reversal count" ], "laggingIndicators": [ "duplicate outreach reduction", "contact history completeness", "reporting duplication reduction" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "A new import, form submission, sync event, or CRM hygiene review finds contacts or accounts that may represent the same person or company.", "requiredEvidence": [ "duplicate match key", "email, phone, name, company, and domain", "source system and created date", "activity history and open opportunities", "record owner", "consent and subscription status", "field survivorship rule", "merge approver" ], "aiRole": "AI identifies duplicate contact candidates, summarizes match evidence and field conflicts, flags protected fields, and prepares merge or no-merge recommendations for approval.", "humanReviewPoint": "CRM owner reviews merges, deletes, consent conflicts, customer records, owner changes, lifecycle changes, and any update affecting reporting or routing.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI merges contacts with different identities, consent status, owners, or account relationships.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Duplicate rules, protected fields, merge permissions, or rollback process are undefined.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 500 duplicate candidates or one weekly CRM duplicate job", "pilotOwner": "CRM operations owner", "pilotSuccessThreshold": "95% of approved merges include match evidence and protected-field review, with fewer than 3% requiring rollback or manual repair.", "workflowDistinction": "Duplicate contact cleanup handles reviewing contact-level duplicate merge candidates with protected-field and consent controls. The audit sample checks audit candidate pairs for match rule, field conflicts, consent, activity history, owner, merge decision, and rollback result. Keep separate from CRM cleanup and account data enrichment. Duplicate cleanup resolves identity conflicts; CRM cleanup is broader, and enrichment adds missing information.", "uniqueDataTest": "Audit candidate pairs for match rule, field conflicts, consent, activity history, owner, merge decision, and rollback result. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from CRM cleanup and account data enrichment. Duplicate cleanup resolves identity conflicts; CRM cleanup is broader, and enrichment adds missing information.", "sourceRefs": [ "salesforce-duplicate-management", "hubspot-data-quality" ] }, { "id": "crm-field-normalization", "name": "CRM Field Normalization", "url": "/workflow-library/crm-field-normalization", "businessFunction": "CRM hygiene", "department": "Revenue Ops", "revenueLeak": "Pipeline Slippage", "kpi": "Pipeline Hygiene", "workflowType": "Workflow Support", "riskLevel": "Medium", "ownerRole": "RevOps", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "CRM Field Normalization is weak when crm hygiene teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of CRM Field Normalization comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Revenue operations owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "crm_field_normalization_review_ready_rate", "baselineMetricDescription": "Share of crm field normalization records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce", "collectionMethod": "Sample crm field normalization records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "A CRM import, integration sync, report issue, routing failure, or scheduled data-quality review finds inconsistent field values.", "requiredEvidence": [ "approved field standard", "allowed values or picklist", "source priority rule", "raw field value", "record type and downstream dependency", "protected field list", "active opportunity flag", "review owner" ], "aiRole": "AI prepares the crm field normalization record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Revenue operations owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Revenue operations owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances crm field normalization from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "CRM Field Normalization does not have stable source records, owner fields, or status fields to sample.", "No accountable crm hygiene owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 crm field normalization records, or all records from one crm hygiene segment over 45 days", "pilotOwner": "Revenue operations owner", "pilotSuccessThreshold": "At least 90% of sampled crm field normalization records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "CRM Field Normalization is the crm hygiene control for crm_field_normalization_review_ready_rate, using hubspot-data-quality, salesforce-duplicate-management as its source boundary and the workflow terms crm, field, normalization. Its audit packet should carry crmfieldnormalizationSourceRecord, crmfieldnormalizationOwnerDecision, crmfieldnormalizationExceptionQueue, crmfieldnormalizationReviewOutcome, and crmfieldnormalizationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Revenue operations owner, exception status, and a safe next action for crm field normalization specifically.", "uniqueDataTest": "Audit 100 crm field normalization records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep crm field normalization separate from adjacent crm hygiene workflows by requiring crm_field_normalization_review_ready_rate, the Revenue operations owner review point, and the source boundary hubspot-data-quality, salesforce-duplicate-management. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-data-quality", "salesforce-duplicate-management" ] }, { "id": "stale-opportunity-cleanup", "name": "Stale Opportunity Cleanup", "url": "/workflow-library/stale-opportunity-cleanup", "businessFunction": "CRM hygiene", "department": "Revenue Ops", "revenueLeak": "Pipeline Slippage", "kpi": "Pipeline Hygiene", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "RevOps", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Stale Opportunity Cleanup is weak when crm hygiene teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Stale Opportunity Cleanup comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Revenue operations owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "stale_opportunity_cleanup_review_ready_rate", "baselineMetricDescription": "Share of stale opportunity cleanup records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce", "collectionMethod": "Sample stale opportunity cleanup records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A scheduled pipeline hygiene review finds open opportunities with old activity, outdated close dates, missing next steps, or stage age beyond the team standard.", "requiredEvidence": [ "opportunity stage", "stage age and last activity", "close date", "next step and due date", "owner", "amount and forecast category", "revive reason or loss reason", "manager approval rule" ], "aiRole": "AI prepares the stale opportunity cleanup record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Revenue operations owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Revenue operations owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances stale opportunity cleanup from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Stale Opportunity Cleanup does not have stable source records, owner fields, or status fields to sample.", "No accountable crm hygiene owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 stale opportunity cleanup records, or all records from one crm hygiene segment over 45 days", "pilotOwner": "Revenue operations owner", "pilotSuccessThreshold": "At least 90% of sampled stale opportunity cleanup records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Stale Opportunity Cleanup is the crm hygiene control for stale_opportunity_cleanup_review_ready_rate, using hubspot-stage-calculated-properties, salesforce-pipeline-inspection, salesforce-forecasting as its source boundary and the workflow terms stale, opportunity, cleanup. Its audit packet should carry staleopportunitycleanupSourceRecord, staleopportunitycleanupOwnerDecision, staleopportunitycleanupExceptionQueue, staleopportunitycleanupReviewOutcome, and staleopportunitycleanupScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Revenue operations owner, exception status, and a safe next action for stale opportunity cleanup specifically.", "uniqueDataTest": "Audit 100 stale opportunity cleanup records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep stale opportunity cleanup separate from adjacent crm hygiene workflows by requiring stale_opportunity_cleanup_review_ready_rate, the Revenue operations owner review point, and the source boundary hubspot-stage-calculated-properties, salesforce-pipeline-inspection, salesforce-forecasting. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-stage-calculated-properties", "salesforce-pipeline-inspection", "salesforce-forecasting" ] }, { "id": "crm-note-structuring", "name": "CRM Note Structuring", "url": "/workflow-library/crm-note-structuring", "businessFunction": "CRM hygiene", "department": "Revenue Ops", "revenueLeak": "Pipeline Slippage", "kpi": "Pipeline Hygiene", "workflowType": "Workflow Support", "riskLevel": "Medium", "ownerRole": "RevOps", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "CRM note structuring is weak when free-text CRM notes hide decision makers, objections, next steps, dates, commitments, and risks that managers need for review. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in CRM note structuring. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "crm_note_required_field_extraction_rate", "baselineMetricDescription": "Share of CRM notes converted into required structured fields such as stakeholder, objection, next step, date, commitment, risk, and follow-up owner.", "sourceSystem": "CRM notes, call intelligence transcript, email sync, opportunity fields, activity log", "collectionMethod": "Sample notes and compare extracted fields to source note, transcript, manager corrections, and downstream task or stage updates.", "leadingIndicators": [ "structured field fill rate", "owner correction rate", "next-step extraction", "risk or objection capture" ], "laggingIndicators": [ "handoff acceptance rate", "meeting prep quality", "pipeline review note completeness" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "A sales call, customer call, handoff, support conversation, or important email needs to be saved to the correct CRM record.", "requiredEvidence": [ "call transcript or raw note", "CRM record and opportunity", "buyer goal and pain", "timeline and urgency", "objections and blockers", "commitments and promised next step", "owner and due date", "fields used for forecast, handoff, or follow-up" ], "aiRole": "AI extracts structured fields from notes and transcripts, flags ambiguous commitments, drafts update suggestions, and routes uncertain or customer-visible implications to review.", "humanReviewPoint": "The deal owner or manager reviews commitments, stage-impacting updates, forecast implications, sensitive notes, and ambiguous next steps before CRM fields change.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI converts a vague note into a false commitment, stage change, or forecast signal.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "Notes are not linked to contacts, accounts, opportunities, or activity source records.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "200 recent CRM notes from one sales team over 30 days", "pilotOwner": "Sales operations manager", "pilotSuccessThreshold": "85% of sampled notes have required fields extracted or explicitly marked unavailable, with fewer than 5% manager-corrected critical errors.", "workflowDistinction": "CRM note structuring owns turning unstructured sales notes into reviewable CRM fields, not cleaning duplicates, enriching accounts, or logging activities automatically. Its proof object is crm_note_required_field_extraction_rate from CRM notes, call intelligence transcript, email sync, opportunity fields, activity log, with Sales operations manager accountable for review. Keep separate from CRM cleanup and CRM activity logging. Note structuring is about field extraction from unstructured evidence, not bulk data hygiene or event capture.", "uniqueDataTest": "Compare note text and call transcript to extracted fields, manager corrections, task creation, and any stage or forecast update. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Keep separate from CRM cleanup and CRM activity logging. Note structuring is about field extraction from unstructured evidence, not bulk data hygiene or event capture.", "sourceRefs": [ "gong-call-intelligence", "hubspot-data-quality", "nist-ai-rmf" ] }, { "id": "account-data-enrichment", "name": "Account Data Enrichment", "url": "/workflow-library/account-data-enrichment", "businessFunction": "CRM hygiene", "department": "Revenue Ops", "revenueLeak": "Pipeline Slippage", "kpi": "Pipeline Hygiene", "workflowType": "Workflow Support", "riskLevel": "Medium", "ownerRole": "RevOps", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Account Data Enrichment is weak when crm hygiene teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Account Data Enrichment comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Revenue operations owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "account_data_enrichment_review_ready_rate", "baselineMetricDescription": "Share of account data enrichment records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce, risk review notes", "collectionMethod": "Sample account data enrichment records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A new account is created, a key field is missing, a scoring or routing rule needs more context, or a scheduled enrichment refresh finds stale account data.", "requiredEvidence": [ "account domain and company name", "CRM account record", "approved enrichment fields", "source priority rule", "match confidence score", "overwrite and fill-empty rule", "suppression or opt-out status", "routing, scoring, or segmentation dependency" ], "aiRole": "AI prepares the account data enrichment record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Revenue operations owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Revenue operations owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances account data enrichment from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Account Data Enrichment does not have stable source records, owner fields, or status fields to sample.", "No accountable crm hygiene owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 account data enrichment records, or all records from one crm hygiene segment over 45 days", "pilotOwner": "Revenue operations owner", "pilotSuccessThreshold": "At least 90% of sampled account data enrichment records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Account Data Enrichment is the crm hygiene control for account_data_enrichment_review_ready_rate, using hubspot-data-quality, salesforce-lead-management, nist-ai-rmf as its source boundary and the workflow terms account, data, enrichment. Its audit packet should carry accountdataenrichmentSourceRecord, accountdataenrichmentOwnerDecision, accountdataenrichmentExceptionQueue, accountdataenrichmentReviewOutcome, and accountdataenrichmentScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Revenue operations owner, exception status, and a safe next action for account data enrichment specifically.", "uniqueDataTest": "Audit 100 account data enrichment records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep account data enrichment separate from adjacent crm hygiene workflows by requiring account_data_enrichment_review_ready_rate, the Revenue operations owner review point, and the source boundary hubspot-data-quality, salesforce-lead-management, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-data-quality", "salesforce-lead-management", "nist-ai-rmf" ] }, { "id": "pipeline-data-validation", "name": "Pipeline Data Validation", "url": "/workflow-library/pipeline-data-validation", "businessFunction": "CRM hygiene", "department": "Revenue Ops", "revenueLeak": "Pipeline Slippage", "kpi": "Pipeline Hygiene", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "RevOps", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Pipeline Data Validation is weak when crm hygiene teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Pipeline Data Validation comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Revenue operations owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "pipeline_data_validation_review_ready_rate", "baselineMetricDescription": "Share of pipeline data validation records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, Salesforce, HubSpot", "collectionMethod": "Sample pipeline data validation records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, Salesforce, HubSpot.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A weekly forecast cycle, pipeline review, stage change, close-date movement, or data-quality report finds opportunities with weak or missing evidence.", "requiredEvidence": [ "opportunity stage and stage definition", "stage age and last activity", "close date and close-date evidence", "amount basis", "next step and due date", "buyer commitment", "owner and forecast category", "manager review rule" ], "aiRole": "AI prepares the pipeline data validation record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Revenue operations owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Revenue operations owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances pipeline data validation from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Pipeline Data Validation does not have stable source records, owner fields, or status fields to sample.", "No accountable crm hygiene owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 pipeline data validation records, or all records from one crm hygiene segment over 45 days", "pilotOwner": "Revenue operations owner", "pilotSuccessThreshold": "At least 90% of sampled pipeline data validation records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Pipeline Data Validation is the crm hygiene control for pipeline_data_validation_review_ready_rate, using salesforce-pipeline-inspection, hubspot-forecast-tool, salesforce-forecasting as its source boundary and the workflow terms pipeline, data, validation. Its audit packet should carry pipelinedatavalidationSourceRecord, pipelinedatavalidationOwnerDecision, pipelinedatavalidationExceptionQueue, pipelinedatavalidationReviewOutcome, and pipelinedatavalidationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Revenue operations owner, exception status, and a safe next action for pipeline data validation specifically.", "uniqueDataTest": "Audit 100 pipeline data validation records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep pipeline data validation separate from adjacent crm hygiene workflows by requiring pipeline_data_validation_review_ready_rate, the Revenue operations owner review point, and the source boundary salesforce-pipeline-inspection, hubspot-forecast-tool, salesforce-forecasting. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "salesforce-pipeline-inspection", "hubspot-forecast-tool", "salesforce-forecasting" ] }, { "id": "crm-activity-logging", "name": "CRM Activity Logging", "url": "/workflow-library/crm-activity-logging", "businessFunction": "CRM hygiene", "department": "Revenue Ops", "revenueLeak": "Pipeline Slippage", "kpi": "Pipeline Hygiene", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "RevOps", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "CRM Activity Logging is weak when crm hygiene teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of CRM Activity Logging comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Revenue operations owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "crm_activity_logging_review_ready_rate", "baselineMetricDescription": "Share of crm activity logging records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, call intelligence", "collectionMethod": "Sample crm activity logging records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, call intelligence.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A call, email, meeting, text, or note is created and needs to be attached to the correct CRM contact, account, opportunity, or customer record.", "requiredEvidence": [ "activity type and timestamp", "participants and sender domain", "matched CRM contact, account, and opportunity", "call transcript or email thread", "privacy and domain-filter rule", "summary policy", "next step and owner", "duplicate activity check" ], "aiRole": "AI prepares the crm activity logging record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Revenue operations owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Revenue operations owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances crm activity logging from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "CRM Activity Logging does not have stable source records, owner fields, or status fields to sample.", "No accountable crm hygiene owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 crm activity logging records, or all records from one crm hygiene segment over 45 days", "pilotOwner": "Revenue operations owner", "pilotSuccessThreshold": "At least 90% of sampled crm activity logging records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "CRM Activity Logging is the crm hygiene control for crm_activity_logging_review_ready_rate, using hubspot-sales-automation, gong-call-intelligence, hubspot-data-quality as its source boundary and the workflow terms crm, activity, logging. Its audit packet should carry crmactivityloggingSourceRecord, crmactivityloggingOwnerDecision, crmactivityloggingExceptionQueue, crmactivityloggingReviewOutcome, and crmactivityloggingScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Revenue operations owner, exception status, and a safe next action for crm activity logging specifically.", "uniqueDataTest": "Audit 100 crm activity logging records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep crm activity logging separate from adjacent crm hygiene workflows by requiring crm_activity_logging_review_ready_rate, the Revenue operations owner review point, and the source boundary hubspot-sales-automation, gong-call-intelligence, hubspot-data-quality. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-sales-automation", "gong-call-intelligence", "hubspot-data-quality" ] }, { "id": "sales-pipeline-review", "name": "Sales Pipeline Review", "url": "/workflow-library/sales-pipeline-review", "businessFunction": "Pipeline management", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Sales pipeline review stays weak when pipeline meetings rely on rep narrative while stage age, close date movement, missing next steps, deal risk, and data quality exceptions remain unstructured. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making sales pipeline review measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "pipeline_review_exception_resolution_rate", "baselineMetricDescription": "Share of reviewed opportunities with stage age, next step, close date, amount movement, owner action, risk flag, and manager disposition recorded.", "sourceSystem": "CRM opportunities, pipeline inspection view, forecast tool, activity history, manager review notes", "collectionMethod": "Compare pipeline review briefs to manager dispositions, action completion, stage changes, forecast updates, and stale deal cleanup.", "leadingIndicators": [ "exception list completion", "stage movement summary", "no-next-step count", "manager decision capture" ], "laggingIndicators": [ "pipeline review time saved", "forecast correction rate", "stale deal reduction" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A weekly pipeline meeting, forecast call, manager review, or sales leadership update requires a current view of deal movement and risk.", "requiredEvidence": [ "pipeline snapshot", "changes since last review", "stage, amount, and close date", "last activity and next step", "deal owner notes", "risk signals", "forecast category", "manager review agenda" ], "aiRole": "AI prepares a pipeline review brief by surfacing stale next steps, stage-age exceptions, close-date movement, amount changes, missing activity, and data-quality flags.", "humanReviewPoint": "Sales manager reviews forecast implications, stage movement, deal strategy, owner commitments, and customer-facing next actions before changes are made.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI changes stage, forecast, or deal strategy without manager judgment.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "CRM stages, close dates, activity history, or manager review cadence are unreliable.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "All open opportunities for one sales team across four weekly pipeline reviews", "pilotOwner": "Sales manager", "pilotSuccessThreshold": "95% of flagged pipeline exceptions receive manager disposition and 85% of assigned owner actions are completed before the next review.", "workflowDistinction": "Sales pipeline review handles preparing the weekly manager meeting view across active opportunities, including stale deals, data gaps, risk flags, and owner actions. The audit sample checks audit the pipeline meeting roster for opportunity age, activity gap, date movement, amount change, risk theme, manager question, assigned owner action, and follow-through. Keep separate from forecast risk review and stage progression monitoring. Pipeline review is the manager meeting roster across many deals, not commit governance or single-field discipline.", "uniqueDataTest": "Audit the pipeline meeting roster for opportunity age, activity gap, date movement, amount change, risk theme, manager question, assigned owner action, and follow-through. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from forecast risk review and stage progression monitoring. Pipeline review is the manager meeting roster across many deals, not commit governance or single-field discipline.", "sourceRefs": [ "salesforce-pipeline-inspection", "hubspot-forecast-tool", "hubspot-stage-calculated-properties" ] }, { "id": "deal-risk-detection", "name": "Deal Risk Detection", "url": "/workflow-library/deal-risk-detection", "businessFunction": "Pipeline management", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Deals become risky before the CRM stage changes. Missing champions, no next step, long stage age, weak activity, competitor mentions, procurement silence, and unresolved objections may be present in calls and fields, but managers see the risk only after the close date slips.", "economicLogic": "The value is earlier intervention on pipeline that still has a chance. The workflow should identify risk reasons, assign owner action, and measure whether the risk was resolved, escalated, or became a slipped/lost deal.", "baselineMetric": "deal_risk_action_resolution_rate", "baselineMetricDescription": "Share of flagged deal risks with risk reason, source evidence, owner action, manager review, resolution status, and eventual stage, slip, win, or loss outcome captured.", "sourceSystem": "CRM opportunities, pipeline inspection, call intelligence, email/calendar activity, stage history", "collectionMethod": "Compare deal-risk flags to stage age, close-date changes, next steps, call topics, stakeholder coverage, manager action, resolution, and final outcome.", "leadingIndicators": [ "risk reason coverage", "manager review completion", "owner action created", "risk resolution age" ], "laggingIndicators": [ "slipped deal rate", "flagged deal win/loss rate", "forecast category correction" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A deal enters a review stage, changes forecast category, shows stale activity, loses buyer engagement, slips close date, or misses a required qualification signal.", "requiredEvidence": [ "opportunity stage and amount", "last activity and buyer engagement", "next step and deadline", "qualification evidence", "stakeholder and decision-process notes", "close-date movement", "forecast category", "manager escalation rule" ], "aiRole": "AI reviews opportunity fields, stage history, activity, call intelligence, stakeholder mentions, objections, and close-date movement to produce risk reasons and suggested coaching actions. It does not change forecast category or rep performance assessment on its own.", "humanReviewPoint": "Sales manager reviews critical risk flags, coaching action, forecast implication, customer-facing next step, and any risk reason based on ambiguous conversation evidence.", "evidenceBoundary": "Pipeline inspection and call intelligence sources support mechanics for detecting and inspecting risk signals. Prediction quality must be validated against deal outcomes.", "stopRules": [ "AI flags generic risk without a concrete source.", "Risk alerts punish reps instead of helping deal coaching." ], "notReadyIf": [ "Stage history is unreliable.", "Next steps are not captured.", "Manager risk review and action outcomes are not logged." ], "pilotDuration": "45 days", "pilotSampleSize": "Top 100 open opportunities by amount or all deals in one forecast segment", "pilotOwner": "Sales manager", "pilotSuccessThreshold": "At least 85% of flagged risks have a reviewed owner action; unresolved critical risks are visible before forecast submission or close-date movement.", "workflowDistinction": "Deal risk detection is a deal-level coaching and intervention workflow. It surfaces risk reasons before the deal slips or is lost. Pipeline forecasting may use the same signals, but forecasting is about period-level category confidence.", "uniqueDataTest": "Review flagged opportunities for risk reason, source evidence, stage age, close-date change, stakeholder coverage, next step, manager decision, owner action, risk resolution, and final outcome. Track false positives and missed losses.", "duplicateGuard": "Do not merge with pipeline forecasting. Deal risk detection owns individual opportunity risk reasons and coaching action; forecasting owns the aggregate forecast call and category submission.", "sourceRefs": [ "salesforce-pipeline-inspection", "gong-call-intelligence", "hubspot-stage-calculated-properties" ] }, { "id": "pipeline-forecasting", "name": "Pipeline Forecasting", "url": "/workflow-library/pipeline-forecasting", "businessFunction": "Pipeline management", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Forecast meetings waste time when the pipeline number depends on rep optimism, stale close dates, uninspected stage age, and missing next steps. Leaders need a forecast packet that separates committed revenue, at-risk deals, stale data, and human judgment.", "economicLogic": "The value is forecast discipline. The workflow should improve inspection quality by showing what changed, which deals are unsupported, and where manager review is needed before a forecast category influences hiring, cash, or board expectations.", "baselineMetric": "forecast_inspection_exception_resolution_rate", "baselineMetricDescription": "Share of forecasted opportunities with stage age, close date, next step, forecast category, amount, risk reason, manager review, and exception resolution captured before forecast submission.", "sourceSystem": "CRM opportunities, forecast tool, pipeline inspection, stage history, manager notes, sales activity", "collectionMethod": "Compare forecast category and amount to stage history, close date changes, next steps, activity, risk flags, manager decisions, and final period outcome.", "leadingIndicators": [ "stale close date count", "no-next-step forecast amount", "manager-reviewed exception rate", "forecast category change log" ], "laggingIndicators": [ "forecast accuracy", "slipped deal rate", "commit-to-close variance" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A weekly forecast cycle, month-end review, quarter-end inspection, or leadership forecast submission requires updated pipeline evidence.", "requiredEvidence": [ "opportunity amount", "current stage and stage exit evidence", "close date and close-date reason", "next mutual step", "buyer commitment", "last activity", "forecast category", "manager override reason" ], "aiRole": "AI prepares a forecast inspection packet by finding stale close dates, stage-age risk, missing next steps, category changes, activity gaps, and deal-level risk reasons. It does not submit the forecast or override manager judgment.", "humanReviewPoint": "Sales manager or revenue operations reviews forecast exceptions, category changes, commit calls, large-deal risk, and any narrative used for executive or board reporting.", "evidenceBoundary": "Forecasting and pipeline inspection sources support CRM mechanics. Forecast accuracy gains must be measured against actual period outcomes.", "stopRules": [ "AI creates a confident forecast narrative from incomplete CRM hygiene.", "Managers treat AI risk flags as final forecast calls." ], "notReadyIf": [ "Forecast categories are undefined.", "Stage history and close-date changes are not reliable.", "Manager review decisions are not captured." ], "pilotDuration": "One forecast cycle", "pilotSampleSize": "All forecasted opportunities in one sales team for one monthly or quarterly forecast cycle", "pilotOwner": "Revenue operations manager", "pilotSuccessThreshold": "At least 90% of forecast exceptions have owner decision before submission; opportunities without next step or stale close date are separated from clean forecast records.", "workflowDistinction": "Pipeline forecasting is an inspection workflow for forecast submission. It evaluates opportunity evidence, category changes, and risk before leadership relies on the number. Deal risk detection can feed it, but forecasting owns period-level commit quality.", "uniqueDataTest": "For one forecast cycle, review forecasted opportunities for category, close date changes, stage age, next step, activity, amount, risk flags, manager decision, and final period outcome. Separate data hygiene exceptions from true deal risk.", "duplicateGuard": "Keep this separate from deal risk detection and forecast risk review. Forecasting owns period-level forecast category evidence and submission readiness; deal risk detection owns individual deal risk signals.", "sourceRefs": [ "hubspot-forecast-tool", "salesforce-forecasting", "salesforce-pipeline-inspection" ] }, { "id": "stage-progression-monitoring", "name": "Stage Progression Monitoring", "url": "/workflow-library/stage-progression-monitoring", "businessFunction": "Pipeline management", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Workflow Support", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Stage progression monitoring stays weak when deals move stages without enough buyer evidence, skipped-stage approval, stage-age context, or correction path for false progression. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making stage progression monitoring measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "stage_progression_evidence_compliance_rate", "baselineMetricDescription": "Share of stage changes with required evidence, source activity, stage age, skipped-stage flag, manager approval, and correction outcome.", "sourceSystem": "CRM stage history, stage calculated properties, activity history, pipeline inspection view, forecast tool", "collectionMethod": "Compare stage changes to required fields, source activities, skipped-stage exceptions, manager corrections, and deal outcomes.", "leadingIndicators": [ "time-in-stage breach", "missing stage requirement", "stage regression count", "no-next-step in stage" ], "laggingIndicators": [ "stale opportunity reduction", "stage conversion clarity", "pipeline review exception reduction" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A rep changes opportunity stage, a deal exceeds expected stage age, or a weekly pipeline review finds stage movement without supporting evidence.", "requiredEvidence": [ "current stage", "proposed stage", "stage entry criteria", "stage exit criteria", "buyer evidence", "stage age", "required fields", "forecast impact" ], "aiRole": "AI reviews stage movements for missing evidence, skipped steps, stale stage age, activity mismatch, and forecast impact, then creates manager review tasks.", "humanReviewPoint": "Manager or deal owner reviews stage advancement, moving a deal backward, skipped stages, forecast impact, and buyer-facing next action.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI corrects or rolls back stage without manager review.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Stage definitions, required evidence, stage history, or manager correction process are not defined.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "All stage changes from one sales team over 60 days", "pilotOwner": "Sales operations manager", "pilotSuccessThreshold": "95% of stage changes include required evidence or approved exception, and 90% of flagged false progressions are corrected within 7 days.", "workflowDistinction": "Stage progression monitoring handles checking stage changes for required buyer evidence and correction workflows. The audit sample checks audit each stage change for prior stage, new stage, evidence, stage age, skipped-stage flag, manager decision, correction, and forecast impact. Keep separate from pipeline review and next-step enforcement. Stage progression monitors stage integrity; the others review pipeline broadly or enforce next action coverage.", "uniqueDataTest": "Audit each stage change for prior stage, new stage, evidence, stage age, skipped-stage flag, manager decision, correction, and forecast impact. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from pipeline review and next-step enforcement. Stage progression monitors stage integrity; the others review pipeline broadly or enforce next action coverage.", "sourceRefs": [ "hubspot-stage-calculated-properties", "salesforce-pipeline-inspection", "hubspot-forecast-tool" ] }, { "id": "lost-deal-analysis", "name": "Lost Deal Analysis", "url": "/workflow-library/lost-deal-analysis", "businessFunction": "Pipeline management", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Lost Deal Analysis is weak when pipeline management teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Lost Deal Analysis comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales operations manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "lost_deal_analysis_review_ready_rate", "baselineMetricDescription": "Share of lost deal analysis records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, Salesforce, call intelligence, HubSpot", "collectionMethod": "Sample lost deal analysis records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, Salesforce, call intelligence, HubSpot.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "An opportunity is closed lost, no-decision, delayed indefinitely, or removed from forecast and needs a useful reason before the learning is counted.", "requiredEvidence": [ "closed-lost opportunity", "CRM loss reason", "rep notes", "buyer feedback or interview", "competitor or status quo context", "pricing and scope history", "decision process notes", "manager review rule" ], "aiRole": "AI prepares the lost deal analysis record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales operations manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales operations manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances lost deal analysis from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Lost Deal Analysis does not have stable source records, owner fields, or status fields to sample.", "No accountable pipeline management owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 lost deal analysis records, or all records from one pipeline management segment over 45 days", "pilotOwner": "Sales operations manager", "pilotSuccessThreshold": "At least 90% of sampled lost deal analysis records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Lost Deal Analysis is the pipeline management control for lost_deal_analysis_review_ready_rate, using salesforce-pipeline-inspection, gong-call-intelligence, hubspot-forecast-tool as its source boundary and the workflow terms lost, deal, analysis. Its audit packet should carry lostdealanalysisSourceRecord, lostdealanalysisOwnerDecision, lostdealanalysisExceptionQueue, lostdealanalysisReviewOutcome, and lostdealanalysisScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales operations manager, exception status, and a safe next action for lost deal analysis specifically.", "uniqueDataTest": "Audit 100 lost deal analysis records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep lost deal analysis separate from adjacent pipeline management workflows by requiring lost_deal_analysis_review_ready_rate, the Sales operations manager review point, and the source boundary salesforce-pipeline-inspection, gong-call-intelligence, hubspot-forecast-tool. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "salesforce-pipeline-inspection", "gong-call-intelligence", "hubspot-forecast-tool" ] }, { "id": "sales-manager-weekly-review", "name": "Sales Manager Weekly Review", "url": "/workflow-library/sales-manager-weekly-review", "businessFunction": "Pipeline management", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Follow-Up", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Sales manager weekly review stays weak when weekly manager reviews lack a prepared exception agenda connecting rep activity, pipeline risk, prior commitments, coaching topics, and follow-through. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making sales manager weekly review measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "manager_review_commitment_followthrough_rate", "baselineMetricDescription": "Share of weekly review items with rep, exception reason, prior commitment, coaching topic, owner action, due date, and next-review status.", "sourceSystem": "CRM, activity history, pipeline inspection view, forecast tool, call intelligence, manager notes", "collectionMethod": "Compare generated review agenda to manager edits, rep commitments, completed actions, forecast changes, and unresolved exceptions.", "leadingIndicators": [ "exception brief completion", "decision capture", "owner assignment", "follow-up task completion" ], "laggingIndicators": [ "stale deal reduction", "forecast correction timeliness", "rep coaching action completion" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A weekly sales manager meeting, rep one-on-one, pipeline inspection, or forecast review needs a prepared agenda and follow-up from last week.", "requiredEvidence": [ "rep pipeline snapshot", "changes since last review", "activity and meeting data", "deal risk flags", "forecast changes", "open commitments from last week", "coaching focus", "manager review notes" ], "aiRole": "AI prepares manager agendas by surfacing rep-specific exceptions, prior commitments, pipeline risks, coaching prompts, and follow-up items from last review.", "humanReviewPoint": "Sales manager reviews coaching language, performance interpretation, forecast changes, compensation-sensitive conclusions, and customer-facing action items.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI creates performance judgments or coaching messages without manager context.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "CRM, activity history, prior commitments, or manager review notes are incomplete.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "4 weekly review cycles for one manager and their direct reports", "pilotOwner": "Sales manager", "pilotSuccessThreshold": "90% of review commitments have owner and due date, and 85% are completed or dispositioned before the next weekly review.", "workflowDistinction": "Sales manager weekly review handles preparing rep-specific manager review agendas with commitments and coaching controls. The audit sample checks audit review agenda item, source exception, prior commitment, manager edit, owner action, due date, and next-review status. Keep separate from sales pipeline review and sales activity reporting. Manager review is rep-coaching and commitment follow-through, not the full pipeline meeting or activity report.", "uniqueDataTest": "Audit review agenda item, source exception, prior commitment, manager edit, owner action, due date, and next-review status. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from sales pipeline review and sales activity reporting. Manager review is rep-coaching and commitment follow-through, not the full pipeline meeting or activity report.", "sourceRefs": [ "salesforce-pipeline-inspection", "hubspot-forecast-tool", "gong-call-intelligence" ] }, { "id": "renewal-pipeline-tracking", "name": "Renewal Pipeline Tracking", "url": "/workflow-library/renewal-pipeline-tracking", "businessFunction": "Pipeline management", "department": "Operations", "revenueLeak": "Retention Risk", "kpi": "Retention Rate", "workflowType": "Workflow Support", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Renewal Pipeline Tracking is weak when pipeline management teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Renewal Pipeline Tracking comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales operations manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "renewal_pipeline_tracking_review_ready_rate", "baselineMetricDescription": "Share of renewal pipeline tracking records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, Salesforce, HubSpot", "collectionMethod": "Sample renewal pipeline tracking records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, Salesforce, HubSpot.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A customer reaches a renewal window, contract data changes, health score changes, support risk appears, payment status changes, or a renewal forecast review is scheduled.", "requiredEvidence": [ "renewal date and source", "account owner", "renewal value and contract terms", "customer health signals", "product adoption", "support and payment status", "expansion, downsell, or churn risk", "commercial next step and escalation rule" ], "aiRole": "AI prepares the renewal pipeline tracking record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales operations manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales operations manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances renewal pipeline tracking from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Renewal Pipeline Tracking does not have stable source records, owner fields, or status fields to sample.", "No accountable pipeline management owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 renewal pipeline tracking records, or all records from one pipeline management segment over 45 days", "pilotOwner": "Sales operations manager", "pilotSuccessThreshold": "At least 90% of sampled renewal pipeline tracking records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Renewal Pipeline Tracking is the pipeline management control for renewal_pipeline_tracking_review_ready_rate, using salesforce-forecasting, hubspot-forecast-tool, salesforce-pipeline-inspection as its source boundary and the workflow terms renewal, pipeline, tracking. Its audit packet should carry renewalpipelinetrackingSourceRecord, renewalpipelinetrackingOwnerDecision, renewalpipelinetrackingExceptionQueue, renewalpipelinetrackingReviewOutcome, and renewalpipelinetrackingScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales operations manager, exception status, and a safe next action for renewal pipeline tracking specifically.", "uniqueDataTest": "Audit 100 renewal pipeline tracking records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep renewal pipeline tracking separate from adjacent pipeline management workflows by requiring renewal_pipeline_tracking_review_ready_rate, the Sales operations manager review point, and the source boundary salesforce-forecasting, hubspot-forecast-tool, salesforce-pipeline-inspection. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "salesforce-forecasting", "hubspot-forecast-tool", "salesforce-pipeline-inspection" ] }, { "id": "next-step-enforcement", "name": "Next Step Enforcement", "url": "/workflow-library/next-step-enforcement", "businessFunction": "Sales operations", "department": "Sales", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Follow-Up", "riskLevel": "Low", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Next step enforcement stays weak when opportunities sit open without a dated next step, or the CRM next step contradicts recent communication and stage reality. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making next step enforcement measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "opportunity_next_step_coverage_rate", "baselineMetricDescription": "Share of open opportunities with dated next step, owner, source evidence, stale-date status, stage alignment, and manager review outcome.", "sourceSystem": "CRM opportunity fields, activity history, stage history, pipeline inspection view, manager notes", "collectionMethod": "Compare flagged stale or missing next steps to manager disposition, updated task, customer response, and later stage movement.", "leadingIndicators": [ "missing next-step count", "overdue next-step count", "owner reassignment rate", "completion by due date" ], "laggingIndicators": [ "stalled record reduction", "cycle time improvement", "manager exception reduction" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "An open opportunity has no dated next step, the next-step date has passed, the stage changed without a clear action, or recent communication contradicts the CRM field.", "requiredEvidence": [ "opportunity stage and close date", "current next-step field", "last sales activity date", "call notes and email summaries", "buyer-stated action or decision date", "rep owner and manager owner", "deal value and forecast category", "prior stale-deal history" ], "aiRole": "AI detects missing, stale, or contradictory next steps by comparing CRM fields, activity history, stage age, and recent communication evidence.", "humanReviewPoint": "Sales manager reviews forecast implications, stage changes, rep accountability, and customer-visible next steps before any commitment or forecast change.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI creates a customer commitment or rep accountability action from weak evidence.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Next-step field, activity sync, stage rules, or manager review cadence is unreliable.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "All open opportunities in one sales team for four weekly reviews", "pilotOwner": "Sales manager", "pilotSuccessThreshold": "95% of open opportunities have a dated next step or documented exception, and 90% of stale next-step flags receive owner action before the next review.", "workflowDistinction": "Next step enforcement handles maintaining the single next-action field on each opportunity, including due date, source evidence, stale state, and owner confirmation. The audit sample checks audit each next-action field for due date, source activity, buyer-facing promise, stale marker, owner confirmation, manager override, and resulting task. Keep separate from sales pipeline review and stage progression monitoring. Next-step enforcement is field hygiene for the next action, not the full manager agenda or stage evidence control.", "uniqueDataTest": "Audit each next-action field for due date, source activity, buyer-facing promise, stale marker, owner confirmation, manager override, and resulting task. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from sales pipeline review and stage progression monitoring. Next-step enforcement is field hygiene for the next action, not the full manager agenda or stage evidence control.", "sourceRefs": [ "hubspot-stage-calculated-properties", "atlassian-priority-levels", "salesforce-pipeline-inspection" ] }, { "id": "client-onboarding", "name": "Client Onboarding", "url": "/workflow-library/client-onboarding", "businessFunction": "Client onboarding", "department": "Customer Success", "revenueLeak": "Time To Value", "kpi": "Time To Value", "workflowType": "Handoff", "riskLevel": "Low", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Client onboarding fails when signed-deal context does not become an executable start plan. Sales commitments, stakeholders, data needs, kickoff agenda, access requests, risks, and first value milestones often live in separate notes while the client waits.", "economicLogic": "The value is faster time-to-value with fewer preventable escalations. The workflow should prove that onboarding starts with the right inputs, named owners, risk flags, and milestone plan rather than asking the client to repeat what sales already learned.", "baselineMetric": "onboarding_launch_readiness_rate", "baselineMetricDescription": "Share of new clients with sales handoff, kickoff agenda, access/data requests, stakeholder map, implementation risks, first milestone, and owner assignments complete before kickoff.", "sourceSystem": "CRM closed-won opportunity, onboarding project tool, customer success platform, sales call notes, contract/SOW", "collectionMethod": "Compare closed-won records to onboarding project creation, kickoff agenda, access requests, owner assignments, risk log, milestone plan, and first value status.", "leadingIndicators": [ "handoff packet completeness", "access request completion", "kickoff agenda readiness", "risk flag review" ], "laggingIndicators": [ "time to first value", "onboarding delay rate", "first 30-day escalation rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "The workflow starts when a deal is marked closed-won, an agreement is signed, a deposit is received, or a new client is ready to enter onboarding.", "requiredEvidence": [ "signed agreement or order form", "proposal or scope summary", "client intake form", "stakeholder list", "access requirements", "billing or deposit status", "project template", "kickoff scheduling rules", "first milestone definition" ], "aiRole": "AI assembles the onboarding launch packet from closed-won data, contract/SOW, sales notes, stakeholder context, and onboarding templates, then flags missing access, unclear promises, and risk items. It does not approve scope or client-facing commitments.", "humanReviewPoint": "Customer success or delivery lead reviews scope, kickoff agenda, access dependencies, first milestone, risk flags, and any client-facing recap before the onboarding plan is shared.", "evidenceBoundary": "Customer onboarding sources support process mechanics. Time-to-value and delay reductions must be proven from the company's own onboarding cohorts.", "stopRules": [ "AI turns sales notes into an onboarding plan that includes unapproved promises.", "The workflow creates tasks without confirming client owner or access dependency." ], "notReadyIf": [ "Closed-won handoff fields are blank.", "Onboarding templates vary by owner with no standard gates.", "First value milestone is undefined." ], "pilotDuration": "45 days", "pilotSampleSize": "First 25 new clients or all new clients from one service line in a quarter", "pilotOwner": "Customer success operations lead", "pilotSuccessThreshold": "At least 90% of new clients have launch readiness fields complete before kickoff and fewer than 10% of pilots are delayed by missing access, owner, or scope context.", "workflowDistinction": "Client onboarding is the launch-readiness workflow after a deal is won. It turns sales, contract, and implementation inputs into a kickoff-ready plan. Customer success handoff is narrower around transferring relationship and account context from sales to CS.", "uniqueDataTest": "Audit new clients for closed-won handoff, contract/SOW match, kickoff agenda, stakeholder map, access requests, risk log, owner assignments, first milestone, and delay reason. Missing scope or access blockers should be visible before kickoff.", "duplicateGuard": "Keep this separate from client kickoff preparation and customer success handoff. Onboarding owns the broader launch plan and readiness gates; kickoff preparation owns the meeting packet; handoff owns sales-to-CS context transfer.", "sourceRefs": [ "hubspot-customer-onboarding", "hubspot-service-hub-onboarding" ] }, { "id": "onboarding-forms", "name": "Onboarding Forms", "url": "/workflow-library/onboarding-forms", "businessFunction": "Client onboarding", "department": "Customer Success", "revenueLeak": "Time To Value", "kpi": "Time To Value", "workflowType": "Handoff", "riskLevel": "Low", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Onboarding Forms is weak when client onboarding teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Onboarding Forms comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Client onboarding lead, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "onboarding_forms_review_ready_rate", "baselineMetricDescription": "Share of onboarding forms records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot", "collectionMethod": "Sample onboarding forms records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A new client signs, receives an onboarding form, submits intake answers, uploads documents, or leaves required onboarding information incomplete.", "requiredEvidence": [ "signed agreement or onboarding trigger", "intake form answers", "required field rules", "document upload checklist", "payment or billing status", "consent and security language", "owner and due date", "kickoff-readiness rule" ], "aiRole": "AI prepares the onboarding forms record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Client onboarding lead; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Client onboarding lead reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances onboarding forms from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Onboarding Forms does not have stable source records, owner fields, or status fields to sample.", "No accountable client onboarding owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 onboarding forms records, or all records from one client onboarding segment over 45 days", "pilotOwner": "Client onboarding lead", "pilotSuccessThreshold": "At least 90% of sampled onboarding forms records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Onboarding Forms is the client onboarding control for onboarding_forms_review_ready_rate, using hubspot-customer-onboarding, hubspot-service-hub-onboarding as its source boundary and the workflow terms onboarding, forms. Its audit packet should carry onboardingformsSourceRecord, onboardingformsOwnerDecision, onboardingformsExceptionQueue, onboardingformsReviewOutcome, and onboardingformsScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Client onboarding lead, exception status, and a safe next action for onboarding forms specifically.", "uniqueDataTest": "Audit 100 onboarding forms records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep onboarding forms separate from adjacent client onboarding workflows by requiring onboarding_forms_review_ready_rate, the Client onboarding lead review point, and the source boundary hubspot-customer-onboarding, hubspot-service-hub-onboarding. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-customer-onboarding", "hubspot-service-hub-onboarding" ] }, { "id": "client-kickoff-preparation", "name": "Client Kickoff Preparation", "url": "/workflow-library/client-kickoff-preparation", "businessFunction": "Client onboarding", "department": "Customer Success", "revenueLeak": "Time To Value", "kpi": "Time To Value", "workflowType": "Handoff", "riskLevel": "Low", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Kickoff meetings are often treated as a calendar event rather than a control point. Teams show up without a clear agenda, stakeholder roles, promised outcomes, access requests, known risks, or decisions needed from the client, which makes the first meeting feel repetitive and vague.", "economicLogic": "The value is cleaner project start. A better kickoff packet reduces wasted meeting time, prevents early blockers, and gives delivery a shared record of what must be confirmed before work begins. The pilot should measure avoided confusion, not claim that one meeting fixes the whole onboarding journey.", "baselineMetric": "kickoff_packet_decision_readiness_rate", "baselineMetricDescription": "Share of kickoff meetings with agenda, stakeholder roles, scope summary, required decisions, access/data requests, risk flags, and next-step owners complete before the meeting.", "sourceSystem": "CRM opportunity, contract/SOW, onboarding project, meeting agenda, customer success notes, access request tracker", "collectionMethod": "Compare kickoff agenda and packet fields to contract/SOW, sales notes, stakeholder list, access requests, meeting outcomes, and post-kickoff task creation.", "leadingIndicators": [ "agenda completeness", "stakeholder role coverage", "access request readiness", "risk item review" ], "laggingIndicators": [ "post-kickoff blocker rate", "kickoff rework tasks", "time from kickoff to first value task" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A kickoff meeting is scheduled or a client reaches kickoff-ready status after contract, intake, payment, access, and internal handoff checks.", "requiredEvidence": [ "signed scope and proposal", "intake answers and missing items", "stakeholder list and roles", "success criteria", "timeline and first milestone", "communication preferences", "known risks and dependencies", "post-meeting recap owner" ], "aiRole": "AI prepares the kickoff packet from sales notes, contract/SOW, stakeholder data, onboarding template, and risk history, then flags missing decisions or access needs. It does not set scope or commit to delivery dates without review.", "humanReviewPoint": "Implementation lead reviews agenda, scope summary, delivery assumptions, access requests, risk flags, and client-facing recap before the kickoff packet is used.", "evidenceBoundary": "Onboarding sources support structured setup and tasking. The effect on time-to-value depends on how reliably kickoff blockers are captured and removed.", "stopRules": [ "The kickoff packet repeats sales claims that delivery cannot support.", "The agenda is complete but does not name client decisions." ], "notReadyIf": [ "Kickoff agenda template is missing.", "Contract/SOW is not accessible.", "Client stakeholder roles are unknown." ], "pilotDuration": "30 days", "pilotSampleSize": "First 25 kickoff meetings or all kickoffs from one implementation team", "pilotOwner": "Implementation manager", "pilotSuccessThreshold": "At least 90% of kickoffs have a complete packet before the meeting and fewer than 10% require a second meeting due to missing scope, access, stakeholder, or decision context.", "workflowDistinction": "Client kickoff preparation is a meeting-readiness workflow. It produces the agenda and decision packet for the first client meeting, while broader onboarding covers the full launch plan and customer success handoff covers relationship context.", "uniqueDataTest": "Review kickoff packets for agenda, contract/SOW match, stakeholder roles, required decisions, access/data requests, risk flags, next-step owners, and post-meeting blockers. The test should reveal whether the meeting could actually start work.", "duplicateGuard": "Do not merge this with client onboarding. Kickoff preparation owns one meeting and its decision packet: agenda, client decisions, access asks, scope recap, risks, and next-step owners. Onboarding owns the larger launch path, milestones, and readiness gates after the meeting.", "sourceRefs": [ "hubspot-customer-onboarding", "hubspot-service-hub-onboarding" ] }, { "id": "new-customer-welcome-sequence", "name": "New Customer Welcome Sequence", "url": "/workflow-library/new-customer-welcome-sequence", "businessFunction": "Client onboarding", "department": "Customer Success", "revenueLeak": "Time To Value", "kpi": "Time To Value", "workflowType": "Handoff", "riskLevel": "Low", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "New Customer Welcome Sequence is weak when client onboarding teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of New Customer Welcome Sequence comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Client onboarding lead, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "new_customer_welcome_sequence_review_ready_rate", "baselineMetricDescription": "Share of new customer welcome sequence records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot", "collectionMethod": "Sample new customer welcome sequence records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A customer signs, pays, completes checkout, books kickoff, or enters a new-client status that should start onboarding communication.", "requiredEvidence": [ "signed offer and customer segment", "onboarding status", "first required action", "welcome message template", "suppression rules", "communication preference", "stalled-customer rule", "message approver" ], "aiRole": "AI prepares the new customer welcome sequence record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Client onboarding lead; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Client onboarding lead reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances new customer welcome sequence from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "New Customer Welcome Sequence does not have stable source records, owner fields, or status fields to sample.", "No accountable client onboarding owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 new customer welcome sequence records, or all records from one client onboarding segment over 45 days", "pilotOwner": "Client onboarding lead", "pilotSuccessThreshold": "At least 90% of sampled new customer welcome sequence records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "New Customer Welcome Sequence is the client onboarding control for new_customer_welcome_sequence_review_ready_rate, using hubspot-customer-onboarding, hubspot-sales-automation as its source boundary and the workflow terms new, customer, welcome, sequence. Its audit packet should carry newcustomerwelcomesequenceSourceRecord, newcustomerwelcomesequenceOwnerDecision, newcustomerwelcomesequenceExceptionQueue, newcustomerwelcomesequenceReviewOutcome, and newcustomerwelcomesequenceScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Client onboarding lead, exception status, and a safe next action for new customer welcome sequence specifically.", "uniqueDataTest": "Audit 100 new customer welcome sequence records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep new customer welcome sequence separate from adjacent client onboarding workflows by requiring new_customer_welcome_sequence_review_ready_rate, the Client onboarding lead review point, and the source boundary hubspot-customer-onboarding, hubspot-sales-automation. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-customer-onboarding", "hubspot-sales-automation" ] }, { "id": "implementation-handoff", "name": "Implementation Handoff", "url": "/workflow-library/implementation-handoff", "businessFunction": "Client onboarding", "department": "Customer Success", "revenueLeak": "Time To Value", "kpi": "Time To Value", "workflowType": "Handoff", "riskLevel": "Low", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Implementation Handoff is weak when client onboarding teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Implementation Handoff comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Client onboarding lead, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "implementation_handoff_review_ready_rate", "baselineMetricDescription": "Share of implementation handoff records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, CLM, project management or knowledge base", "collectionMethod": "Sample implementation handoff records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, CLM, project management or knowledge base.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A deal closes, a project is accepted, or implementation needs to begin planning before the customer kickoff.", "requiredEvidence": [ "signed agreement and proposal", "sales notes and call summaries", "buyer goal and urgency", "sold scope and not-sold boundaries", "stakeholder map", "risks, dependencies, and open questions", "first 30-day success criteria", "sales and implementation signoff" ], "aiRole": "AI prepares the implementation handoff record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Client onboarding lead; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Client onboarding lead reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances implementation handoff from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Implementation Handoff does not have stable source records, owner fields, or status fields to sample.", "No accountable client onboarding owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 implementation handoff records, or all records from one client onboarding segment over 45 days", "pilotOwner": "Client onboarding lead", "pilotSuccessThreshold": "At least 90% of sampled implementation handoff records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Implementation Handoff is the client onboarding control for implementation_handoff_review_ready_rate, using hubspot-customer-onboarding, docusign-clm, atlassian-change-record as its source boundary and the workflow terms implementation, handoff. Its audit packet should carry implementationhandoffSourceRecord, implementationhandoffOwnerDecision, implementationhandoffExceptionQueue, implementationhandoffReviewOutcome, and implementationhandoffScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Client onboarding lead, exception status, and a safe next action for implementation handoff specifically.", "uniqueDataTest": "Audit 100 implementation handoff records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep implementation handoff separate from adjacent client onboarding workflows by requiring implementation_handoff_review_ready_rate, the Client onboarding lead review point, and the source boundary hubspot-customer-onboarding, docusign-clm, atlassian-change-record. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-customer-onboarding", "docusign-clm", "atlassian-change-record" ] }, { "id": "access-request-collection", "name": "Access Request Collection", "url": "/workflow-library/access-request-collection", "businessFunction": "Client onboarding", "department": "Customer Success", "revenueLeak": "Time To Value", "kpi": "Time To Value", "workflowType": "Handoff", "riskLevel": "Low", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 92, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Access request collection is weak when delivery starts before required logins, permissions, owner approvals, and sensitive-access boundaries are collected and reviewed. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in access request collection. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "access_readiness_clearance_rate", "baselineMetricDescription": "Share of required access requests with system, role, approver, sensitivity level, delivery dependency, grant status, and review outcome before kickoff.", "sourceSystem": "onboarding checklist, ticketing system, identity provider, project plan, client intake form", "collectionMethod": "Compare required access list to granted permissions, missing approvals, blocker age, sensitivity tags, and kickoff readiness decision.", "leadingIndicators": [ "required access identified", "request submitted", "approval received", "verification completed" ], "laggingIndicators": [ "start delay due to access", "blocked task count", "time to first deliverable" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A new project needs client system access, tool permissions, delegated accounts, files, portals, APIs, or admin approval before implementation can proceed.", "requiredEvidence": [ "system or tool requested", "access purpose", "permission scope", "credential or account owner", "least-privilege rule", "secure collection method", "approval owner", "expiration and deprovisioning rule" ], "aiRole": "AI builds an access readiness list from project scope and intake forms, identifies missing grants and approvers, and drafts focused client or internal request messages.", "humanReviewPoint": "The delivery lead reviews sensitive systems, permission level, credential handling, client-facing requests, and whether kickoff can proceed with missing access.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI asks for credentials or excessive permissions in an unsafe or overbroad way.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "Project scope, required systems, permission levels, or approved request channels are undefined.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "All access items for the next 25 onboarding projects or one implementation pod over 45 days", "pilotOwner": "Implementation manager", "pilotSuccessThreshold": "95% of required access items have grant, owner, or blocker status before kickoff and 0 sensitive credentials are requested in unsafe channels.", "workflowDistinction": "Access request collection owns collecting access readiness evidence for implementation, not collecting all client data or tracking generic onboarding checklist completion. Its proof object is access_readiness_clearance_rate from onboarding checklist, ticketing system, identity provider, project plan, client intake form, with Implementation manager accountable for review. Keep separate from client data collection and onboarding checklist tracking. Access collection is specifically about permissions and sensitive system readiness.", "uniqueDataTest": "Audit each project for required system, permission level, approver, grant date, blocker owner, sensitivity flag, and kickoff decision. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Keep separate from client data collection and onboarding checklist tracking. Access collection is specifically about permissions and sensitive system readiness.", "sourceRefs": [ "atlassian-priority-levels", "atlassian-change-record", "nist-ai-rmf" ] }, { "id": "onboarding-checklist-tracking", "name": "Onboarding Checklist Tracking", "url": "/workflow-library/onboarding-checklist-tracking", "businessFunction": "Client onboarding", "department": "Customer Success", "revenueLeak": "Time To Value", "kpi": "Time To Value", "workflowType": "Handoff", "riskLevel": "Low", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Onboarding Checklist Tracking is weak when client onboarding teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Onboarding Checklist Tracking comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Client onboarding lead, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "onboarding_checklist_tracking_review_ready_rate", "baselineMetricDescription": "Share of onboarding checklist tracking records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, learning platform", "collectionMethod": "Sample onboarding checklist tracking records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, learning platform.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A new client signs, a kickoff date is scheduled, or an onboarding checklist item becomes overdue or blocks the first delivery milestone.", "requiredEvidence": [ "signed agreement and sold scope", "onboarding checklist", "required vs optional item rules", "client contact and internal owner", "due dates and kickoff date", "uploaded documents and access status", "missing-item history", "implementation lead signoff" ], "aiRole": "AI prepares the onboarding checklist tracking record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Client onboarding lead; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Client onboarding lead reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances onboarding checklist tracking from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Onboarding Checklist Tracking does not have stable source records, owner fields, or status fields to sample.", "No accountable client onboarding owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 onboarding checklist tracking records, or all records from one client onboarding segment over 45 days", "pilotOwner": "Client onboarding lead", "pilotSuccessThreshold": "At least 90% of sampled onboarding checklist tracking records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Onboarding Checklist Tracking is the client onboarding control for onboarding_checklist_tracking_review_ready_rate, using hubspot-customer-onboarding, learnupon-learning-paths as its source boundary and the workflow terms onboarding, checklist, tracking. Its audit packet should carry onboardingchecklisttrackingSourceRecord, onboardingchecklisttrackingOwnerDecision, onboardingchecklisttrackingExceptionQueue, onboardingchecklisttrackingReviewOutcome, and onboardingchecklisttrackingScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Client onboarding lead, exception status, and a safe next action for onboarding checklist tracking specifically.", "uniqueDataTest": "Audit 100 onboarding checklist tracking records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep onboarding checklist tracking separate from adjacent client onboarding workflows by requiring onboarding_checklist_tracking_review_ready_rate, the Client onboarding lead review point, and the source boundary hubspot-customer-onboarding, learnupon-learning-paths. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-customer-onboarding", "learnupon-learning-paths" ] }, { "id": "client-data-collection", "name": "Client Data Collection", "url": "/workflow-library/client-data-collection", "businessFunction": "Client onboarding", "department": "Customer Success", "revenueLeak": "Time To Value", "kpi": "Time To Value", "workflowType": "Handoff", "riskLevel": "Medium", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Client data collection is weak when onboarding collects incomplete, excessive, or unclear client inputs, causing rework, privacy risk, and delayed delivery. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in client data collection. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "client_input_completeness_review_rate", "baselineMetricDescription": "Share of required client inputs with field owner, completeness status, sensitivity label, clarification need, storage location, and delivery-readiness decision.", "sourceSystem": "client intake form, secure upload folder, CRM or project record, onboarding checklist, delivery requirements", "collectionMethod": "Compare required input list to submitted files, missing fields, sensitivity labels, clarification tasks, and first-milestone readiness.", "leadingIndicators": [ "data package completeness", "format validation pass", "missing field count", "rework request count" ], "laggingIndicators": [ "delivery delay due to data", "data-related defect count", "time to first deliverable" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "A client submits an intake form, uploads documents, grants access, or reaches an onboarding deadline with required information still missing.", "requiredEvidence": [ "intake form responses", "required data checklist", "uploaded files and links", "access credentials status without storing secrets in plain text", "client role and contact owner", "scope and service package", "privacy or compliance requirements", "implementation owner review status" ], "aiRole": "AI checks submitted client inputs against delivery requirements, flags missing or unclear items, labels sensitivity, and drafts focused clarification requests.", "humanReviewPoint": "The delivery lead reviews sensitive data, unclear answers, excessive collection, first-milestone readiness, and any client-facing request for additional information.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI requests unnecessary sensitive data or accepts unclear inputs as complete.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "Delivery requirements, approved storage, sensitivity labels, or owner review rules are undefined.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 30 onboarding clients or one implementation cohort over 60 days", "pilotOwner": "Client onboarding lead", "pilotSuccessThreshold": "90% of required inputs are complete or assigned before kickoff and 0 sensitive-data requests use unapproved channels.", "workflowDistinction": "Client data collection owns checking client-provided inputs for completeness and sensitivity, not collecting access permissions or tracking generic checklist items. Its proof object is client_input_completeness_review_rate from client intake form, secure upload folder, CRM or project record, onboarding checklist, delivery requirements, with Client onboarding lead accountable for review. Keep separate from access request collection and onboarding checklist tracking. This workflow controls information completeness and sensitivity, not permissions or task progress.", "uniqueDataTest": "Audit each client packet for required input, owner, submitted evidence, sensitivity label, clarification task, storage location, and readiness decision. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Keep separate from access request collection and onboarding checklist tracking. This workflow controls information completeness and sensitivity, not permissions or task progress.", "sourceRefs": [ "hubspot-customer-onboarding", "microsoft-syntex", "nist-ai-rmf" ] }, { "id": "project-status-updates", "name": "Project Status Updates", "url": "/workflow-library/project-status-updates", "businessFunction": "Delivery operations", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Project status updates stays weak when status updates summarize activity but miss decision needs, blockers, client promises, scope changes, owner commitments, and stale tasks. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making project status updates measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "project_update_decision_readiness_rate", "baselineMetricDescription": "Share of project updates with progress, blocker, risk, owner, client commitment, decision need, and next action accepted by the project owner.", "sourceSystem": "project management tool, client communication log, ticketing queue, meeting notes, risk register", "collectionMethod": "Compare draft updates to project tasks, blockers, owner edits, client replies, decision logs, and late-risk exceptions.", "leadingIndicators": [ "source-linked update sections", "owner correction rate", "blocker coverage", "decision coverage" ], "laggingIndicators": [ "stakeholder follow-up questions", "missed blocker escalation", "project review time saved" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A weekly reporting cadence, milestone change, blocker, overdue task, client request, or delivery owner request starts the workflow.", "requiredEvidence": [ "Current project plan, milestone list, and due dates", "Task status, owner updates, and recently completed work", "Open blockers, risks, decision requests, and dependencies", "Client commitments, scope notes, budget notes, and timeline changes", "Approved status template and audience rules", "Delivery owner, approver, and communication channel" ], "aiRole": "AI drafts status updates from tasks, blockers, risks, client messages, and owner notes, then flags missing decisions, stale tasks, and client-impacting changes.", "humanReviewPoint": "Project owner reviews client-facing language, commitments, scope changes, blockers, delivery risk, and any request for decision before sending.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI sends a status update that hides risk or creates an unapproved commitment.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Project tasks, blockers, risks, or owner fields are not maintained.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 60 weekly project updates across one delivery pod", "pilotOwner": "Project manager", "pilotSuccessThreshold": "90% of updates are owner-approved before sending and 95% of blocker or decision items have named owners.", "workflowDistinction": "Project status updates handles creating owner-approved project updates with blockers, decisions, risks, and client-impact controls. The audit sample checks audit update source tasks, blocker status, risk, client commitment, owner edit, decision request, sent status, and follow-up. Keep separate from delivery handoff notes and meeting decision logs. Status updates report current project state; handoffs transfer ownership and decision logs record meeting outcomes.", "uniqueDataTest": "Audit update source tasks, blocker status, risk, client commitment, owner edit, decision request, sent status, and follow-up. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from delivery handoff notes and meeting decision logs. Status updates report current project state; handoffs transfer ownership and decision logs record meeting outcomes.", "sourceRefs": [ "atlassian-priority-levels", "hubspot-service-hub-onboarding", "nist-ai-rmf" ] }, { "id": "task-intake-triage", "name": "Task Intake Triage", "url": "/workflow-library/task-intake-triage", "businessFunction": "Delivery operations", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Routing", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Task intake triage stays weak when internal requests enter work queues without impact, urgency, owner, dependency, missing information, and approval boundaries. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making task intake triage measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "task_intake_first_triage_accuracy_rate", "baselineMetricDescription": "Share of incoming tasks triaged with request type, impact, urgency, owner queue, dependency, missing-info status, and final disposition.", "sourceSystem": "task intake form, project management tool, ticketing system, approval workflow, priority rules", "collectionMethod": "Compare AI triage recommendation to final owner, reroute, priority change, missing-info request, and completion or rejection status.", "leadingIndicators": [ "complete intake rate", "clarification request count", "duplicate task detection", "priority assignment rate" ], "laggingIndicators": [ "time to assignment", "task cycle time", "rework due to unclear intake" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A new internal request, client request, Slack message, form submission, email, or project task enters the intake queue.", "requiredEvidence": [ "Request description and source channel", "Requester, client, project, due date, and business reason", "Impact, urgency, affected users, and customer-visible risk", "Estimated effort, dependencies, and current owner capacity", "Existing scope, SLA, roadmap, or delivery commitments", "Triage rules and required intake fields" ], "aiRole": "AI classifies task requests by type, impact, urgency, dependency, missing information, and owner queue, while flagging approval-sensitive or ambiguous cases.", "humanReviewPoint": "Operations owner reviews high-impact, ambiguous, cross-functional, approval-sensitive, customer-facing, or capacity-changing tasks before assignment.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI routes work that should be declined, scoped, or approved before execution.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Intake fields, priority rules, owner queues, or approval thresholds are not defined.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 300 task intake items or all items in one intake queue over 30 days", "pilotOwner": "Operations coordinator", "pilotSuccessThreshold": "90% first-triage accuracy and 100% human review for ambiguous, high-impact, or approval-sensitive tasks.", "workflowDistinction": "Task intake triage handles classifying incoming internal tasks into owner queues with impact, urgency, dependency, and missing-info controls. The audit sample checks audit request type, impact, urgency, dependency, missing information, owner queue, reroute, priority change, and final disposition. Keep separate from service ticket routing and client request prioritization. Task intake triage handles internal work intake, not customer service queues or account-sensitive requests.", "uniqueDataTest": "Audit request type, impact, urgency, dependency, missing information, owner queue, reroute, priority change, and final disposition. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from service ticket routing and client request prioritization. Task intake triage handles internal work intake, not customer service queues or account-sensitive requests.", "sourceRefs": [ "atlassian-priority-levels", "atlassian-change-record" ] }, { "id": "service-ticket-routing", "name": "Service Ticket Routing", "url": "/workflow-library/service-ticket-routing", "businessFunction": "Delivery operations", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Routing", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Service ticket routing stays weak when service tickets are routed from incomplete summaries or customer-stated urgency rather than issue type, impact, SLA, account context, and missing information. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making service ticket routing measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "ticket_first_route_accuracy_rate", "baselineMetricDescription": "Share of service tickets routed correctly on first assignment with issue type, impact, SLA, account tier, missing-info status, and escalation decision.", "sourceSystem": "ticketing system, CRM account record, SLA rules, service queue, knowledge base", "collectionMethod": "Compare suggested route to final owner, reroute count, SLA breach, missing-info request, escalation status, and resolution outcome.", "leadingIndicators": [ "request type completeness", "impact/urgency coverage", "first queue acceptance", "reassignment count" ], "laggingIndicators": [ "time to first response", "time to resolution", "SLA breach reduction" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A new support ticket, email, portal request, chat transcript, or escalated service request enters the queue.", "requiredEvidence": [ "Ticket text, attachments, and customer history", "Product, service line, account tier, and affected users", "Impact, urgency, symptoms, and business interruption", "SLA policy, priority matrix, and escalation rules", "Team ownership rules and current queue capacity", "Known incidents, recent changes, and knowledge-base matches" ], "aiRole": "AI summarizes ticket evidence, classifies issue type and impact, suggests owner queue, flags missing information, and escalates high-risk or ambiguous tickets.", "humanReviewPoint": "Support lead reviews VIP, security, billing, SLA-risk, ambiguous, multi-owner, and high-impact tickets before priority or customer commitment changes.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI routes sensitive or high-impact tickets to the wrong team or creates an unsupported customer promise.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Ticket categories, owner queues, SLA rules, or account context are unavailable.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 300 service tickets or all tickets in one queue over 30 days", "pilotOwner": "Support operations manager", "pilotSuccessThreshold": "90% first-route accuracy and 100% human review for VIP, security, billing, SLA-risk, or ambiguous tickets.", "workflowDistinction": "Service ticket routing handles assigning service tickets to the right owner queue with impact, SLA, and missing-info controls. The audit sample checks audit ticket summary, issue type, impact, account tier, sla, owner queue, reroute, missing-info request, and resolution owner. Keep separate from client request prioritization and support ticket summarization. Routing assigns the service owner; prioritization weighs business importance, and summarization condenses ticket history.", "uniqueDataTest": "Audit ticket summary, issue type, impact, account tier, SLA, owner queue, reroute, missing-info request, and resolution owner. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from client request prioritization and support ticket summarization. Routing assigns the service owner; prioritization weighs business importance, and summarization condenses ticket history.", "sourceRefs": [ "atlassian-priority-levels", "hubspot-service-hub-onboarding" ] }, { "id": "quality-assurance-review", "name": "Quality Assurance Review", "url": "/workflow-library/quality-assurance-review", "businessFunction": "Delivery operations", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Quality assurance review stays weak when deliverables pass checklists while acceptance criteria, defects, client context, release approval, and subjective quality calls remain unresolved. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making quality assurance review measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "qa_exception_resolution_rate", "baselineMetricDescription": "Share of deliverables with reviewed checklist, acceptance criteria, defect severity, rework owner, release approval, and post-release issue outcome.", "sourceSystem": "QA checklist, project management tool, acceptance criteria, defect tracker, client requirement record", "collectionMethod": "Sample QA reviews and compare checklist items, defects, owner approvals, release decisions, rework, and post-release issues.", "leadingIndicators": [ "QA checklist completion", "defect category count", "rework owner assigned", "approval before delivery" ], "laggingIndicators": [ "customer-reported defect rate", "rework cycle time", "repeat defect reduction" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A deliverable moves to internal review, pre-client delivery, milestone approval, final QA, or release-ready status.", "requiredEvidence": [ "Deliverable link, version, and owner", "Scope, acceptance criteria, and client requirements", "QA checklist, brand rules, and compliance requirements", "Known defects, previous feedback, and unresolved comments", "Release channel, client approver, and due date", "Review owner and final release authority" ], "aiRole": "AI checks deliverables against acceptance criteria and QA checklist, summarizes defects, flags missing evidence, and prepares rework tasks for owner review.", "humanReviewPoint": "QA or delivery owner approves subjective quality, release decision, client-facing notes, regulated claims, and unresolved checklist exceptions.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI marks a deliverable ready when human acceptance criteria or subjective quality judgment is unresolved.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Acceptance criteria, QA checklist, defect severity rules, or release owner are undefined.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 50 deliverables entering QA or all QA reviews in one delivery pod over 45 days", "pilotOwner": "QA lead", "pilotSuccessThreshold": "95% of critical QA exceptions receive owner disposition before release and fewer than 10% of released items reopen for missed checklist evidence.", "workflowDistinction": "Quality assurance review handles reviewing deliverable quality exceptions against acceptance criteria before release. The audit sample checks audit each deliverable for acceptance criteria, checklist status, defect severity, owner, release approval, rework, and post-release issue. Keep separate from resource planning and project status updates. QA review controls release quality; the others manage capacity or status communication.", "uniqueDataTest": "Audit each deliverable for acceptance criteria, checklist status, defect severity, owner, release approval, rework, and post-release issue. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from resource planning and project status updates. QA review controls release quality; the others manage capacity or status communication.", "sourceRefs": [ "atlassian-change-record", "nist-ai-rmf", "iso-30401" ] }, { "id": "delivery-handoff-notes", "name": "Delivery Handoff Notes", "url": "/workflow-library/delivery-handoff-notes", "businessFunction": "Delivery operations", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Handoff", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Delivery handoff notes is weak when handoffs lose open risks, client promises, support obligations, defects, access details, and owner confirmation between teams. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in delivery handoff notes. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "handoff_completeness_acceptance_rate", "baselineMetricDescription": "Share of handoff packets accepted by the receiving owner with completed work, open work, risks, client promises, access notes, and next owner confirmed.", "sourceSystem": "project management tool, client communication log, ticketing system, QA checklist, knowledge base", "collectionMethod": "Sample handoff packets and compare required fields to receiver acceptance, reopened work, support escalations, and post-handoff rework.", "leadingIndicators": [ "context field completion", "receiver acceptance", "clarification request count", "risk/decision coverage" ], "laggingIndicators": [ "handoff delay", "customer repeat-question rate", "delivery rework due to missing context" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A project phase ends, work moves from one owner to another, delivery shifts to support, or a client deliverable is ready for ongoing ownership.", "requiredEvidence": [ "Completed work, deliverables, and version links", "Open tasks, risks, defects, and unresolved decisions", "Scope promises, client expectations, and support obligations", "Access notes, system dependencies, and documentation links", "Next milestone, due date, and receiving owner", "Approval status from sending and receiving owners" ], "aiRole": "AI drafts a concise handoff packet from project tasks, client messages, QA notes, and support obligations, then flags missing owners, risks, and unresolved promises.", "humanReviewPoint": "The sending and receiving owners approve open risks, client expectations, support obligations, defects, access details, and ownership transfer.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI omits unresolved risk or exposes sensitive access details in the handoff.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "Project tasks, open risks, owner fields, or acceptance criteria are not maintained.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 30 project, phase, or support handoffs over 60 days", "pilotOwner": "Delivery operations manager", "pilotSuccessThreshold": "95% of handoffs receive receiver acceptance and fewer than 10% reopen for missing context within 14 days.", "workflowDistinction": "Delivery handoff notes owns capturing ownership transfer and unresolved delivery context, not documenting SOPs or summarizing client data intake. Its proof object is handoff_completeness_acceptance_rate from project management tool, client communication log, ticketing system, QA checklist, knowledge base, with Delivery operations manager accountable for review. Do not merge with client data collection or internal SOPs. Delivery handoff notes transfer responsibility for live work, unresolved risks, client promises, support obligations, and receiver acceptance.", "uniqueDataTest": "Check each handoff for completed work, open work, owner, risk, client promise, support obligation, sensitive access, receiver acceptance, and rework outcome. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Do not merge with client data collection or internal SOPs. Delivery handoff notes transfer responsibility for live work, unresolved risks, client promises, support obligations, and receiver acceptance.", "sourceRefs": [ "hubspot-customer-onboarding", "atlassian-kb-templates", "nist-ai-rmf" ] }, { "id": "resource-planning", "name": "Resource Planning", "url": "/workflow-library/resource-planning", "businessFunction": "Delivery operations", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Workflow Support", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 96, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Resource planning is weak when delivery teams see utilization, deadlines, skills, and client commitments in separate systems, so staffing conflicts surface too late. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in resource planning. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "capacity_exception_review_rate", "baselineMetricDescription": "Share of staffing conflicts reviewed with person, skill, client commitment, deadline, utilization, and owner decision before work is reassigned.", "sourceSystem": "project management tool, time tracking, resource plan, client commitment log, delivery risk register", "collectionMethod": "Compare weekly capacity exceptions to assignments, deadlines, utilization, skill tags, client promises, and manager decisions.", "leadingIndicators": [ "capacity conflict count", "skill mismatch count", "unassigned work count", "overallocated owner count" ], "laggingIndicators": [ "delivery delay due to capacity", "work reassignment rate", "utilization variance" ], "implementationEffort": "High", "dataReadiness": "Mixed", "trigger": "A new project starts, a deadline changes, a person becomes overallocated, a skill gap appears, or weekly planning needs an exception report.", "requiredEvidence": [ "active project list", "task deadlines and milestones", "team capacity and availability", "skill requirements", "client priority and contractual commitments", "budget or hours remaining", "planned time off", "manager approval rules" ], "aiRole": "AI prepares a capacity exception report by comparing assignments, skill tags, utilization, deadlines, and client commitments, then flags conflicts and decision options.", "humanReviewPoint": "The delivery lead reviews staffing tradeoffs, skill fit, margin impact, deadline promises, and client-facing changes before any reassignment or schedule change.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI reallocates work based on utilization without considering skill, quality risk, or client commitments.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "Project dates, staff assignments, skill tags, and client commitments are not maintained in source systems.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "All active projects and assigned staff in one delivery pod for 4 weeks", "pilotOwner": "Delivery operations manager", "pilotSuccessThreshold": "Review 95% of high-risk capacity exceptions before the affected deadline and keep unapproved client-facing schedule changes at 0.", "workflowDistinction": "Resource planning owns detecting delivery capacity exceptions across staff, skill, deadline, and commitment evidence, not managing project tasks or forecasting revenue. Its proof object is capacity_exception_review_rate from project management tool, time tracking, resource plan, client commitment log, delivery risk register, with Delivery operations manager accountable for review. Keep separate from change request handling and quality assurance review. Resource planning allocates capacity before delivery risk becomes a defect or scope change.", "uniqueDataTest": "Run a weekly capacity pull and verify every flagged conflict has assignment, utilization, skill, deadline, client commitment, and owner decision fields. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Keep separate from change request handling and quality assurance review. Resource planning allocates capacity before delivery risk becomes a defect or scope change.", "sourceRefs": [ "atlassian-priority-levels", "hubspot-customer-onboarding", "nist-ai-rmf" ] }, { "id": "client-request-prioritization", "name": "Client Request Prioritization", "url": "/workflow-library/client-request-prioritization", "businessFunction": "Client success", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Routing", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Client request prioritization is weak when urgent client language overrides contractual scope, SLA, business impact, account context, and delivery capacity. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in client request prioritization. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "client_request_priority_accuracy_review_rate", "baselineMetricDescription": "Share of client requests with impact, urgency, scope status, SLA, account tier, owner decision, and final priority reviewed before commitment.", "sourceSystem": "support ticketing system, CRM account record, contract or SOW, SLA rules, project management tool", "collectionMethod": "Compare request priority recommendations to owner decisions, SLA breaches, scope exceptions, reroutes, and client response outcomes.", "leadingIndicators": [ "impact/urgency coverage", "customer tier match", "priority override rate", "escalation accuracy" ], "laggingIndicators": [ "SLA breach reduction", "high-impact request response time", "customer escalation reduction" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A client submits a request by email, chat, portal, support ticket, meeting note, or direct message and the team needs to decide whether to handle, defer, quote, escalate, or decline it.", "requiredEvidence": [ "client request text", "source channel", "account tier and relationship context", "contracted scope and SLA", "impact and urgency signals", "estimated effort", "open project priorities", "account owner approval status" ], "aiRole": "AI summarizes the request, maps impact and urgency to SLA and scope evidence, suggests priority and route, and flags paid change or escalation cases.", "humanReviewPoint": "The account or support owner reviews out-of-scope work, goodwill exceptions, paid change requests, VIP overrides, SLA risk, and client-facing commitment.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI commits to urgent work that is out of scope or displaces higher-impact contractual work.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "SLA rules, account tier, contract scope, or request categories are not available.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 client requests across one account segment or 30 days of request volume", "pilotOwner": "Client success operations manager", "pilotSuccessThreshold": "90% of priority recommendations match owner-approved path and 100% of out-of-scope or paid-change cases receive human review.", "workflowDistinction": "Client request prioritization owns prioritizing incoming client requests against scope, SLA, and account context, not approving change requests or routing generic service tickets. Its proof object is client_request_priority_accuracy_review_rate from support ticketing system, CRM account record, contract or SOW, SLA rules, project management tool, with Client success operations manager accountable for review. Keep separate from change request handling and service ticket routing. Client request prioritization handles business priority and scope sensitivity after the request is understood.", "uniqueDataTest": "Audit each request for impact, urgency, account tier, SLA, scope status, owner decision, and final route. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Keep separate from change request handling and service ticket routing. Client request prioritization handles business priority and scope sensitivity after the request is understood.", "sourceRefs": [ "atlassian-priority-levels", "hubspot-service-hub-onboarding" ] }, { "id": "change-request-handling", "name": "Change Request Handling", "url": "/workflow-library/change-request-handling", "businessFunction": "Delivery operations", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Workflow Support", "riskLevel": "High", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 93, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Change request handling is weak when scope, schedule, and cost changes enter through emails or meetings before impact, approval authority, and client response are controlled. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in change request handling. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "change_request_approved_path_rate", "baselineMetricDescription": "Share of change requests with scope impact, cost or schedule estimate, approver, client communication status, and final decision before work starts.", "sourceSystem": "project management tool, ticketing system, contract or SOW, client email, change log, approval workflow", "collectionMethod": "Compare inbound change requests to scope baseline, impact note, approval status, owner, client response, and work-start timestamp.", "leadingIndicators": [ "change type classification", "impact/risk assessment", "approval path completion", "scope/commercial review" ], "laggingIndicators": [ "unauthorized change reduction", "change-related rework", "delivery timeline variance" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A client, stakeholder, or internal owner asks for work that may change scope, schedule, budget, quality, or deliverables.", "requiredEvidence": [ "original scope or SOW", "change request text", "request reason", "affected deliverables", "cost and schedule assumptions", "dependencies", "approval rules", "client communication history" ], "aiRole": "AI summarizes the request, compares it to scope and delivery records, drafts impact questions, and prepares approve, quote, defer, or decline options for review.", "humanReviewPoint": "The project or account owner reviews scope impact, cost, timing, approval authority, relationship risk, and client-facing response before work begins.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI approves scope or creates a client commitment without commercial review.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "Scope baseline, approval authority, or change log is missing.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 40 client change requests or all requests in one delivery pod over 45 days", "pilotOwner": "Delivery operations lead", "pilotSuccessThreshold": "95% of requests receive an approved path before work starts and 0 paid-scope exceptions are handled without owner review.", "workflowDistinction": "Change request handling owns controlling scope-change decisions and client response, not prioritizing ordinary client requests or planning resources. Its proof object is change_request_approved_path_rate from project management tool, ticketing system, contract or SOW, client email, change log, approval workflow, with Delivery operations lead accountable for review. Keep separate from client request prioritization. Change request handling applies when scope, schedule, budget, or deliverable commitment may change and work must not begin until the commercial path is approved.", "uniqueDataTest": "Trace each request to original scope, impact estimate, approver, decision, client response, and work-start timestamp. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Keep separate from client request prioritization. Change request handling applies when scope, schedule, budget, or deliverable commitment may change and work must not begin until the commercial path is approved.", "sourceRefs": [ "atlassian-change-record", "atlassian-priority-levels", "docusign-clm" ] }, { "id": "internal-sops", "name": "Internal SOPs", "url": "/workflow-library/internal-sops", "businessFunction": "Internal knowledge management", "department": "Enablement", "revenueLeak": "Capacity Drain", "kpi": "Cycle Time Reduction", "workflowType": "Review", "riskLevel": "Low", "ownerRole": "Enablement Lead", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Internal SOPs is weak when internal knowledge management teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Internal SOPs comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Knowledge operations owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "internal_sops_review_ready_rate", "baselineMetricDescription": "Share of internal sops records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, project management or knowledge base", "collectionMethod": "Sample internal sops records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, project management or knowledge base.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "A repeated task, training gap, quality issue, handoff problem, compliance need, or owner request starts the SOP workflow.", "requiredEvidence": [ "Current process notes, recordings, documents, and examples", "Process owner, role responsibilities, and approver", "Trigger, starting condition, ending condition, and expected output", "Known exceptions, risks, safety issues, and customer impact", "Screenshots, links, templates, and source evidence", "Version history, review date, and acknowledgment requirement" ], "aiRole": "AI prepares the internal sops record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Knowledge operations owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Knowledge operations owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances internal sops from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Internal SOPs does not have stable source records, owner fields, or status fields to sample.", "No accountable internal knowledge management owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 internal sops records, or all records from one internal knowledge management segment over 45 days", "pilotOwner": "Knowledge operations owner", "pilotSuccessThreshold": "At least 90% of sampled internal sops records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Internal SOPs is the internal knowledge management control for internal_sops_review_ready_rate, using atlassian-knowledge-management, iso-30401, atlassian-kb-templates as its source boundary and the workflow terms internal, sops. Its audit packet should carry internalsopsSourceRecord, internalsopsOwnerDecision, internalsopsExceptionQueue, internalsopsReviewOutcome, and internalsopsScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Knowledge operations owner, exception status, and a safe next action for internal sops specifically.", "uniqueDataTest": "Audit 100 internal sops records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep internal sops separate from adjacent internal knowledge management workflows by requiring internal_sops_review_ready_rate, the Knowledge operations owner review point, and the source boundary atlassian-knowledge-management, iso-30401, atlassian-kb-templates. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "atlassian-knowledge-management", "iso-30401", "atlassian-kb-templates" ] }, { "id": "knowledge-base-article-creation", "name": "Knowledge Base Article Creation", "url": "/workflow-library/knowledge-base-article-creation", "businessFunction": "Internal knowledge management", "department": "Enablement", "revenueLeak": "Capacity Drain", "kpi": "Cycle Time Reduction", "workflowType": "Review", "riskLevel": "Low", "ownerRole": "Enablement Lead", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Knowledge Base Article Creation is weak when internal knowledge management teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Knowledge Base Article Creation comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Knowledge operations owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "knowledge_base_article_creation_review_ready_rate", "baselineMetricDescription": "Share of knowledge base article creation records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, project management or knowledge base", "collectionMethod": "Sample knowledge base article creation records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, project management or knowledge base.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A repeated question, support ticket pattern, product change, SOP update, onboarding gap, or manager request starts the article workflow.", "requiredEvidence": [ "Question or problem the article should answer", "Source tickets, SOPs, product notes, screenshots, and examples", "Audience, article type, category, and access level", "Approved answer, steps, caveats, and escalation path", "Owner, reviewer, publish status, and review date", "Duplicate article search and related links" ], "aiRole": "AI prepares the knowledge base article creation record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Knowledge operations owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Knowledge operations owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances knowledge base article creation from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Knowledge Base Article Creation does not have stable source records, owner fields, or status fields to sample.", "No accountable internal knowledge management owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 knowledge base article creation records, or all records from one internal knowledge management segment over 45 days", "pilotOwner": "Knowledge operations owner", "pilotSuccessThreshold": "At least 90% of sampled knowledge base article creation records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Knowledge Base Article Creation is the internal knowledge management control for knowledge_base_article_creation_review_ready_rate, using atlassian-kb-templates, atlassian-knowledge-management, iso-30401 as its source boundary and the workflow terms knowledge, base, article, creation. Its audit packet should carry knowledgebasearticlecreationSourceRecord, knowledgebasearticlecreationOwnerDecision, knowledgebasearticlecreationExceptionQueue, knowledgebasearticlecreationReviewOutcome, and knowledgebasearticlecreationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Knowledge operations owner, exception status, and a safe next action for knowledge base article creation specifically.", "uniqueDataTest": "Audit 100 knowledge base article creation records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep knowledge base article creation separate from adjacent internal knowledge management workflows by requiring knowledge_base_article_creation_review_ready_rate, the Knowledge operations owner review point, and the source boundary atlassian-kb-templates, atlassian-knowledge-management, iso-30401. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "atlassian-kb-templates", "atlassian-knowledge-management", "iso-30401" ] }, { "id": "meeting-notes-to-sops", "name": "Meeting Notes To SOPs", "url": "/workflow-library/meeting-notes-to-sops", "businessFunction": "Internal knowledge management", "department": "Enablement", "revenueLeak": "Capacity Drain", "kpi": "Cycle Time Reduction", "workflowType": "Review", "riskLevel": "Low", "ownerRole": "Enablement Lead", "deployabilityBand": "High Readiness", "deployabilityScore": 92, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Meeting notes to SOPs stays weak when process walkthroughs and implementation meetings are converted into procedures without separating decisions, exceptions, temporary workarounds, and owner-approved steps. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making meeting notes to SOPs measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "meeting_to_sop_owner_approval_rate", "baselineMetricDescription": "Share of draft SOPs generated from meeting notes that include source meeting, process owner, approved steps, exception list, open questions, review date, and release decision.", "sourceSystem": "meeting notes, transcript repository, knowledge base, task tracker, SOP owner registry", "collectionMethod": "Sample generated SOP drafts and compare source transcript, decision items, owner comments, release status, and later correction requests.", "leadingIndicators": [ "process decision detected", "SOP owner assigned", "update draft created", "approval completed" ], "laggingIndicators": [ "SOP freshness", "repeat clarification reduction", "process change adoption" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "A process walkthrough, team meeting, training call, postmortem, implementation discussion, or recorded screen-share includes repeatable process instructions.", "requiredEvidence": [ "Meeting transcript, recording, notes, and chat", "Named decisions, open questions, and action items", "Current SOP, screenshots, examples, and source documents", "Process owner, roles, trigger, output, and exceptions", "Customer-facing, compliance, or safety-sensitive steps", "Approval status and review date" ], "aiRole": "AI separates repeatable steps, decisions, exceptions, open questions, and owner tasks from meeting notes, then drafts an SOP candidate with source references and uncertainty flags.", "humanReviewPoint": "The process owner reviews final steps, exceptions, role boundaries, customer-facing implications, temporary workarounds, and release status before the SOP is published.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI turns informal discussion or temporary workaround into official process.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Meetings are not recorded or summarized, process owners are unclear, or the knowledge base lacks an approval workflow.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 40 meeting-derived SOP drafts or all process walkthroughs in one department over 60 days", "pilotOwner": "Knowledge operations owner", "pilotSuccessThreshold": "90% of generated SOP drafts have owner approval or explicit rejection, and 0 are published without source links and owner review.", "workflowDistinction": "Meeting notes to SOPs handles converting a specific meeting transcript into a reviewable SOP candidate with owner approval, exception capture, and release controls. The audit sample checks trace each sop step to the source meeting line, owner comment, open question, exception field, and publish decision. Keep separate from internal SOPs and meeting decision logs. This workflow transforms source discussions into procedure drafts; SOP maintenance governs official procedures, while decision logs capture meeting outcomes.", "uniqueDataTest": "Trace each SOP step to the source meeting line, owner comment, open question, exception field, and publish decision. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from internal SOPs and meeting decision logs. This workflow transforms source discussions into procedure drafts; SOP maintenance governs official procedures, while decision logs capture meeting outcomes.", "sourceRefs": [ "atlassian-knowledge-management", "iso-30401", "notion-search" ] }, { "id": "policy-question-answering", "name": "Policy Question Answering", "url": "/workflow-library/policy-question-answering", "businessFunction": "Internal knowledge management", "department": "Enablement", "revenueLeak": "Capacity Drain", "kpi": "Cycle Time Reduction", "workflowType": "Workflow Support", "riskLevel": "Low", "ownerRole": "Enablement Lead", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Policy question answering stays weak when employees receive confident answers to policy questions without source authority, freshness, eligibility, jurisdiction, or escalation boundaries. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making policy question answering measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "policy_answer_escalation_accuracy_rate", "baselineMetricDescription": "Share of policy answers with cited policy source, freshness date, audience eligibility, escalation status, owner approval for high-impact answers, and feedback outcome.", "sourceSystem": "policy knowledge base, HR or compliance repository, permission groups, employee question log, escalation queue", "collectionMethod": "Sample policy questions and compare answer citation, freshness, eligibility, escalation outcome, owner correction, and employee feedback.", "leadingIndicators": [ "source citation coverage", "outdated policy detection", "escalation rate", "correction rate" ], "laggingIndicators": [ "repeat policy question reduction", "policy answer correction reduction", "time to policy answer" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "An employee asks a question about a policy, procedure, benefit, approval rule, customer term, expense rule, access rule, or operating requirement.", "requiredEvidence": [ "User question and role or permission context", "Approved policy documents and version history", "Effective date, owner, and review date", "Relevant citations and source snippets", "Escalation owner for ambiguous or high-impact answers", "Refusal rules for missing or restricted sources" ], "aiRole": "AI retrieves cited policy passages, summarizes applicable rules, labels uncertainty, and routes eligibility, compliance, legal, or high-impact questions to human review.", "humanReviewPoint": "Policy owner reviews ambiguous, regulated, disciplinary, benefits, legal, customer-facing, or high-impact answers before they are treated as authoritative.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI gives an authoritative policy answer from stale, restricted, or inapplicable content.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Policies lack owners, dates, source authority, or a clear escalation path.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "300 employee policy questions from one department or policy domain over 45 days", "pilotOwner": "Policy owner", "pilotSuccessThreshold": "95% of answered questions include cited policy and freshness date, and 100% of high-impact or ambiguous questions escalate to a human owner.", "workflowDistinction": "Policy question answering handles answering policy questions with authority, eligibility, freshness, and escalation controls. The audit sample checks audit each answer for cited source, effective date, employee eligibility, escalation decision, owner correction, and feedback. Keep separate from internal search assistant. Policy answering is narrower and higher risk because it needs authority, eligibility, freshness, and escalation boundaries.", "uniqueDataTest": "Audit each answer for cited source, effective date, employee eligibility, escalation decision, owner correction, and feedback. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from internal search assistant. Policy answering is narrower and higher risk because it needs authority, eligibility, freshness, and escalation boundaries.", "sourceRefs": [ "notion-search", "iso-30401", "nist-ai-rmf" ] }, { "id": "internal-search-assistant", "name": "Internal Search Assistant", "url": "/workflow-library/internal-search-assistant", "businessFunction": "Internal knowledge management", "department": "Enablement", "revenueLeak": "Capacity Drain", "kpi": "Cycle Time Reduction", "workflowType": "Workflow Support", "riskLevel": "Low", "ownerRole": "Enablement Lead", "deployabilityBand": "High Readiness", "deployabilityScore": 92, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Internal search assistant is weak when employees get confident answers from stale, conflicting, restricted, or uncited internal documents. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in internal search assistant. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "cited_answer_acceptance_rate", "baselineMetricDescription": "Share of internal search answers accepted by users or owners with source citation, permission check, freshness signal, conflict flag, and feedback outcome.", "sourceSystem": "knowledge base, document library, permission groups, search index, feedback log, content owner registry", "collectionMethod": "Sample answered queries and compare citations, source freshness, permission state, conflicting sources, user feedback, and owner corrections.", "leadingIndicators": [ "source citation coverage", "freshness coverage", "permission-safe retrieval", "unanswered question rate" ], "laggingIndicators": [ "time to answer", "repeat question volume", "search abandonment" ], "implementationEffort": "High", "dataReadiness": "Messy", "trigger": "An employee asks a natural-language question that may be answered by SOPs, knowledge base articles, policies, tickets, project documents, or shared internal files.", "requiredEvidence": [ "User question and permission context", "Approved source collections and exclusion rules", "Document owner, freshness, version, and access metadata", "Retrieved passages with source links", "Confidence, conflict, and no-answer rules", "Feedback channel and knowledge-gap owner" ], "aiRole": "AI retrieves and summarizes approved internal sources with citations, freshness signals, permission awareness, conflict flags, and no-answer escalation when evidence is weak.", "humanReviewPoint": "Knowledge owners review source eligibility, permissions, high-impact answers, conflicting sources, and expansion to new repositories or departments.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI answers from restricted, stale, or conflicting documents as if the answer is authoritative.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "Documents lack owners, permissions, freshness metadata, or a controlled search index.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "300 employee queries in one department knowledge base over 30 days", "pilotOwner": "Knowledge operations owner", "pilotSuccessThreshold": "90% of accepted answers include citations and freshness signals, and 100% of restricted-source or conflicting-source cases route to review.", "workflowDistinction": "Internal search assistant owns serving employee questions with cited answer passages, permission checks, freshness labels, no-answer paths, and feedback loops. Its proof object is cited_answer_acceptance_rate from knowledge base, document library, permission groups, search index, feedback log, content owner registry, with Knowledge operations owner accountable for review. Keep distinct from document tagging and process documentation cleanup. Search assistant is a query-and-answer workflow with citations, freshness, permission filtering, conflict detection, and a no-answer path for weak evidence.", "uniqueDataTest": "Audit queries for answer, citation, source freshness, permission check, conflict flag, no-answer status, feedback, and owner correction. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Keep distinct from document tagging and process documentation cleanup. Search assistant is a query-and-answer workflow with citations, freshness, permission filtering, conflict detection, and a no-answer path for weak evidence.", "sourceRefs": [ "notion-search", "atlassian-knowledge-management", "iso-30401" ] }, { "id": "document-tagging", "name": "Document Tagging", "url": "/workflow-library/document-tagging", "businessFunction": "Internal knowledge management", "department": "Enablement", "revenueLeak": "Capacity Drain", "kpi": "Cycle Time Reduction", "workflowType": "Review", "riskLevel": "Low", "ownerRole": "Enablement Lead", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Document tagging is weak when documents become hard to find or unsafe to route when owner, audience, status, sensitivity, topic, and review date metadata are missing. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in document tagging. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "document_metadata_acceptance_rate", "baselineMetricDescription": "Share of tagged documents with approved owner, audience, topic, status, sensitivity, review date, and duplicate or stale-document decision.", "sourceSystem": "SharePoint or document library, knowledge base, content management system, metadata taxonomy, permission groups", "collectionMethod": "Sample tagged documents and compare AI labels to owner review, search results, permission behavior, duplicate matches, and later corrections.", "leadingIndicators": [ "required tag coverage", "review correction rate", "unclassified sensitive document count", "duplicate tag count" ], "laggingIndicators": [ "search success rate", "document routing accuracy", "retention/compliance exception reduction" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A document is created, imported, edited, moved into the knowledge base, or flagged as hard to find.", "requiredEvidence": [ "Document title, body, folder, author, and source system", "Existing taxonomy, required metadata, and naming rules", "Audience, department, document type, owner, and status", "Sensitivity, access level, and permission rules", "Review date, version, duplicate candidates, and confidence score", "Knowledge owner or taxonomy approver" ], "aiRole": "AI suggests metadata tags, owner, audience, status, sensitivity, review date, and duplicate candidates, then sends low-confidence or restricted labels to review.", "humanReviewPoint": "The knowledge owner reviews taxonomy changes, restricted or sensitive labels, audience tags, permission implications, and low-confidence classifications.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI applies tags that expose sensitive documents, hide useful documents, or create taxonomy sprawl.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "No taxonomy, owner model, permission rules, or review process exists for the document library.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "500 documents from one knowledge base or department library", "pilotOwner": "Knowledge management owner", "pilotSuccessThreshold": "90% of sampled documents receive accepted metadata and 100% of sensitive or restricted labels receive human approval.", "workflowDistinction": "Document tagging owns classifying files with owner, audience, topic, status, sensitivity, review date, duplicate, and permission-affecting metadata. Its proof object is document_metadata_acceptance_rate from SharePoint or document library, knowledge base, content management system, metadata taxonomy, permission groups, with Knowledge management owner accountable for review. Keep separate from internal search assistant and process documentation cleanup. Tagging changes classification, findability, retention cues, restricted labels, and permission-adjacent metadata before search or archive workflows use the file.", "uniqueDataTest": "Audit document tags against owner, audience, status, sensitivity, review date, duplicate candidate, permission behavior, and search correction logs. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Keep separate from internal search assistant and process documentation cleanup. Tagging changes classification, findability, retention cues, restricted labels, and permission-adjacent metadata before search or archive workflows use the file.", "sourceRefs": [ "sharepoint-metadata", "microsoft-syntex", "iso-30401" ] }, { "id": "sop-review-reminders", "name": "SOP Review Reminders", "url": "/workflow-library/sop-review-reminders", "businessFunction": "Internal knowledge management", "department": "Enablement", "revenueLeak": "Capacity Drain", "kpi": "Cycle Time Reduction", "workflowType": "Review", "riskLevel": "Low", "ownerRole": "Enablement Lead", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "SOP Review Reminders is weak when internal knowledge management teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of SOP Review Reminders comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Knowledge operations owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "sop_review_reminders_review_ready_rate", "baselineMetricDescription": "Share of sop review reminders records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, project management or knowledge base", "collectionMethod": "Sample sop review reminders records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, project management or knowledge base.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "An SOP reaches its review date, a process changes, a policy changes, a tool changes, or repeated exceptions suggest the procedure is stale.", "requiredEvidence": [ "SOP owner, approver, review interval, and last reviewed date", "Procedure risk level and affected roles", "Recent process changes, exceptions, incidents, and feedback", "Acknowledgment requirements and training impact", "Version history, source links, and related SOPs", "Escalation rule for ignored reviews" ], "aiRole": "AI prepares the sop review reminders record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Knowledge operations owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Knowledge operations owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances sop review reminders from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "SOP Review Reminders does not have stable source records, owner fields, or status fields to sample.", "No accountable internal knowledge management owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 sop review reminders records, or all records from one internal knowledge management segment over 45 days", "pilotOwner": "Knowledge operations owner", "pilotSuccessThreshold": "At least 90% of sampled sop review reminders records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "SOP Review Reminders is the internal knowledge management control for sop_review_reminders_review_ready_rate, using atlassian-knowledge-management, iso-30401, atlassian-kb-templates as its source boundary and the workflow terms sop, review, reminders. Its audit packet should carry sopreviewremindersSourceRecord, sopreviewremindersOwnerDecision, sopreviewremindersExceptionQueue, sopreviewremindersReviewOutcome, and sopreviewremindersScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Knowledge operations owner, exception status, and a safe next action for sop review reminders specifically.", "uniqueDataTest": "Audit 100 sop review reminders records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep sop review reminders separate from adjacent internal knowledge management workflows by requiring sop_review_reminders_review_ready_rate, the Knowledge operations owner review point, and the source boundary atlassian-knowledge-management, iso-30401, atlassian-kb-templates. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "atlassian-knowledge-management", "iso-30401", "atlassian-kb-templates" ] }, { "id": "process-documentation-cleanup", "name": "Process Documentation Cleanup", "url": "/workflow-library/process-documentation-cleanup", "businessFunction": "Internal knowledge management", "department": "Enablement", "revenueLeak": "Capacity Drain", "kpi": "Cycle Time Reduction", "workflowType": "Workflow Support", "riskLevel": "Low", "ownerRole": "Enablement Lead", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Process documentation cleanup stays weak when old, duplicate, conflicting, ownerless, or broken process documents stay live and create search confusion or execution errors. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making process documentation cleanup measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "process_doc_cleanup_decision_rate", "baselineMetricDescription": "Share of flagged process documents with owner, current status, duplicate or conflict status, action decision, redirect need, and review date.", "sourceSystem": "knowledge base, document library, search logs, process owner registry, link checker, SOP repository", "collectionMethod": "Review cleanup queue items against owner decision, archive or merge action, redirect completion, search feedback, and later reopen rate.", "leadingIndicators": [ "duplicate cluster count", "ownerless page count", "outdated page count", "resolution decision completion" ], "laggingIndicators": [ "search result quality", "repeat process questions", "SOP review completion" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "A scheduled cleanup, failed search, duplicate document, broken link, process change, audit request, or employee feedback starts the workflow.", "requiredEvidence": [ "Document inventory, folders, owners, dates, and version history", "Usage data, search terms, failed searches, and feedback", "Duplicate candidates, broken links, and conflicting instructions", "Access level, audience, and public/internal status", "Related SOPs, articles, and training references", "Document owner and cleanup approver" ], "aiRole": "AI identifies stale, duplicate, conflicting, broken, and ownerless process documents, recommends cleanup actions, and flags risky deletion or merge cases.", "humanReviewPoint": "Document owner approves archive, merge, redirect, official procedure change, permission change, and any cleanup that affects active work.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI archives or merges an active procedure that a team still depends on.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Documents do not have owners, usage signals, review dates, or a place to record lifecycle decisions.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "500 process documents or one department knowledge base cleanup queue", "pilotOwner": "Knowledge management owner", "pilotSuccessThreshold": "90% of high-risk cleanup items receive owner decisions and 100% of archived or merged documents have redirect or replacement handling.", "workflowDistinction": "Process documentation cleanup handles deciding document lifecycle actions for stale or conflicting process content. The audit sample checks check each cleanup item for owner, usage evidence, duplicate or conflict match, action decision, redirect, and post-cleanup search impact. Keep separate from document tagging and internal search assistant. Cleanup changes lifecycle state; tagging changes metadata, and search answers questions using approved content.", "uniqueDataTest": "Check each cleanup item for owner, usage evidence, duplicate or conflict match, action decision, redirect, and post-cleanup search impact. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from document tagging and internal search assistant. Cleanup changes lifecycle state; tagging changes metadata, and search answers questions using approved content.", "sourceRefs": [ "atlassian-knowledge-management", "notion-search", "iso-30401" ] }, { "id": "new-hire-training-plans", "name": "New Hire Training Plans", "url": "/workflow-library/new-hire-training-plans", "businessFunction": "Team training", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Workflow Support", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "New hire training plans stays weak when new hires receive generic checklists that do not connect role outcomes, required systems, practice scenarios, mentor review, and readiness criteria. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making new hire training plans measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "new_hire_role_readiness_plan_rate", "baselineMetricDescription": "Share of new-hire plans with role outcomes, required learning path, system access, practice scenario, mentor owner, readiness check, and manager approval.", "sourceSystem": "HRIS, LMS, role profile, manager checklist, access request queue, onboarding plan", "collectionMethod": "Review new-hire plans against role profile, assigned modules, access status, manager check-ins, practice completion, and readiness decision.", "leadingIndicators": [ "learning path assigned", "course completion", "manager check-in completion", "practice task completion" ], "laggingIndicators": [ "time to role readiness", "early performance milestone", "new hire support request reduction" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A new employee is hired, changes roles, joins a department, or needs a role-specific onboarding plan before day one.", "requiredEvidence": [ "Role, department, manager, start date, and mentor", "Required tools, access, equipment, and compliance training", "Role outcomes, first-week tasks, and 30-day readiness criteria", "Relevant SOPs, knowledge articles, and training materials", "Practice scenarios, shadowing plan, and check-in schedule", "Manager approval and HR requirements" ], "aiRole": "AI assembles a role-specific training plan from role profile, learning paths, access needs, SOPs, and manager expectations, then flags missing readiness evidence.", "humanReviewPoint": "The hiring manager approves role outcomes, practice scenarios, mentor assignment, compliance items, and any readiness interpretation before it affects performance expectations.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI equates module completion with role readiness or adds compliance requirements without HR review.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Role outcomes, required systems, LMS paths, or manager review cadence are not defined.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 30 new hires or one department hiring cohort over 90 days", "pilotOwner": "People operations manager", "pilotSuccessThreshold": "95% of new hires have a manager-approved role-readiness plan before day one and 90% complete the first readiness check on time.", "workflowDistinction": "New hire training plans handles building an individualized readiness plan for one new hire role, including access, learning path, mentor, and readiness gates. The audit sample checks audit each plan for role outcome, assigned learning path, access checklist, practice scenario, mentor, manager approval, and readiness decision. Keep separate from role-based onboarding and training completion tracking. New-hire plans combine role setup and first-period readiness; completion tracking only measures learning progress.", "uniqueDataTest": "Audit each plan for role outcome, assigned learning path, access checklist, practice scenario, mentor, manager approval, and readiness decision. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from role-based onboarding and training completion tracking. New-hire plans combine role setup and first-period readiness; completion tracking only measures learning progress.", "sourceRefs": [ "viva-learning-paths", "learnupon-learning-paths", "docebo-learning-plans" ] }, { "id": "training-content-creation", "name": "Training Content Creation", "url": "/workflow-library/training-content-creation", "businessFunction": "Team training", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Training Content Creation is weak when team training teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Training Content Creation comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Learning operations manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "training_content_creation_review_ready_rate", "baselineMetricDescription": "Share of training content creation records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, learning platform", "collectionMethod": "Sample training content creation records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, learning platform.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A new process, recurring mistake, role change, product update, compliance need, or manager request creates a training need.", "requiredEvidence": [ "Training goal, role, audience, and performance objective", "Source SOPs, policies, examples, screenshots, and SME notes", "Common mistakes, edge cases, and realistic scenarios", "Assessment criteria and acceptable performance standard", "Format, duration, delivery channel, and accessibility needs", "SME reviewer, release owner, and review date" ], "aiRole": "AI prepares the training content creation record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Learning operations manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Learning operations manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances training content creation from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Training Content Creation does not have stable source records, owner fields, or status fields to sample.", "No accountable team training owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 training content creation records, or all records from one team training segment over 45 days", "pilotOwner": "Learning operations manager", "pilotSuccessThreshold": "At least 90% of sampled training content creation records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Training Content Creation is the team training control for training_content_creation_review_ready_rate, using docebo-learning-plans, viva-learning-paths, iso-30401 as its source boundary and the workflow terms training, content, creation. Its audit packet should carry trainingcontentcreationSourceRecord, trainingcontentcreationOwnerDecision, trainingcontentcreationExceptionQueue, trainingcontentcreationReviewOutcome, and trainingcontentcreationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Learning operations manager, exception status, and a safe next action for training content creation specifically.", "uniqueDataTest": "Audit 100 training content creation records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep training content creation separate from adjacent team training workflows by requiring training_content_creation_review_ready_rate, the Learning operations manager review point, and the source boundary docebo-learning-plans, viva-learning-paths, iso-30401. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "docebo-learning-plans", "viva-learning-paths", "iso-30401" ] }, { "id": "role-based-onboarding", "name": "Role Based Onboarding", "url": "/workflow-library/role-based-onboarding", "businessFunction": "Training and enablement", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Role Based Onboarding is weak when training and enablement teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Role Based Onboarding comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Learning operations manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "role_based_onboarding_review_ready_rate", "baselineMetricDescription": "Share of role based onboarding records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, learning platform", "collectionMethod": "Sample role based onboarding records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, learning platform.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A new hire is accepted, a role changes, or a manager needs a role-specific onboarding plan before the employee's first day.", "requiredEvidence": [ "job description", "department and reporting line", "required systems and access", "first-week schedule", "role-specific SOPs", "first 30-day outcomes", "peer or buddy owner", "manager check-in cadence" ], "aiRole": "AI prepares the role based onboarding record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Learning operations manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Learning operations manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances role based onboarding from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Role Based Onboarding does not have stable source records, owner fields, or status fields to sample.", "No accountable training and enablement owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 role based onboarding records, or all records from one training and enablement segment over 45 days", "pilotOwner": "Learning operations manager", "pilotSuccessThreshold": "At least 90% of sampled role based onboarding records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Role Based Onboarding is the training and enablement control for role_based_onboarding_review_ready_rate, using viva-learning-paths, learnupon-learning-paths, docebo-learning-plans as its source boundary and the workflow terms role, based, onboarding. Its audit packet should carry rolebasedonboardingSourceRecord, rolebasedonboardingOwnerDecision, rolebasedonboardingExceptionQueue, rolebasedonboardingReviewOutcome, and rolebasedonboardingScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Learning operations manager, exception status, and a safe next action for role based onboarding specifically.", "uniqueDataTest": "Audit 100 role based onboarding records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep role based onboarding separate from adjacent training and enablement workflows by requiring role_based_onboarding_review_ready_rate, the Learning operations manager review point, and the source boundary viva-learning-paths, learnupon-learning-paths, docebo-learning-plans. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "viva-learning-paths", "learnupon-learning-paths", "docebo-learning-plans" ] }, { "id": "sales-coaching-feedback", "name": "Sales Coaching Feedback", "url": "/workflow-library/sales-coaching-feedback", "businessFunction": "Sales enablement", "department": "Sales", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Scoring", "riskLevel": "Medium", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Sales Coaching Feedback is weak when sales enablement teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Sales Coaching Feedback comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales enablement manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "sales_coaching_feedback_review_ready_rate", "baselineMetricDescription": "Share of sales coaching feedback records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, call intelligence, HubSpot, risk review notes", "collectionMethod": "Sample sales coaching feedback records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, call intelligence, HubSpot, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A sales call ends, a deal stalls, a manager prepares for coaching, or a rep asks for feedback on a conversation.", "requiredEvidence": [ "call transcript or recording summary", "sales rubric", "deal stage and CRM context", "buyer questions and objections", "rep notes", "next-step evidence", "manager coaching priorities", "prior coaching history" ], "aiRole": "AI prepares the sales coaching feedback record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales enablement manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales enablement manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances sales coaching feedback from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Sales Coaching Feedback does not have stable source records, owner fields, or status fields to sample.", "No accountable sales enablement owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 sales coaching feedback records, or all records from one sales enablement segment over 45 days", "pilotOwner": "Sales enablement manager", "pilotSuccessThreshold": "At least 90% of sampled sales coaching feedback records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Sales Coaching Feedback is the sales enablement control for sales_coaching_feedback_review_ready_rate, using gong-call-intelligence, hubspot-sales-automation, nist-ai-rmf as its source boundary and the workflow terms sales, coaching, feedback. Its audit packet should carry salescoachingfeedbackSourceRecord, salescoachingfeedbackOwnerDecision, salescoachingfeedbackExceptionQueue, salescoachingfeedbackReviewOutcome, and salescoachingfeedbackScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales enablement manager, exception status, and a safe next action for sales coaching feedback specifically.", "uniqueDataTest": "Audit 100 sales coaching feedback records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep sales coaching feedback separate from adjacent sales enablement workflows by requiring sales_coaching_feedback_review_ready_rate, the Sales enablement manager review point, and the source boundary gong-call-intelligence, hubspot-sales-automation, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "gong-call-intelligence", "hubspot-sales-automation", "nist-ai-rmf" ] }, { "id": "support-agent-coaching", "name": "Support Agent Coaching", "url": "/workflow-library/support-agent-coaching", "businessFunction": "Customer support", "department": "Customer Success", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Scoring", "riskLevel": "Medium", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Support Agent Coaching is weak when customer support teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Support Agent Coaching comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Support operations manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "support_agent_coaching_review_ready_rate", "baselineMetricDescription": "Share of support agent coaching records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, support platform, project management or knowledge base", "collectionMethod": "Sample support agent coaching records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, support platform, project management or knowledge base.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A ticket closes, a low CSAT response arrives, a support lead runs QA, or a recurring customer issue needs coaching review.", "requiredEvidence": [ "resolved ticket thread", "support rubric", "customer sentiment or CSAT", "resolution time", "policy and knowledge-base references", "escalation history", "agent notes", "support lead review rules" ], "aiRole": "AI prepares the support agent coaching record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Support operations manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Support operations manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances support agent coaching from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Support Agent Coaching does not have stable source records, owner fields, or status fields to sample.", "No accountable customer support owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 support agent coaching records, or all records from one customer support segment over 45 days", "pilotOwner": "Support operations manager", "pilotSuccessThreshold": "At least 90% of sampled support agent coaching records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Support Agent Coaching is the customer support control for support_agent_coaching_review_ready_rate, using zendesk-qa-scorecards, zendesk-qa-admin, atlassian-kb-templates as its source boundary and the workflow terms support, agent, coaching. Its audit packet should carry supportagentcoachingSourceRecord, supportagentcoachingOwnerDecision, supportagentcoachingExceptionQueue, supportagentcoachingReviewOutcome, and supportagentcoachingScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Support operations manager, exception status, and a safe next action for support agent coaching specifically.", "uniqueDataTest": "Audit 100 support agent coaching records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep support agent coaching separate from adjacent customer support workflows by requiring support_agent_coaching_review_ready_rate, the Support operations manager review point, and the source boundary zendesk-qa-scorecards, zendesk-qa-admin, atlassian-kb-templates. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "zendesk-qa-scorecards", "zendesk-qa-admin", "atlassian-kb-templates" ] }, { "id": "training-completion-tracking", "name": "Training Completion Tracking", "url": "/workflow-library/training-completion-tracking", "businessFunction": "Training and compliance", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 91, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Training completion tracking stays weak when learning systems show completion but not overdue risk, manager follow-up, required role readiness, exception reason, or evidence of practice. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making training completion tracking measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "training_completion_exception_resolution_rate", "baselineMetricDescription": "Share of required training assignments with completion status, due date, role requirement, overdue reason, manager follow-up, and readiness check.", "sourceSystem": "LMS, HRIS, role profile, manager checklist, compliance tracker", "collectionMethod": "Compare training assignments to completion, overdue exceptions, manager follow-up, role readiness, and compliance reporting.", "leadingIndicators": [ "assignment coverage", "overdue exception count", "manager notification completion", "manual progress correction rate" ], "laggingIndicators": [ "required training completion by deadline", "audit exception reduction", "role-readiness blocker closure" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "Training is assigned, a due date approaches, a learner becomes overdue, or a manager needs a completion report before an audit or deadline.", "requiredEvidence": [ "training assignment list", "learner role and department", "due dates", "completion status", "reminder history", "manager owner", "exemption or leave status", "compliance requirement rules" ], "aiRole": "AI monitors required training progress, flags overdue or role-critical gaps, drafts manager follow-up, and separates completion evidence from readiness evidence.", "humanReviewPoint": "Manager or HR owner reviews compliance-sensitive items, readiness interpretation, remediation, deadline exceptions, and performance implications.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI treats course completion as proof of job readiness or makes performance judgments.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "LMS assignments, role requirements, due dates, or manager ownership are not maintained.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "All required training assignments for one role group or 500 assignments over 60 days", "pilotOwner": "Learning operations manager", "pilotSuccessThreshold": "95% of overdue role-critical assignments receive owner follow-up and 90% of readiness checks are completed by the target date.", "workflowDistinction": "Training completion tracking handles tracking required learning progress, overdue exceptions, and manager follow-up separately from role readiness. The audit sample checks audit assignment, due date, completion, overdue reason, role requirement, manager follow-up, readiness check, and exception closure. Keep separate from new-hire training plans and role-based onboarding. Completion tracking monitors progress and exceptions; plans define what training should exist.", "uniqueDataTest": "Audit assignment, due date, completion, overdue reason, role requirement, manager follow-up, readiness check, and exception closure. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from new-hire training plans and role-based onboarding. Completion tracking monitors progress and exceptions; plans define what training should exist.", "sourceRefs": [ "viva-learning-progress", "learnupon-learning-paths", "docebo-learning-plans" ] }, { "id": "microlearning-generation", "name": "Microlearning Generation", "url": "/workflow-library/microlearning-generation", "businessFunction": "Training and enablement", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Microlearning Generation is weak when training and enablement teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Microlearning Generation comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Learning operations manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "microlearning_generation_review_ready_rate", "baselineMetricDescription": "Share of microlearning generation records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, learning platform, project management or knowledge base", "collectionMethod": "Sample microlearning generation records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, learning platform, project management or knowledge base.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A new SOP, policy update, support issue, sales pattern, or recurring mistake needs short training that employees can use in the flow of work.", "requiredEvidence": [ "approved SOP or training source", "target role", "single learning objective", "real workplace scenario", "common mistake", "policy or compliance constraints", "subject matter expert owner", "manager check question" ], "aiRole": "AI prepares the microlearning generation record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Learning operations manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Learning operations manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances microlearning generation from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Microlearning Generation does not have stable source records, owner fields, or status fields to sample.", "No accountable training and enablement owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 microlearning generation records, or all records from one training and enablement segment over 45 days", "pilotOwner": "Learning operations manager", "pilotSuccessThreshold": "At least 90% of sampled microlearning generation records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Microlearning Generation is the training and enablement control for microlearning_generation_review_ready_rate, using docebo-ai-features, atlassian-kb-templates, iso-30401 as its source boundary and the workflow terms microlearning, generation. Its audit packet should carry microlearninggenerationSourceRecord, microlearninggenerationOwnerDecision, microlearninggenerationExceptionQueue, microlearninggenerationReviewOutcome, and microlearninggenerationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Learning operations manager, exception status, and a safe next action for microlearning generation specifically.", "uniqueDataTest": "Audit 100 microlearning generation records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep microlearning generation separate from adjacent training and enablement workflows by requiring microlearning_generation_review_ready_rate, the Learning operations manager review point, and the source boundary docebo-ai-features, atlassian-kb-templates, iso-30401. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "docebo-ai-features", "atlassian-kb-templates", "iso-30401" ] }, { "id": "manager-training-summaries", "name": "Manager Training Summaries", "url": "/workflow-library/manager-training-summaries", "businessFunction": "Team training", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Follow-Up", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 92, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Manager Training Summaries is weak when team training teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Manager Training Summaries comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Learning operations manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "manager_training_summaries_review_ready_rate", "baselineMetricDescription": "Share of manager training summaries records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, learning platform, risk review notes", "collectionMethod": "Sample manager training summaries records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, learning platform, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A manager completes training, a cohort session ends, or HR needs follow-up notes from a management development program.", "requiredEvidence": [ "training agenda", "session transcript or notes", "manager role and team context", "practice exercises", "commitments made", "follow-up dates", "coaching resources", "HR review rules" ], "aiRole": "AI prepares the manager training summaries record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Learning operations manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Learning operations manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances manager training summaries from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Manager Training Summaries does not have stable source records, owner fields, or status fields to sample.", "No accountable team training owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 manager training summaries records, or all records from one team training segment over 45 days", "pilotOwner": "Learning operations manager", "pilotSuccessThreshold": "At least 90% of sampled manager training summaries records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Manager Training Summaries is the team training control for manager_training_summaries_review_ready_rate, using viva-learning-progress, nist-ai-rmf as its source boundary and the workflow terms manager, training, summaries. Its audit packet should carry managertrainingsummariesSourceRecord, managertrainingsummariesOwnerDecision, managertrainingsummariesExceptionQueue, managertrainingsummariesReviewOutcome, and managertrainingsummariesScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Learning operations manager, exception status, and a safe next action for manager training summaries specifically.", "uniqueDataTest": "Audit 100 manager training summaries records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep manager training summaries separate from adjacent team training workflows by requiring manager_training_summaries_review_ready_rate, the Learning operations manager review point, and the source boundary viva-learning-progress, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "viva-learning-progress", "nist-ai-rmf" ] }, { "id": "weekly-performance-reporting", "name": "Weekly Performance Reporting", "url": "/workflow-library/weekly-performance-reporting", "businessFunction": "Reporting", "department": "Operations", "revenueLeak": "Decision Delay", "kpi": "Decision Cycle Time", "workflowType": "Reporting", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Weekly performance reporting stays weak when weekly reports repeat metrics without linking changes to source freshness, owner explanation, threshold breaches, and next operating action. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making weekly performance reporting measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "weekly_report_actionability_rate", "baselineMetricDescription": "Share of weekly performance report items with source metric, freshness timestamp, threshold status, owner explanation, action decision, and follow-up owner.", "sourceSystem": "BI dashboard, analytics platform, CRM report, operations dashboard, KPI owner notes", "collectionMethod": "Sample weekly report items and compare source metric, freshness, owner explanation, action assignment, and next-week follow-through.", "leadingIndicators": [ "source metric freshness", "exception count", "owner assignment", "decision capture" ], "laggingIndicators": [ "overdue operating issue reduction", "meeting time saved", "repeat exception rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "The workflow starts on a fixed weekly reporting schedule or when a reporting period closes and agreed metrics are ready for review.", "requiredEvidence": [ "approved metric list", "current reporting period", "prior period or target baseline", "data source timestamps", "variance thresholds", "owner notes", "open decisions or commitments", "audience and delivery format" ], "aiRole": "AI drafts weekly summaries from approved metrics, flags stale data and threshold movement, separates facts from interpretation, and lists items needing owner explanation.", "humanReviewPoint": "Report owner reviews variance interpretation, sensitive narrative, operational recommendations, and any action assigned to a team or individual.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI implies causation or assigns action from metric movement without owner review.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Metrics lack owners, thresholds, freshness timestamps, or a weekly reporting cadence.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "Eight weekly performance reports or the top 25 recurring metrics over 60 days", "pilotOwner": "Operations analyst", "pilotSuccessThreshold": "100% of report items include source and freshness fields, and 85% of action items have an owner and follow-up status by the next report.", "workflowDistinction": "Weekly performance reporting handles turning a recurring weekly metric pack into action follow-up, freshness labels, owner commentary, and next-week accountability. The audit sample checks verify each weekly report row against metric source, freshness label, weekly delta, owner commentary, action decision, follow-up owner, and next-report status. Keep separate from operations dashboard summaries and executive KPI summaries. Weekly reporting is a cadence artifact for recurring metric rows, owner commentary, and next-week accountability.", "uniqueDataTest": "Verify each weekly report row against metric source, freshness label, weekly delta, owner commentary, action decision, follow-up owner, and next-report status. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from operations dashboard summaries and executive KPI summaries. Weekly reporting is a cadence artifact for recurring metric rows, owner commentary, and next-week accountability.", "sourceRefs": [ "looker-data-freshness", "ga4-custom-reports", "nist-ai-rmf" ] }, { "id": "client-reporting", "name": "Client Reporting", "url": "/workflow-library/client-reporting", "businessFunction": "Reporting", "department": "Operations", "revenueLeak": "Decision Delay", "kpi": "Decision Cycle Time", "workflowType": "Reporting", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Client Reporting is weak when reporting teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Client Reporting comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Operations analytics owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "client_reporting_review_ready_rate", "baselineMetricDescription": "Share of client reporting records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, BI or analytics dashboard, risk review notes", "collectionMethod": "Sample client reporting records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, BI or analytics dashboard, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A reporting period closes, a client meeting is scheduled, or delivery results need to be summarized for a client decision.", "requiredEvidence": [ "approved KPI data", "delivery notes", "client goals", "prior report commitments", "open risks or blockers", "wins and completed work", "client-needed decisions", "account owner review rules" ], "aiRole": "AI prepares the client reporting record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Operations analytics owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Operations analytics owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances client reporting from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Client Reporting does not have stable source records, owner fields, or status fields to sample.", "No accountable reporting owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 client reporting records, or all records from one reporting segment over 45 days", "pilotOwner": "Operations analytics owner", "pilotSuccessThreshold": "At least 90% of sampled client reporting records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Client Reporting is the reporting control for client_reporting_review_ready_rate, using looker-data-freshness, ga4-custom-reports, nist-ai-rmf as its source boundary and the workflow terms client, reporting. Its audit packet should carry clientreportingSourceRecord, clientreportingOwnerDecision, clientreportingExceptionQueue, clientreportingReviewOutcome, and clientreportingScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Operations analytics owner, exception status, and a safe next action for client reporting specifically.", "uniqueDataTest": "Audit 100 client reporting records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep client reporting separate from adjacent reporting workflows by requiring client_reporting_review_ready_rate, the Operations analytics owner review point, and the source boundary looker-data-freshness, ga4-custom-reports, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "looker-data-freshness", "ga4-custom-reports", "nist-ai-rmf" ] }, { "id": "marketing-performance-reporting", "name": "Marketing Performance Reporting", "url": "/workflow-library/marketing-performance-reporting", "businessFunction": "Marketing", "department": "Marketing Ops", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Reporting", "riskLevel": "Medium", "ownerRole": "Marketing Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Marketing performance reporting is weak when marketing reports combine channel metrics, attribution, campaign status, and narrative without freshness, source, and owner review. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in marketing performance reporting. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "marketing_report_claim_trace_rate", "baselineMetricDescription": "Share of marketing performance claims with source platform, attribution rule, freshness timestamp, campaign owner, variance note, and decision implication.", "sourceSystem": "GA4, Google Ads, marketing automation, CRM campaign records, BI dashboard", "collectionMethod": "Sample report claims and tie each one to platform source, attribution setting, owner note, variance explanation, and correction history.", "leadingIndicators": [ "conversion tracking coverage", "campaign source integrity", "variance flag count", "CRM outcome match rate" ], "laggingIndicators": [ "budget decision quality", "campaign pause or iterate decisions", "lead-quality feedback closure" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "A weekly or monthly marketing reporting period closes, campaign performance changes materially, or a budget or optimization decision is due.", "requiredEvidence": [ "channel performance data", "target KPIs", "spend and pacing", "pipeline or lead quality data", "creative or offer notes", "conversion rates", "attribution caveats", "marketing owner review rules" ], "aiRole": "AI drafts report summaries from approved marketing data sources, flags stale or conflicting data, separates platform facts from attribution interpretation, and lists open questions.", "humanReviewPoint": "Marketing analytics or demand generation reviews attribution interpretation, campaign context, budget implications, anomalous data, and any recommendation to change spend.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI attributes performance change to a campaign or channel without source and attribution context.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "Campaign naming, source connections, attribution settings, or reporting owner are unclear.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "One monthly reporting cycle covering the top 10 campaigns and primary acquisition channels", "pilotOwner": "Marketing operations manager", "pilotSuccessThreshold": "100% of material report claims include source and freshness fields, and 90% of variance explanations receive owner review before publication.", "workflowDistinction": "Marketing performance reporting owns source-tracing marketing report claims, not doing broad KPI variance analysis or executive KPI summary writing. Its proof object is marketing_report_claim_trace_rate from GA4, Google Ads, marketing automation, CRM campaign records, BI dashboard, with Marketing operations manager accountable for review. Do not merge with executive KPI summaries or KPI variance analysis. Marketing reporting is channel and attribution specific, and it must preserve platform source, campaign owner, and attribution settings.", "uniqueDataTest": "Verify each claim against platform source, attribution setting, campaign owner, data freshness, variance note, and decision implication. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Do not merge with executive KPI summaries or KPI variance analysis. Marketing reporting is channel and attribution specific, and it must preserve platform source, campaign owner, and attribution settings.", "sourceRefs": [ "ga4-custom-reports", "google-ads-attribution", "hubspot-marketing-reports" ] }, { "id": "sales-activity-reporting", "name": "Sales Activity Reporting", "url": "/workflow-library/sales-activity-reporting", "businessFunction": "Sales operations", "department": "Sales", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Reporting", "riskLevel": "Medium", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Sales activity reporting stays weak when activity reports count emails, calls, meetings, and tasks without showing source completeness, account context, outcome, and manager-useful exceptions. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making sales activity reporting measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "sales_activity_report_acceptance_rate", "baselineMetricDescription": "Share of activity report rows with source event, owner, account or opportunity link, outcome, exception flag, and manager review status.", "sourceSystem": "CRM activity history, sales engagement platform, calendar, call intelligence, pipeline inspection view", "collectionMethod": "Compare activity summaries to raw events, missing sync items, manager comments, action items, and opportunity movement.", "leadingIndicators": [ "activity logging completeness", "opportunity association rate", "next-step coverage", "manager exception review" ], "laggingIndicators": [ "stale opportunity reduction", "coaching pattern closure", "pipeline stage hygiene" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "A weekly sales review is due, activity falls below expectations, a rep needs coaching, or CRM activity data looks incomplete.", "requiredEvidence": [ "CRM activity logs", "calls and emails", "meetings booked", "stage changes", "new opportunities", "next-step status", "closed won or lost notes", "manager coaching rules" ], "aiRole": "AI summarizes sales activity patterns, flags missing or stale events, links activity to accounts and opportunities, and separates raw volume from outcome indicators.", "humanReviewPoint": "Sales manager reviews performance interpretation, coaching implications, rep-sensitive conclusions, forecast relevance, and any action assigned to a rep.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI turns activity volume into performance judgment without context.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Activities are not synced reliably or cannot be linked to accounts and opportunities.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "Four weekly reports for one sales team or 1,000 activity events", "pilotOwner": "Sales operations analyst", "pilotSuccessThreshold": "95% of report rows link to source events and 90% of manager exceptions receive follow-up action or dismissal.", "workflowDistinction": "Sales activity reporting handles turning raw sales activity events into source-linked manager report exceptions. The audit sample checks audit activity event, owner, account link, opportunity link, outcome, missing-sync flag, manager comment, and follow-up action. Keep separate from sales manager weekly review and CRM activity logging. Reporting summarizes patterns; logging captures events, and manager review prepares coaching agenda.", "uniqueDataTest": "Audit activity event, owner, account link, opportunity link, outcome, missing-sync flag, manager comment, and follow-up action. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from sales manager weekly review and CRM activity logging. Reporting summarizes patterns; logging captures events, and manager review prepares coaching agenda.", "sourceRefs": [ "hubspot-sales-automation", "salesforce-pipeline-inspection", "gong-call-intelligence" ] }, { "id": "operations-dashboard-summaries", "name": "Operations Dashboard Summaries", "url": "/workflow-library/operations-dashboard-summaries", "businessFunction": "Operations", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Operations dashboard summaries stays weak when operations summaries describe metric movement without freshness, owner context, threshold rules, exception status, and next operational decision. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making operations dashboard summaries measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "operations_summary_exception_trace_rate", "baselineMetricDescription": "Share of operations dashboard summaries with source dashboard, freshness timestamp, threshold breach, owner note, exception status, and next decision.", "sourceSystem": "BI dashboard, operations dashboard, ticketing queue, project tracker, KPI owner notes", "collectionMethod": "Sample summary lines and verify source metric, freshness, threshold rule, owner explanation, exception owner, and follow-up status.", "leadingIndicators": [ "dashboard freshness", "exception threshold coverage", "owner assignment", "blocked-work flag count" ], "laggingIndicators": [ "repeat exception rate", "cycle time for operating issues", "escalation timeliness" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A weekly operations meeting is coming up, a KPI crosses a threshold, or a dashboard needs a plain-language summary for managers.", "requiredEvidence": [ "operations dashboard metrics", "KPI definitions", "threshold rules", "prior-period values", "owner assignments", "known data-quality issues", "open operational risks", "manager review rules" ], "aiRole": "AI drafts operations summaries from approved dashboards, flags stale data and threshold breaches, separates metric facts from explanation, and lists exceptions requiring owner input.", "humanReviewPoint": "Operations owner reviews interpretation, threshold changes, staffing or priority recommendations, sensitive customer issues, and any action that changes operating commitments.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI explains operational variance or recommends action without owner context.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Dashboards lack owners, freshness timestamps, thresholds, or reliable metric definitions.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "One monthly operating review with the top 20 recurring operational metrics", "pilotOwner": "Operations manager", "pilotSuccessThreshold": "100% of material summary claims include source and freshness fields, and 90% of exceptions have owner disposition before review.", "workflowDistinction": "Operations dashboard summaries handles translating dashboard threshold breaches into queue, project, service-level, and operating-owner exception notes. The audit sample checks verify each operations exception against dashboard source, freshness timestamp, threshold rule, queue or project owner, service impact, exception status, and next action. Keep separate from executive KPI summaries and weekly performance reporting. Operations dashboard summaries serve queue, project, SLA, and service-level exception control.", "uniqueDataTest": "Verify each operations exception against dashboard source, freshness timestamp, threshold rule, queue or project owner, service impact, exception status, and next action. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from executive KPI summaries and weekly performance reporting. Operations dashboard summaries serve queue, project, SLA, and service-level exception control.", "sourceRefs": [ "looker-data-freshness", "atlassian-priority-levels", "nist-ai-rmf" ] }, { "id": "kpi-variance-analysis", "name": "KPI Variance Analysis", "url": "/workflow-library/kpi-variance-analysis", "businessFunction": "Reporting", "department": "Operations", "revenueLeak": "Decision Delay", "kpi": "Decision Cycle Time", "workflowType": "Reporting", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "KPI Variance Analysis is weak when reporting teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of KPI Variance Analysis comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Operations analytics owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "kpi_variance_analysis_review_ready_rate", "baselineMetricDescription": "Share of kpi variance analysis records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, BI or analytics dashboard, Salesforce", "collectionMethod": "Sample kpi variance analysis records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, BI or analytics dashboard, Salesforce.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A KPI crosses a threshold, a reporting period closes, actuals differ materially from target, or leadership needs an explanation for a performance change.", "requiredEvidence": [ "KPI definition", "actual result", "target or budget", "prior-period result", "threshold rule", "supporting operational data", "known one-time events", "finance or operations review rules" ], "aiRole": "AI prepares the kpi variance analysis record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Operations analytics owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Operations analytics owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances kpi variance analysis from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "KPI Variance Analysis does not have stable source records, owner fields, or status fields to sample.", "No accountable reporting owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 kpi variance analysis records, or all records from one reporting segment over 45 days", "pilotOwner": "Operations analytics owner", "pilotSuccessThreshold": "At least 90% of sampled kpi variance analysis records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "KPI Variance Analysis is the reporting control for kpi_variance_analysis_review_ready_rate, using looker-data-freshness, ga4-custom-reports, salesforce-pipeline-inspection as its source boundary and the workflow terms kpi, variance, analysis. Its audit packet should carry kpivarianceanalysisSourceRecord, kpivarianceanalysisOwnerDecision, kpivarianceanalysisExceptionQueue, kpivarianceanalysisReviewOutcome, and kpivarianceanalysisScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Operations analytics owner, exception status, and a safe next action for kpi variance analysis specifically.", "uniqueDataTest": "Audit 100 kpi variance analysis records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep kpi variance analysis separate from adjacent reporting workflows by requiring kpi_variance_analysis_review_ready_rate, the Operations analytics owner review point, and the source boundary looker-data-freshness, ga4-custom-reports, salesforce-pipeline-inspection. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "looker-data-freshness", "ga4-custom-reports", "salesforce-pipeline-inspection" ] }, { "id": "board-reporting-preparation", "name": "Board Reporting Preparation", "url": "/workflow-library/board-reporting-preparation", "businessFunction": "Reporting", "department": "Operations", "revenueLeak": "Decision Delay", "kpi": "Decision Cycle Time", "workflowType": "Review", "riskLevel": "High", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 91, "publicClaimLevel": "Directional", "buyerProblem": "Board reporting preparation is weak when board packets can blend stale numbers, unsupported narrative, forecast changes, and risk framing without enough source traceability. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in board reporting preparation. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "board_packet_source_trace_rate", "baselineMetricDescription": "Share of board-reporting claims with source dashboard, owner, freshness timestamp, variance explanation, risk note, and executive approval status.", "sourceSystem": "BI dashboard, CRM forecast, finance model, KPI owner notes, risk register, board packet draft", "collectionMethod": "Sample board packet claims and tie each number or narrative point to source freshness, owner approval, variance notes, and unresolved risk.", "leadingIndicators": [ "source coverage", "owner signoff", "open claim count", "decision ask clarity" ], "laggingIndicators": [ "board revision cycles", "late-data exception count", "post-board action capture" ], "implementationEffort": "High", "dataReadiness": "Mixed", "trigger": "A monthly or quarterly board meeting is scheduled and reporting inputs need to be assembled.", "requiredEvidence": [ "financial metrics", "KPI dashboard", "budget and forecast variance", "operational updates", "customer or pipeline updates", "key risks", "decisions needed", "appendix materials" ], "aiRole": "AI prepares a board packet evidence checklist by matching metrics, narrative claims, forecast changes, and risks to source systems and owner notes.", "humanReviewPoint": "Executives review interpretation, forecast confidence, risk framing, sensitive narrative, and every material number before board distribution.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI turns stale or conflicting metrics into a confident board narrative.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "Metrics do not have owners, freshness timestamps, or a source-of-truth dashboard.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "One board packet plus all KPI, forecast, and risk claims included in the draft", "pilotOwner": "Chief of staff", "pilotSuccessThreshold": "100% of material claims have source links and owner approval before distribution, with unresolved or stale data clearly labeled.", "workflowDistinction": "Board reporting preparation owns preparing source-traced board reporting evidence, not creating executive KPI summaries for internal operating review. Its proof object is board_packet_source_trace_rate from BI dashboard, CRM forecast, finance model, KPI owner notes, risk register, board packet draft, with Chief of staff accountable for review. Do not merge with executive KPI summaries. Board reporting preparation has external-governance sensitivity, investor or board audience risk, packet-level approval requirements, and stricter source traceability.", "uniqueDataTest": "Trace every number and risk claim in the board packet to dashboard source, freshness timestamp, owner note, variance reason, and executive approval. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Do not merge with executive KPI summaries. Board reporting preparation has external-governance sensitivity, investor or board audience risk, packet-level approval requirements, and stricter source traceability.", "sourceRefs": [ "looker-data-freshness", "salesforce-forecasting", "nist-ai-rmf" ] }, { "id": "executive-kpi-summaries", "name": "Executive KPI Summaries", "url": "/workflow-library/executive-kpi-summaries", "businessFunction": "Reporting", "department": "Operations", "revenueLeak": "Decision Delay", "kpi": "Decision Cycle Time", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 92, "publicClaimLevel": "Directional", "buyerProblem": "Executive KPI summaries is weak when leaders receive KPI narratives that are detached from source freshness, owner explanation, variance cause, and decision implication. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in executive KPI summaries. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "kpi_summary_source_readiness_rate", "baselineMetricDescription": "Share of KPI summary points with source dashboard, freshness timestamp, owner explanation, variance cause, decision implication, and approval status.", "sourceSystem": "BI dashboard, CRM pipeline report, finance dashboard, operations dashboard, KPI owner notes", "collectionMethod": "Sample KPI summary lines and verify source freshness, owner review, variance explanation, decision ask, and correction history.", "leadingIndicators": [ "exception threshold accuracy", "owner assignment", "driver evidence coverage", "summary approval rate" ], "laggingIndicators": [ "executive follow-up completion", "repeat unanswered exception count", "decision latency" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A weekly, monthly, or quarterly KPI review is due, or a KPI crosses an exception threshold.", "requiredEvidence": [ "KPI dashboard", "target and actual values", "variance thresholds", "historical trend", "data owner notes", "known initiatives", "function owner", "decision or action rules" ], "aiRole": "AI drafts KPI summary points from dashboards and owner notes, flags stale data or unexplained variance, and separates facts from interpretation and decisions.", "humanReviewPoint": "KPI owners review variance interpretation, data freshness, decision requests, sensitive narrative, and any summary used for executive action.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI explains variance or recommends action without owner evidence.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "KPI owners, source dashboards, or freshness timestamps are not defined.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "Top 20 executive KPIs across one monthly operating review cycle", "pilotOwner": "Revenue operations leader", "pilotSuccessThreshold": "100% of KPI summary points include source and freshness fields, and 90% include owner-approved variance explanation before review.", "workflowDistinction": "Executive KPI summaries owns summarizing internal KPI movement for operating review, not preparing board packets or doing deep variance analysis. Its proof object is kpi_summary_source_readiness_rate from BI dashboard, CRM pipeline report, finance dashboard, operations dashboard, KPI owner notes, with Revenue operations leader accountable for review. Keep distinct from board reporting preparation and KPI variance analysis. Executive KPI summaries create concise operating narratives; the other workflows cover external packet control or deeper root-cause work.", "uniqueDataTest": "Verify each summary point has source dashboard, freshness timestamp, owner note, variance reason, decision implication, and approval status. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Keep distinct from board reporting preparation and KPI variance analysis. Executive KPI summaries create concise operating narratives; the other workflows cover external packet control or deeper root-cause work.", "sourceRefs": [ "looker-data-freshness", "salesforce-pipeline-inspection", "nist-ai-rmf" ] }, { "id": "customer-churn-risk-detection", "name": "Customer Churn Risk Detection", "url": "/workflow-library/customer-churn-risk-detection", "businessFunction": "Customer success", "department": "Customer Success", "revenueLeak": "Retention Risk", "kpi": "Retention Rate", "workflowType": "Workflow Support", "riskLevel": "Medium", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Churn risk is often recognized too late or too vaguely. Teams see lower usage, support frustration, executive silence, billing friction, or renewal date pressure, but no one turns those signals into a reviewed intervention plan while there is still time.", "economicLogic": "The value is retention focus. The workflow should find accounts with credible loss risk, explain the signal pattern, assign intervention owners, and measure whether actions happen before renewal or cancellation decisions are final.", "baselineMetric": "churn_risk_intervention_coverage_rate", "baselineMetricDescription": "Share of accounts flagged for churn risk with risk reason, signal evidence, renewal context, intervention owner, action plan, review status, and later renewal/churn outcome captured.", "sourceSystem": "Customer success platform, product analytics, support tickets, CRM renewal records, billing/subscription data", "collectionMethod": "Compare churn-risk flags to underlying signals, renewal date, owner action, executive escalation, customer response, save attempt, and final renewal or churn outcome.", "leadingIndicators": [ "risk reason coverage", "intervention owner assignment", "days before renewal flagged", "CSM action completion" ], "laggingIndicators": [ "renewal save rate", "churn rate in flagged cohort", "false positive risk rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A customer shows declining engagement, unresolved issues, negative sentiment, renewal risk, billing friction, or silence before a renewal or key milestone.", "requiredEvidence": [ "usage or engagement trend", "support ticket history", "sentiment and feedback", "renewal date", "commercial and billing status", "customer success notes", "stakeholder engagement", "customer owner review rules" ], "aiRole": "AI combines product, support, renewal, billing, relationship, and prior health signals into a churn-risk brief with reasons, confidence, and suggested internal action. It does not tell customers they are predicted to churn or decide concession strategy.", "humanReviewPoint": "CSM, CS leader, or renewal owner reviews critical risk flags, intervention plan, customer-facing messaging, concessions, and false-positive patterns before action is taken.", "evidenceBoundary": "Health and renewal-center sources support risk-signal and renewal mechanics. Churn prediction accuracy must be validated against renewal outcomes and CSM judgment.", "stopRules": [ "The workflow flags too many accounts and CSMs stop acting.", "AI recommends customer outreach that mishandles sensitive account context." ], "notReadyIf": [ "Renewal dates are unreliable.", "Product/support/billing signals are not connected to accounts.", "CSM intervention actions are not tracked." ], "pilotDuration": "60 days", "pilotSampleSize": "All accounts renewing in the next 90 days or top 100 ARR accounts with active risk signals", "pilotOwner": "Customer success operations lead", "pilotSuccessThreshold": "At least 90% of flagged accounts have risk reason, owner, and intervention plan; false positives and missed churn cases are reviewed before scaling.", "workflowDistinction": "Customer churn risk detection is a risk intervention workflow. It focuses on accounts likely to leave or downgrade and the actions needed before renewal. Customer health scoring is broader and can include stable, expansion, and onboarding signals.", "uniqueDataTest": "For accounts renewing soon or showing risk signals, verify risk reason, underlying product/support/billing/relationship evidence, days before renewal, owner action, CSM review, customer response, and final renewal or churn outcome.", "duplicateGuard": "Do not merge this with customer health scoring. Health scoring may feed the workflow, but churn risk detection owns the loss-risk reason, days-before-renewal context, intervention owner, customer-facing action review, and renewal or churn outcome after the intervention window.", "sourceRefs": [ "hubspot-health-score", "gainsight-health-score", "gainsight-renewal-center" ] }, { "id": "renewal-preparation", "name": "Renewal Preparation", "url": "/workflow-library/renewal-preparation", "businessFunction": "Customer success", "department": "Customer Success", "revenueLeak": "Retention Risk", "kpi": "Retention Rate", "workflowType": "Workflow Support", "riskLevel": "Medium", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Renewal Preparation is weak when customer success teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Renewal Preparation comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Customer success operations owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "renewal_preparation_review_ready_rate", "baselineMetricDescription": "Share of renewal preparation records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, customer success platform, HubSpot", "collectionMethod": "Sample renewal preparation records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, customer success platform, HubSpot.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A renewal is 120, 90, 60, or 30 days away, a QBR is scheduled, or an account shows risk before renewal.", "requiredEvidence": [ "contract end date", "renewal terms", "customer goals and success criteria", "usage or service outcomes", "stakeholder map", "open risks and commitments", "support and billing history", "account owner review rules" ], "aiRole": "AI prepares the renewal preparation record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Customer success operations owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Customer success operations owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances renewal preparation from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Renewal Preparation does not have stable source records, owner fields, or status fields to sample.", "No accountable customer success owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 renewal preparation records, or all records from one customer success segment over 45 days", "pilotOwner": "Customer success operations owner", "pilotSuccessThreshold": "At least 90% of sampled renewal preparation records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Renewal Preparation is the customer success control for renewal_preparation_review_ready_rate, using gainsight-renewal-center, hubspot-health-score, hubspot-customer-onboarding as its source boundary and the workflow terms renewal, preparation. Its audit packet should carry renewalpreparationSourceRecord, renewalpreparationOwnerDecision, renewalpreparationExceptionQueue, renewalpreparationReviewOutcome, and renewalpreparationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Customer success operations owner, exception status, and a safe next action for renewal preparation specifically.", "uniqueDataTest": "Audit 100 renewal preparation records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep renewal preparation separate from adjacent customer success workflows by requiring renewal_preparation_review_ready_rate, the Customer success operations owner review point, and the source boundary gainsight-renewal-center, hubspot-health-score, hubspot-customer-onboarding. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "gainsight-renewal-center", "hubspot-health-score", "hubspot-customer-onboarding" ] }, { "id": "customer-health-scoring", "name": "Customer Health Scoring", "url": "/workflow-library/customer-health-scoring", "businessFunction": "Customer success", "department": "Customer Success", "revenueLeak": "Retention Risk", "kpi": "Retention Rate", "workflowType": "Scoring", "riskLevel": "Medium", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 96, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Health scores lose trust when they become opaque color badges. CSMs need to know which product, support, adoption, relationship, billing, and outcome signals drove the score, which signals are stale, and what action the score recommends.", "economicLogic": "The value is prioritization for customer success capacity. A credible score should help teams focus on accounts that need action, explain why, and compare score movement against renewal, expansion, and escalation outcomes.", "baselineMetric": "health_score_explainable_action_rate", "baselineMetricDescription": "Share of customer health score changes that include contributing signals, stale or missing data flags, recommended action, owner, review status, and later account outcome.", "sourceSystem": "Customer success platform, product analytics, support tickets, CRM account records, billing/subscription data", "collectionMethod": "Compare health score movement to underlying signals, data freshness, CSM review, action taken, escalation, renewal, churn, or expansion outcome.", "leadingIndicators": [ "signal freshness rate", "score explanation coverage", "CSM review completion", "action creation rate" ], "laggingIndicators": [ "renewal risk accuracy", "expansion signal quality", "escalation rate after score drop" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A weekly account review runs, a health score changes materially, a renewal approaches, or an account lacks a recent health snapshot.", "requiredEvidence": [ "usage or engagement data", "feature or service adoption", "support ticket status", "sentiment or feedback", "billing issues", "stakeholder engagement", "success plan milestones", "customer owner review rules" ], "aiRole": "AI explains health score movement, checks signal freshness, identifies contributing adoption, support, billing, and relationship factors, and recommends an action or review. It does not decide renewal forecast, churn status, or customer communication without CSM review.", "humanReviewPoint": "CSM or CS ops reviews material score changes, stale data flags, renewal-risk escalations, expansion suggestions, and any customer-facing action triggered by the score.", "evidenceBoundary": "Health-score sources support signal-based scoring mechanics. Predictive accuracy and renewal impact need account-level validation in the company's data.", "stopRules": [ "The score looks precise but is driven by stale or missing data.", "CSMs ignore the score because it does not match account reality." ], "notReadyIf": [ "Core health signals are not integrated.", "Renewal or churn outcomes cannot be tied to accounts.", "CSM action and override reasons are not captured." ], "pilotDuration": "60 days", "pilotSampleSize": "Top 100 accounts by ARR or one renewal-quarter cohort", "pilotOwner": "Customer success operations lead", "pilotSuccessThreshold": "At least 85% of material score changes include signal explanation and CSM review; stale-data driven changes are separated from true account risk.", "workflowDistinction": "Customer health scoring creates an explainable prioritization signal across accounts. Churn risk detection is a narrower risk workflow focused on likely loss and intervention; health scoring can also identify stable or expansion-ready accounts.", "uniqueDataTest": "Review accounts with material score changes and verify product, support, billing, relationship, renewal, and CSM action signals. Compare score direction to CSM override, escalation, renewal, churn, and expansion outcomes over the cohort.", "duplicateGuard": "Keep separate from churn risk detection and onboarding health checks. Health scoring is the broad account signal model; churn detection focuses on loss risk, and onboarding checks focus on early lifecycle progress.", "sourceRefs": [ "hubspot-health-score", "gainsight-health-score", "gainsight-renewal-center" ] }, { "id": "save-offer-routing", "name": "Save Offer Routing", "url": "/workflow-library/save-offer-routing", "businessFunction": "Customer success", "department": "Customer Success", "revenueLeak": "Retention Risk", "kpi": "Retention Rate", "workflowType": "Routing", "riskLevel": "High", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 95, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Save Offer Routing is weak when customer success teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Save Offer Routing comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Customer success operations owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "save_offer_routing_review_ready_rate", "baselineMetricDescription": "Share of save offer routing records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, customer success platform, HubSpot, risk review notes", "collectionMethod": "Sample save offer routing records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, customer success platform, HubSpot, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A customer requests cancellation, signals serious churn risk, rejects renewal, complains about value, or asks for a price concession.", "requiredEvidence": [ "cancellation or risk signal", "customer reason", "account value", "contract and renewal status", "service history", "support and satisfaction notes", "approved save options", "account owner review rules" ], "aiRole": "AI prepares the save offer routing record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Customer success operations owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Customer success operations owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances save offer routing from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Save Offer Routing does not have stable source records, owner fields, or status fields to sample.", "No accountable customer success owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 save offer routing records, or all records from one customer success segment over 45 days", "pilotOwner": "Customer success operations owner", "pilotSuccessThreshold": "At least 90% of sampled save offer routing records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Save Offer Routing is the customer success control for save_offer_routing_review_ready_rate, using gainsight-renewal-center, hubspot-health-score, nist-ai-rmf as its source boundary and the workflow terms save, offer, routing. Its audit packet should carry saveofferroutingSourceRecord, saveofferroutingOwnerDecision, saveofferroutingExceptionQueue, saveofferroutingReviewOutcome, and saveofferroutingScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Customer success operations owner, exception status, and a safe next action for save offer routing specifically.", "uniqueDataTest": "Audit 100 save offer routing records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep save offer routing separate from adjacent customer success workflows by requiring save_offer_routing_review_ready_rate, the Customer success operations owner review point, and the source boundary gainsight-renewal-center, hubspot-health-score, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "gainsight-renewal-center", "hubspot-health-score", "nist-ai-rmf" ] }, { "id": "post-project-follow-up", "name": "Post-Project Follow-Up", "url": "/workflow-library/post-project-follow-up", "businessFunction": "Client success", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Follow-Up", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Post-Project Follow-Up is weak when client success teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Post-Project Follow-Up comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Client success lead, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "post_project_follow_up_review_ready_rate", "baselineMetricDescription": "Share of post-project follow-up records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, risk review notes", "collectionMethod": "Sample post-project follow-up records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A project deliverable is accepted, a project closes, final invoice is prepared, or a post-delivery follow-up window arrives.", "requiredEvidence": [ "final deliverables", "client acceptance status", "open issues or support items", "project results and notes", "invoice or payment status", "testimonial or referral eligibility", "archive requirements", "account owner review rules" ], "aiRole": "AI prepares the post-project follow-up record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Client success lead; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Client success lead reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances post-project follow-up from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Post-Project Follow-Up does not have stable source records, owner fields, or status fields to sample.", "No accountable client success owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 post-project follow-up records, or all records from one client success segment over 45 days", "pilotOwner": "Client success lead", "pilotSuccessThreshold": "At least 90% of sampled post-project follow-up records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Post-Project Follow-Up is the client success control for post_project_follow_up_review_ready_rate, using hubspot-customer-onboarding, hubspot-service-hub-onboarding, nist-ai-rmf as its source boundary and the workflow terms post, project, follow, up. Its audit packet should carry postprojectfollowupSourceRecord, postprojectfollowupOwnerDecision, postprojectfollowupExceptionQueue, postprojectfollowupReviewOutcome, and postprojectfollowupScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Client success lead, exception status, and a safe next action for post-project follow-up specifically.", "uniqueDataTest": "Audit 100 post-project follow-up records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep post-project follow-up separate from adjacent client success workflows by requiring post_project_follow_up_review_ready_rate, the Client success lead review point, and the source boundary hubspot-customer-onboarding, hubspot-service-hub-onboarding, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-customer-onboarding", "hubspot-service-hub-onboarding", "nist-ai-rmf" ] }, { "id": "contract-renewal-reminders", "name": "Contract Renewal Reminders", "url": "/workflow-library/contract-renewal-reminders", "businessFunction": "Customer success", "department": "Customer Success", "revenueLeak": "Retention Risk", "kpi": "Retention Rate", "workflowType": "Follow-Up", "riskLevel": "Medium", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Contract Renewal Reminders is weak when customer success teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Contract Renewal Reminders comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Customer success operations owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "contract_renewal_reminders_review_ready_rate", "baselineMetricDescription": "Share of contract renewal reminders records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, customer success platform, HubSpot, Salesforce", "collectionMethod": "Sample contract renewal reminders records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, customer success platform, HubSpot, Salesforce.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A contract reaches a 120, 90, 60, or 30-day renewal window, or a renewal task remains incomplete near a deadline.", "requiredEvidence": [ "contract end date", "renewal notice period", "auto-renew terms", "account owner", "customer stakeholder map", "value proof status", "risk status", "procurement or legal requirements" ], "aiRole": "AI prepares the contract renewal reminders record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Customer success operations owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Customer success operations owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances contract renewal reminders from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Contract Renewal Reminders does not have stable source records, owner fields, or status fields to sample.", "No accountable customer success owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 contract renewal reminders records, or all records from one customer success segment over 45 days", "pilotOwner": "Customer success operations owner", "pilotSuccessThreshold": "At least 90% of sampled contract renewal reminders records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Contract Renewal Reminders is the customer success control for contract_renewal_reminders_review_ready_rate, using gainsight-renewal-center, hubspot-forecast-tool, salesforce-forecasting as its source boundary and the workflow terms contract, renewal, reminders. Its audit packet should carry contractrenewalremindersSourceRecord, contractrenewalremindersOwnerDecision, contractrenewalremindersExceptionQueue, contractrenewalremindersReviewOutcome, and contractrenewalremindersScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Customer success operations owner, exception status, and a safe next action for contract renewal reminders specifically.", "uniqueDataTest": "Audit 100 contract renewal reminders records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep contract renewal reminders separate from adjacent customer success workflows by requiring contract_renewal_reminders_review_ready_rate, the Customer success operations owner review point, and the source boundary gainsight-renewal-center, hubspot-forecast-tool, salesforce-forecasting. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "gainsight-renewal-center", "hubspot-forecast-tool", "salesforce-forecasting" ] }, { "id": "customer-feedback-analysis", "name": "Customer Feedback Analysis", "url": "/workflow-library/customer-feedback-analysis", "businessFunction": "Customer success", "department": "Customer Success", "revenueLeak": "Retention Risk", "kpi": "Retention Rate", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Customer Feedback Analysis is weak when customer success teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Customer Feedback Analysis comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Customer success operations owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "customer_feedback_analysis_review_ready_rate", "baselineMetricDescription": "Share of customer feedback analysis records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, project management or knowledge base, risk review notes", "collectionMethod": "Sample customer feedback analysis records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, project management or knowledge base, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "New feedback arrives, a weekly feedback review runs, a theme spikes, or leadership needs a voice-of-customer digest.", "requiredEvidence": [ "survey responses", "support tickets", "reviews and comments", "call or chat transcripts", "customer segment", "account value or risk", "current feedback taxonomy", "owner review rules" ], "aiRole": "AI prepares the customer feedback analysis record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Customer success operations owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Customer success operations owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances customer feedback analysis from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Customer Feedback Analysis does not have stable source records, owner fields, or status fields to sample.", "No accountable customer success owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 customer feedback analysis records, or all records from one customer success segment over 45 days", "pilotOwner": "Customer success operations owner", "pilotSuccessThreshold": "At least 90% of sampled customer feedback analysis records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Customer Feedback Analysis is the customer success control for customer_feedback_analysis_review_ready_rate, using hubspot-health-score, atlassian-kb-templates, nist-ai-rmf as its source boundary and the workflow terms customer, feedback, analysis. Its audit packet should carry customerfeedbackanalysisSourceRecord, customerfeedbackanalysisOwnerDecision, customerfeedbackanalysisExceptionQueue, customerfeedbackanalysisReviewOutcome, and customerfeedbackanalysisScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Customer success operations owner, exception status, and a safe next action for customer feedback analysis specifically.", "uniqueDataTest": "Audit 100 customer feedback analysis records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep customer feedback analysis separate from adjacent customer success workflows by requiring customer_feedback_analysis_review_ready_rate, the Customer success operations owner review point, and the source boundary hubspot-health-score, atlassian-kb-templates, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-health-score", "atlassian-kb-templates", "nist-ai-rmf" ] }, { "id": "account-value-recap", "name": "Account Value Recap", "url": "/workflow-library/account-value-recap", "businessFunction": "Customer success", "department": "Customer Success", "revenueLeak": "Retention Risk", "kpi": "Retention Rate", "workflowType": "Workflow Support", "riskLevel": "Medium", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Account Value Recap is weak when customer success teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Account Value Recap comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Customer success operations owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "account_value_recap_review_ready_rate", "baselineMetricDescription": "Share of account value recap records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, customer success platform, HubSpot, Salesforce", "collectionMethod": "Sample account value recap records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, customer success platform, HubSpot, Salesforce.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A QBR, renewal, project closeout, monthly report, or account review needs a concise value story.", "requiredEvidence": [ "customer goals", "completed work", "outcome evidence", "usage or performance data", "customer feedback", "open risks", "next recommendations", "account owner review rules" ], "aiRole": "AI prepares the account value recap record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Customer success operations owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Customer success operations owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances account value recap from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Account Value Recap does not have stable source records, owner fields, or status fields to sample.", "No accountable customer success owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 account value recap records, or all records from one customer success segment over 45 days", "pilotOwner": "Customer success operations owner", "pilotSuccessThreshold": "At least 90% of sampled account value recap records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Account Value Recap is the customer success control for account_value_recap_review_ready_rate, using gainsight-renewal-center, hubspot-health-score, salesforce-forecasting as its source boundary and the workflow terms account, value, recap. Its audit packet should carry accountvaluerecapSourceRecord, accountvaluerecapOwnerDecision, accountvaluerecapExceptionQueue, accountvaluerecapReviewOutcome, and accountvaluerecapScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Customer success operations owner, exception status, and a safe next action for account value recap specifically.", "uniqueDataTest": "Audit 100 account value recap records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep account value recap separate from adjacent customer success workflows by requiring account_value_recap_review_ready_rate, the Customer success operations owner review point, and the source boundary gainsight-renewal-center, hubspot-health-score, salesforce-forecasting. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "gainsight-renewal-center", "hubspot-health-score", "salesforce-forecasting" ] }, { "id": "customer-reactivation", "name": "Customer Reactivation", "url": "/workflow-library/customer-reactivation", "businessFunction": "Retention", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Inactive customers are easy to over-message and hard to prioritize. Teams may know who stopped buying or engaging, but not why, whether they can be contacted, what changed since the last purchase, or which reactivation offer would be relevant.", "economicLogic": "The value is disciplined revenue recovery from known relationships. The workflow should identify reachable inactive customers, separate commercial reactivation from service risk, and measure response, conversion, and opt-out outcomes by segment.", "baselineMetric": "reactivation_eligible_customer_action_rate", "baselineMetricDescription": "Share of inactive customers with eligibility reason, consent status, prior purchase or usage context, recommended path, human review status, outreach action, response, and conversion or opt-out outcome.", "sourceSystem": "CRM accounts and contacts, order/subscription records, marketing automation, messaging consent logs, support history", "collectionMethod": "Compare inactivity definition, consent, prior value, support or churn context, segment, outreach path, response, conversion, unsubscribe/opt-out, and reactivation outcome.", "leadingIndicators": [ "eligible inactive customer count", "consent-safe contact rate", "reviewed suppression rate", "reactivation action completion" ], "laggingIndicators": [ "reactivation response rate", "repeat purchase or renewal rate", "opt-out or complaint rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A customer has not purchased, booked, logged in, replied, or engaged within the defined inactivity window for their segment.", "requiredEvidence": [ "last purchase or engagement date", "customer value tier", "purchase or service history", "known churn or inactivity reason", "consent and channel permissions", "relationship notes", "available offer boundaries", "owner review rules" ], "aiRole": "AI identifies inactive customers by segment, checks consent and suppression, summarizes prior relationship context, recommends reactivation path, and drafts internal briefs or reviewed messages. It does not bypass opt-out, complaint, or sensitive-account review.", "humanReviewPoint": "Lifecycle marketing or account owner reviews suppression rules, offer fit, complaint history, high-value accounts, and any customer-facing message before launch.", "evidenceBoundary": "Sales automation, messaging policy, and marketing reporting sources support mechanics and guardrails. Reactivation lift must be measured by segment and consent-safe audience.", "stopRules": [ "The workflow contacts customers who should be suppressed.", "AI writes a generic win-back message that ignores why the customer went inactive." ], "notReadyIf": [ "Inactive customer definition is unclear.", "Consent and suppression data are unreliable.", "Prior purchase, churn, or support context is unavailable." ], "pilotDuration": "45 days", "pilotSampleSize": "First 500 inactive customers in one segment or a consent-safe sample of at least 200 customers", "pilotOwner": "Lifecycle marketing manager", "pilotSuccessThreshold": "At least 90% of selected customers have eligibility, consent, suppression, and path documented; opt-out or complaint rate stays within the pre-approved threshold.", "workflowDistinction": "Customer reactivation is a lifecycle recovery workflow for known customers. It differs from churn risk detection because the customer is already inactive or lapsed, and from lead follow-up because the relationship history and consent boundary are central.", "uniqueDataTest": "Build a reactivation cohort and verify inactivity definition, prior value, consent, suppression, support or churn context, segment, outreach path, response, conversion, opt-out, and complaint outcome. Exclusions should be as visible as sends.", "duplicateGuard": "Keep this separate from no-response follow-up and churn risk detection. Reactivation targets lapsed or inactive customers with prior relationship context; churn risk targets active accounts before loss.", "sourceRefs": [ "hubspot-sales-automation", "twilio-messaging-policy", "hubspot-marketing-reports" ] }, { "id": "lost-lead-reactivation", "name": "Lost Lead Reactivation", "url": "/workflow-library/lost-lead-reactivation", "businessFunction": "Sales", "department": "Sales", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Lost Lead Reactivation is weak when sales teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Lost Lead Reactivation comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales operations manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "lost_lead_reactivation_review_ready_rate", "baselineMetricDescription": "Share of lost lead reactivation records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, messaging platform", "collectionMethod": "Sample lost lead reactivation records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, messaging platform.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "A qualified lead has gone quiet, missed a follow-up window, stayed in a lost or stale status, or matches a timing trigger that makes reactivation relevant.", "requiredEvidence": [ "CRM lead status", "last conversation summary", "lost or stalled reason", "lead fit and value", "prior objections", "permission and channel history", "new trigger or offer reason", "sales owner review rules" ], "aiRole": "AI prepares the lost lead reactivation record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales operations manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales operations manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances lost lead reactivation from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Lost Lead Reactivation does not have stable source records, owner fields, or status fields to sample.", "No accountable sales owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 lost lead reactivation records, or all records from one sales segment over 45 days", "pilotOwner": "Sales operations manager", "pilotSuccessThreshold": "At least 90% of sampled lost lead reactivation records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Lost Lead Reactivation is the sales control for lost_lead_reactivation_review_ready_rate, using hubspot-sequences, hubspot-sales-automation, twilio-messaging-policy as its source boundary and the workflow terms lost, lead, reactivation. Its audit packet should carry lostleadreactivationSourceRecord, lostleadreactivationOwnerDecision, lostleadreactivationExceptionQueue, lostleadreactivationReviewOutcome, and lostleadreactivationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales operations manager, exception status, and a safe next action for lost lead reactivation specifically.", "uniqueDataTest": "Audit 100 lost lead reactivation records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep lost lead reactivation separate from adjacent sales workflows by requiring lost_lead_reactivation_review_ready_rate, the Sales operations manager review point, and the source boundary hubspot-sequences, hubspot-sales-automation, twilio-messaging-policy. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-sequences", "hubspot-sales-automation", "twilio-messaging-policy" ] }, { "id": "inactive-email-subscriber-reactivation", "name": "Inactive Email Subscriber Reactivation", "url": "/workflow-library/inactive-email-subscriber-reactivation", "businessFunction": "Email marketing", "department": "Marketing Ops", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Marketing Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Inactive Email Subscriber Reactivation is weak when email marketing teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Inactive Email Subscriber Reactivation comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Email marketing owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "inactive_email_subscriber_reactivation_review_ready_rate", "baselineMetricDescription": "Share of inactive email subscriber reactivation records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, messaging platform, risk review notes", "collectionMethod": "Sample inactive email subscriber reactivation records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, messaging platform, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A subscriber has not opened, clicked, purchased, replied, or engaged within the approved inactivity window for the list.", "requiredEvidence": [ "last open or click date", "last purchase or conversion", "email consent source", "send frequency", "bounce or complaint history", "subscriber value or segment", "current suppression rules", "marketing owner review rules" ], "aiRole": "AI prepares the inactive email subscriber reactivation record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Email marketing owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Email marketing owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances inactive email subscriber reactivation from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Inactive Email Subscriber Reactivation does not have stable source records, owner fields, or status fields to sample.", "No accountable email marketing owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 inactive email subscriber reactivation records, or all records from one email marketing segment over 45 days", "pilotOwner": "Email marketing owner", "pilotSuccessThreshold": "At least 90% of sampled inactive email subscriber reactivation records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Inactive Email Subscriber Reactivation is the email marketing control for inactive_email_subscriber_reactivation_review_ready_rate, using hubspot-marketing-reports, twilio-messaging-policy, nist-ai-rmf as its source boundary and the workflow terms inactive, email, subscriber, reactivation. Its audit packet should carry inactiveemailsubscriberreactivationSourceRecord, inactiveemailsubscriberreactivationOwnerDecision, inactiveemailsubscriberreactivationExceptionQueue, inactiveemailsubscriberreactivationReviewOutcome, and inactiveemailsubscriberreactivationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Email marketing owner, exception status, and a safe next action for inactive email subscriber reactivation specifically.", "uniqueDataTest": "Audit 100 inactive email subscriber reactivation records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep inactive email subscriber reactivation separate from adjacent email marketing workflows by requiring inactive_email_subscriber_reactivation_review_ready_rate, the Email marketing owner review point, and the source boundary hubspot-marketing-reports, twilio-messaging-policy, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-marketing-reports", "twilio-messaging-policy", "nist-ai-rmf" ] }, { "id": "past-client-winback", "name": "Past Client Winback", "url": "/workflow-library/past-client-winback", "businessFunction": "Retention", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 96, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Past Client Winback is weak when retention teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Past Client Winback comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Lifecycle marketing manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "past_client_winback_review_ready_rate", "baselineMetricDescription": "Share of past client winback records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, risk review notes", "collectionMethod": "Sample past client winback records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A former client reaches a winback window, a new offer or service update becomes relevant, or a seasonal/event trigger creates a credible reason to reconnect.", "requiredEvidence": [ "past client list", "last project or service outcome", "client value and fit", "relationship status", "reason for ending", "new offer or update", "permission and contact history", "owner review rules" ], "aiRole": "AI prepares the past client winback record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Lifecycle marketing manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Lifecycle marketing manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances past client winback from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Past Client Winback does not have stable source records, owner fields, or status fields to sample.", "No accountable retention owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 past client winback records, or all records from one retention segment over 45 days", "pilotOwner": "Lifecycle marketing manager", "pilotSuccessThreshold": "At least 90% of sampled past client winback records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Past Client Winback is the retention control for past_client_winback_review_ready_rate, using hubspot-sales-automation, hubspot-sequences, nist-ai-rmf as its source boundary and the workflow terms past, client, winback. Its audit packet should carry pastclientwinbackSourceRecord, pastclientwinbackOwnerDecision, pastclientwinbackExceptionQueue, pastclientwinbackReviewOutcome, and pastclientwinbackScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Lifecycle marketing manager, exception status, and a safe next action for past client winback specifically.", "uniqueDataTest": "Audit 100 past client winback records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep past client winback separate from adjacent retention workflows by requiring past_client_winback_review_ready_rate, the Lifecycle marketing manager review point, and the source boundary hubspot-sales-automation, hubspot-sequences, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-sales-automation", "hubspot-sequences", "nist-ai-rmf" ] }, { "id": "dead-opportunity-reactivation", "name": "Dead Opportunity Reactivation", "url": "/workflow-library/dead-opportunity-reactivation", "businessFunction": "Sales", "department": "Sales", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 96, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Dead Opportunity Reactivation is weak when sales teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Dead Opportunity Reactivation comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales operations manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "dead_opportunity_reactivation_review_ready_rate", "baselineMetricDescription": "Share of dead opportunity reactivation records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, Salesforce, HubSpot, call intelligence", "collectionMethod": "Sample dead opportunity reactivation records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, Salesforce, HubSpot, call intelligence.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "A closed-lost, stalled, or abandoned opportunity reaches a review window or matches a new trigger such as timing, budget, product update, case study, or role change.", "requiredEvidence": [ "opportunity stage and status", "closed-lost or stalled reason", "last objection", "last activity date", "deal value and fit", "buyer role and notes", "new trigger or reason to reconnect", "sales manager review rules" ], "aiRole": "AI prepares the dead opportunity reactivation record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales operations manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales operations manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances dead opportunity reactivation from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Dead Opportunity Reactivation does not have stable source records, owner fields, or status fields to sample.", "No accountable sales owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 dead opportunity reactivation records, or all records from one sales segment over 45 days", "pilotOwner": "Sales operations manager", "pilotSuccessThreshold": "At least 90% of sampled dead opportunity reactivation records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Dead Opportunity Reactivation is the sales control for dead_opportunity_reactivation_review_ready_rate, using salesforce-pipeline-inspection, hubspot-sequences, gong-call-intelligence as its source boundary and the workflow terms dead, opportunity, reactivation. Its audit packet should carry deadopportunityreactivationSourceRecord, deadopportunityreactivationOwnerDecision, deadopportunityreactivationExceptionQueue, deadopportunityreactivationReviewOutcome, and deadopportunityreactivationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales operations manager, exception status, and a safe next action for dead opportunity reactivation specifically.", "uniqueDataTest": "Audit 100 dead opportunity reactivation records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep dead opportunity reactivation separate from adjacent sales workflows by requiring dead_opportunity_reactivation_review_ready_rate, the Sales operations manager review point, and the source boundary salesforce-pipeline-inspection, hubspot-sequences, gong-call-intelligence. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "salesforce-pipeline-inspection", "hubspot-sequences", "gong-call-intelligence" ] }, { "id": "abandoned-quote-reactivation", "name": "Abandoned Quote Reactivation", "url": "/workflow-library/abandoned-quote-reactivation", "businessFunction": "Reactivation", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Follow-Up", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Abandoned Quote Reactivation is weak when reactivation teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Abandoned Quote Reactivation comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Lifecycle marketing manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "abandoned_quote_reactivation_review_ready_rate", "baselineMetricDescription": "Share of abandoned quote reactivation records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, proposal tool, HubSpot", "collectionMethod": "Sample abandoned quote reactivation records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, proposal tool, HubSpot.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A quote or estimate has gone quiet past the normal response window and still appears worth working.", "requiredEvidence": [ "quote or estimate", "quote age and expiration", "customer notes", "project value", "fit and urgency", "last touch history", "known objections", "pricing and scope validity" ], "aiRole": "AI prepares the abandoned quote reactivation record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Lifecycle marketing manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Lifecycle marketing manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances abandoned quote reactivation from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Abandoned Quote Reactivation does not have stable source records, owner fields, or status fields to sample.", "No accountable reactivation owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 abandoned quote reactivation records, or all records from one reactivation segment over 45 days", "pilotOwner": "Lifecycle marketing manager", "pilotSuccessThreshold": "At least 90% of sampled abandoned quote reactivation records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Abandoned Quote Reactivation is the reactivation control for abandoned_quote_reactivation_review_ready_rate, using pandadoc-conditional-approvals, pandadoc-approvals, hubspot-sequences as its source boundary and the workflow terms abandoned, quote, reactivation. Its audit packet should carry abandonedquotereactivationSourceRecord, abandonedquotereactivationOwnerDecision, abandonedquotereactivationExceptionQueue, abandonedquotereactivationReviewOutcome, and abandonedquotereactivationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Lifecycle marketing manager, exception status, and a safe next action for abandoned quote reactivation specifically.", "uniqueDataTest": "Audit 100 abandoned quote reactivation records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep abandoned quote reactivation separate from adjacent reactivation workflows by requiring abandoned_quote_reactivation_review_ready_rate, the Lifecycle marketing manager review point, and the source boundary pandadoc-conditional-approvals, pandadoc-approvals, hubspot-sequences. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "pandadoc-conditional-approvals", "pandadoc-approvals", "hubspot-sequences" ] }, { "id": "seasonal-customer-reactivation", "name": "Seasonal Customer Reactivation", "url": "/workflow-library/seasonal-customer-reactivation", "businessFunction": "Reactivation", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Seasonal Customer Reactivation is weak when reactivation teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Seasonal Customer Reactivation comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Lifecycle marketing manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "seasonal_customer_reactivation_review_ready_rate", "baselineMetricDescription": "Share of seasonal customer reactivation records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, messaging platform", "collectionMethod": "Sample seasonal customer reactivation records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, messaging platform.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A seasonal buying window approaches or last year’s customers enter the normal return window.", "requiredEvidence": [ "past purchase or service history", "seasonal window", "last contact date", "customer segment", "eligibility or consent status", "prior issues", "offer or service availability", "owner review rules" ], "aiRole": "AI prepares the seasonal customer reactivation record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Lifecycle marketing manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Lifecycle marketing manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances seasonal customer reactivation from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Seasonal Customer Reactivation does not have stable source records, owner fields, or status fields to sample.", "No accountable reactivation owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 seasonal customer reactivation records, or all records from one reactivation segment over 45 days", "pilotOwner": "Lifecycle marketing manager", "pilotSuccessThreshold": "At least 90% of sampled seasonal customer reactivation records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Seasonal Customer Reactivation is the reactivation control for seasonal_customer_reactivation_review_ready_rate, using hubspot-marketing-reports, twilio-messaging-policy, hubspot-sales-automation as its source boundary and the workflow terms seasonal, customer, reactivation. Its audit packet should carry seasonalcustomerreactivationSourceRecord, seasonalcustomerreactivationOwnerDecision, seasonalcustomerreactivationExceptionQueue, seasonalcustomerreactivationReviewOutcome, and seasonalcustomerreactivationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Lifecycle marketing manager, exception status, and a safe next action for seasonal customer reactivation specifically.", "uniqueDataTest": "Audit 100 seasonal customer reactivation records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep seasonal customer reactivation separate from adjacent reactivation workflows by requiring seasonal_customer_reactivation_review_ready_rate, the Lifecycle marketing manager review point, and the source boundary hubspot-marketing-reports, twilio-messaging-policy, hubspot-sales-automation. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-marketing-reports", "twilio-messaging-policy", "hubspot-sales-automation" ] }, { "id": "dormant-account-outreach", "name": "Dormant Account Outreach", "url": "/workflow-library/dormant-account-outreach", "businessFunction": "Reactivation", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Dormant Account Outreach is weak when reactivation teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Dormant Account Outreach comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Lifecycle marketing manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "dormant_account_outreach_review_ready_rate", "baselineMetricDescription": "Share of dormant account outreach records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, messaging platform", "collectionMethod": "Sample dormant account outreach records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, messaging platform.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "An account has no meaningful activity after the expected interval or enters a dormant segment.", "requiredEvidence": [ "last activity date", "account value", "purchase or usage history", "support or issue history", "relationship owner", "reason for inactivity if known", "consent status", "available next step or offer" ], "aiRole": "AI prepares the dormant account outreach record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Lifecycle marketing manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Lifecycle marketing manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances dormant account outreach from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Dormant Account Outreach does not have stable source records, owner fields, or status fields to sample.", "No accountable reactivation owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 dormant account outreach records, or all records from one reactivation segment over 45 days", "pilotOwner": "Lifecycle marketing manager", "pilotSuccessThreshold": "At least 90% of sampled dormant account outreach records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Dormant Account Outreach is the reactivation control for dormant_account_outreach_review_ready_rate, using hubspot-sales-automation, hubspot-health-score, twilio-messaging-policy as its source boundary and the workflow terms dormant, account, outreach. Its audit packet should carry dormantaccountoutreachSourceRecord, dormantaccountoutreachOwnerDecision, dormantaccountoutreachExceptionQueue, dormantaccountoutreachReviewOutcome, and dormantaccountoutreachScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Lifecycle marketing manager, exception status, and a safe next action for dormant account outreach specifically.", "uniqueDataTest": "Audit 100 dormant account outreach records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep dormant account outreach separate from adjacent reactivation workflows by requiring dormant_account_outreach_review_ready_rate, the Lifecycle marketing manager review point, and the source boundary hubspot-sales-automation, hubspot-health-score, twilio-messaging-policy. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-sales-automation", "hubspot-health-score", "twilio-messaging-policy" ] }, { "id": "referral-tracking", "name": "Referral Tracking", "url": "/workflow-library/referral-tracking", "businessFunction": "Referral operations", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Referral Tracking is weak when referral operations teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Referral Tracking comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Partnerships operations manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "referral_tracking_review_ready_rate", "baselineMetricDescription": "Share of referral tracking records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, Salesforce", "collectionMethod": "Sample referral tracking records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, Salesforce.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A referral is submitted, a referred lead enters the CRM, a referral source is detected, or a reward claim needs attribution review.", "requiredEvidence": [ "referrer identity", "referred lead or customer", "referral source or link", "CRM lead status", "duplicate record check", "eligibility rules", "reward status", "program owner review rules" ], "aiRole": "AI prepares the referral tracking record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Partnerships operations manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Partnerships operations manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances referral tracking from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Referral Tracking does not have stable source records, owner fields, or status fields to sample.", "No accountable referral operations owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 referral tracking records, or all records from one referral operations segment over 45 days", "pilotOwner": "Partnerships operations manager", "pilotSuccessThreshold": "At least 90% of sampled referral tracking records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Referral Tracking is the referral operations control for referral_tracking_review_ready_rate, using partnerstack-leads-deals, partnerstack-implementation, salesforce-lead-management as its source boundary and the workflow terms referral, tracking. Its audit packet should carry referraltrackingSourceRecord, referraltrackingOwnerDecision, referraltrackingExceptionQueue, referraltrackingReviewOutcome, and referraltrackingScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Partnerships operations manager, exception status, and a safe next action for referral tracking specifically.", "uniqueDataTest": "Audit 100 referral tracking records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep referral tracking separate from adjacent referral operations workflows by requiring referral_tracking_review_ready_rate, the Partnerships operations manager review point, and the source boundary partnerstack-leads-deals, partnerstack-implementation, salesforce-lead-management. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "partnerstack-leads-deals", "partnerstack-implementation", "salesforce-lead-management" ] }, { "id": "referral-request-timing", "name": "Referral Request Timing", "url": "/workflow-library/referral-request-timing", "businessFunction": "Referral operations", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Workflow Support", "riskLevel": "Low", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Referral Request Timing is weak when referral operations teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Referral Request Timing comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Partnerships operations manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "referral_request_timing_review_ready_rate", "baselineMetricDescription": "Share of referral request timing records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, risk review notes", "collectionMethod": "Sample referral request timing records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A customer gives positive feedback, reaches a visible win, renews, completes a project, upgrades, or thanks the team after a solved problem.", "requiredEvidence": [ "positive feedback or success signal", "customer outcome evidence", "relationship status", "open issues or unresolved tickets", "customer segment and fit", "preferred communication channel", "ask history", "account owner review rules" ], "aiRole": "AI prepares the referral request timing record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Partnerships operations manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Partnerships operations manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances referral request timing from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Referral Request Timing does not have stable source records, owner fields, or status fields to sample.", "No accountable referral operations owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 referral request timing records, or all records from one referral operations segment over 45 days", "pilotOwner": "Partnerships operations manager", "pilotSuccessThreshold": "At least 90% of sampled referral request timing records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Referral Request Timing is the referral operations control for referral_request_timing_review_ready_rate, using hubspot-health-score, influitive-advocate-identification, nist-ai-rmf as its source boundary and the workflow terms referral, request, timing. Its audit packet should carry referralrequesttimingSourceRecord, referralrequesttimingOwnerDecision, referralrequesttimingExceptionQueue, referralrequesttimingReviewOutcome, and referralrequesttimingScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Partnerships operations manager, exception status, and a safe next action for referral request timing specifically.", "uniqueDataTest": "Audit 100 referral request timing records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep referral request timing separate from adjacent referral operations workflows by requiring referral_request_timing_review_ready_rate, the Partnerships operations manager review point, and the source boundary hubspot-health-score, influitive-advocate-identification, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-health-score", "influitive-advocate-identification", "nist-ai-rmf" ] }, { "id": "partner-referral-management", "name": "Partner Referral Management", "url": "/workflow-library/partner-referral-management", "businessFunction": "Partner operations", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Routing", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Partner Referral Management is weak when partner operations teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Partner Referral Management comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Partner operations manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "partner_referral_management_review_ready_rate", "baselineMetricDescription": "Share of partner referral management records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, Salesforce", "collectionMethod": "Sample partner referral management records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, Salesforce.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A partner submits a referral, mentions a prospect, shares an introduction, or asks for referral status or credit.", "requiredEvidence": [ "partner identity", "referred lead details", "partner program terms", "lead fit criteria", "duplicate CRM records", "sales owner", "referral attribution rule", "partner manager review rules" ], "aiRole": "AI prepares the partner referral management record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Partner operations manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Partner operations manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances partner referral management from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Partner Referral Management does not have stable source records, owner fields, or status fields to sample.", "No accountable partner operations owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 partner referral management records, or all records from one partner operations segment over 45 days", "pilotOwner": "Partner operations manager", "pilotSuccessThreshold": "At least 90% of sampled partner referral management records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Partner Referral Management is the partner operations control for partner_referral_management_review_ready_rate, using partnerstack-leads-deals, partnerstack-implementation, salesforce-lead-management as its source boundary and the workflow terms partner, referral, management. Its audit packet should carry partnerreferralmanagementSourceRecord, partnerreferralmanagementOwnerDecision, partnerreferralmanagementExceptionQueue, partnerreferralmanagementReviewOutcome, and partnerreferralmanagementScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Partner operations manager, exception status, and a safe next action for partner referral management specifically.", "uniqueDataTest": "Audit 100 partner referral management records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep partner referral management separate from adjacent partner operations workflows by requiring partner_referral_management_review_ready_rate, the Partner operations manager review point, and the source boundary partnerstack-leads-deals, partnerstack-implementation, salesforce-lead-management. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "partnerstack-leads-deals", "partnerstack-implementation", "salesforce-lead-management" ] }, { "id": "customer-advocate-identification", "name": "Customer Advocate Identification", "url": "/workflow-library/customer-advocate-identification", "businessFunction": "Customer marketing", "department": "Customer Success", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Customer Advocate Identification is weak when customer marketing teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Customer Advocate Identification comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Customer marketing manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "customer_advocate_identification_review_ready_rate", "baselineMetricDescription": "Share of customer advocate identification records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, customer success platform", "collectionMethod": "Sample customer advocate identification records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, customer success platform.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "A customer gives positive feedback, renews, achieves a clear result, submits a referral, leaves a good review, or becomes a strong reference candidate.", "requiredEvidence": [ "positive feedback", "customer outcome evidence", "renewal or expansion status", "support or service history", "referral activity", "public review or testimonial history", "permission status", "account owner review rules" ], "aiRole": "AI prepares the customer advocate identification record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Customer marketing manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Customer marketing manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances customer advocate identification from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Customer Advocate Identification does not have stable source records, owner fields, or status fields to sample.", "No accountable customer marketing owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 customer advocate identification records, or all records from one customer marketing segment over 45 days", "pilotOwner": "Customer marketing manager", "pilotSuccessThreshold": "At least 90% of sampled customer advocate identification records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Customer Advocate Identification is the customer marketing control for customer_advocate_identification_review_ready_rate, using influitive-advocate-identification, hubspot-health-score, gainsight-health-score as its source boundary and the workflow terms customer, advocate, identification. Its audit packet should carry customeradvocateidentificationSourceRecord, customeradvocateidentificationOwnerDecision, customeradvocateidentificationExceptionQueue, customeradvocateidentificationReviewOutcome, and customeradvocateidentificationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Customer marketing manager, exception status, and a safe next action for customer advocate identification specifically.", "uniqueDataTest": "Audit 100 customer advocate identification records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep customer advocate identification separate from adjacent customer marketing workflows by requiring customer_advocate_identification_review_ready_rate, the Customer marketing manager review point, and the source boundary influitive-advocate-identification, hubspot-health-score, gainsight-health-score. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "influitive-advocate-identification", "hubspot-health-score", "gainsight-health-score" ] }, { "id": "referral-reward-processing", "name": "Referral Reward Processing", "url": "/workflow-library/referral-reward-processing", "businessFunction": "Referral operations", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Workflow Support", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Referral Reward Processing is weak when referral operations teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Referral Reward Processing comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Partnerships operations manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "referral_reward_processing_review_ready_rate", "baselineMetricDescription": "Share of referral reward processing records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, risk review notes", "collectionMethod": "Sample referral reward processing records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A referred lead converts, a referrer requests credit, a reward becomes due, or referral attribution changes after conversion.", "requiredEvidence": [ "referral tracking record", "conversion event", "referrer eligibility", "program reward rules", "attribution confidence", "duplicate or self-referral check", "payment or discount method", "approval rules" ], "aiRole": "AI prepares the referral reward processing record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Partnerships operations manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Partnerships operations manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances referral reward processing from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Referral Reward Processing does not have stable source records, owner fields, or status fields to sample.", "No accountable referral operations owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 referral reward processing records, or all records from one referral operations segment over 45 days", "pilotOwner": "Partnerships operations manager", "pilotSuccessThreshold": "At least 90% of sampled referral reward processing records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Referral Reward Processing is the referral operations control for referral_reward_processing_review_ready_rate, using partnerstack-implementation, partnerstack-leads-deals, nist-ai-rmf as its source boundary and the workflow terms referral, reward, processing. Its audit packet should carry referralrewardprocessingSourceRecord, referralrewardprocessingOwnerDecision, referralrewardprocessingExceptionQueue, referralrewardprocessingReviewOutcome, and referralrewardprocessingScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Partnerships operations manager, exception status, and a safe next action for referral reward processing specifically.", "uniqueDataTest": "Audit 100 referral reward processing records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep referral reward processing separate from adjacent referral operations workflows by requiring referral_reward_processing_review_ready_rate, the Partnerships operations manager review point, and the source boundary partnerstack-implementation, partnerstack-leads-deals, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "partnerstack-implementation", "partnerstack-leads-deals", "nist-ai-rmf" ] }, { "id": "testimonial-request-workflow", "name": "Testimonial Request", "url": "/workflow-library/testimonial-request-workflow", "businessFunction": "Customer marketing", "department": "Customer Success", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Testimonial Request is weak when customer marketing teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Testimonial Request comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Customer marketing manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "testimonial_request_workflow_review_ready_rate", "baselineMetricDescription": "Share of testimonial request records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, risk review notes", "collectionMethod": "Sample testimonial request records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A customer achieves a clear result, gives positive feedback, completes a successful project, renews, upgrades, or provides unsolicited praise.", "requiredEvidence": [ "positive signal", "customer outcome evidence", "relationship status", "open issues", "preferred testimonial format", "permission requirements", "prior ask history", "owner review rules" ], "aiRole": "AI prepares the testimonial request record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Customer marketing manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Customer marketing manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances testimonial request from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Testimonial Request does not have stable source records, owner fields, or status fields to sample.", "No accountable customer marketing owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 testimonial request records, or all records from one customer marketing segment over 45 days", "pilotOwner": "Customer marketing manager", "pilotSuccessThreshold": "At least 90% of sampled testimonial request records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Testimonial Request is the customer marketing control for testimonial_request_workflow_review_ready_rate, using trustpilot-review-invitations, influitive-advocate-identification, nist-ai-rmf as its source boundary and the workflow terms testimonial, request, workflow. Its audit packet should carry testimonialrequestworkflowSourceRecord, testimonialrequestworkflowOwnerDecision, testimonialrequestworkflowExceptionQueue, testimonialrequestworkflowReviewOutcome, and testimonialrequestworkflowScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Customer marketing manager, exception status, and a safe next action for testimonial request specifically.", "uniqueDataTest": "Audit 100 testimonial request records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep testimonial request separate from adjacent customer marketing workflows by requiring testimonial_request_workflow_review_ready_rate, the Customer marketing manager review point, and the source boundary trustpilot-review-invitations, influitive-advocate-identification, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "trustpilot-review-invitations", "influitive-advocate-identification", "nist-ai-rmf" ] }, { "id": "case-study-candidate-selection", "name": "Case Study Candidate Selection", "url": "/workflow-library/case-study-candidate-selection", "businessFunction": "Customer marketing", "department": "Customer Success", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Directional", "buyerProblem": "Case study candidate selection is weak when marketing asks for case studies from visible customers without checking outcome evidence, relationship health, permission, segment fit, and story risk. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in case study candidate selection. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "case_study_candidate_readiness_rate", "baselineMetricDescription": "Share of proposed case study candidates with outcome evidence, account health, permission status, segment fit, story angle, and account-owner approval.", "sourceSystem": "customer success platform, CRM, advocacy tool, survey responses, account notes, permission tracker", "collectionMethod": "Compare candidate list to health scores, outcome notes, account owner review, permission status, and final case-study disposition.", "leadingIndicators": [ "outcome evidence coverage", "ICP/story fit", "permission readiness", "sales-use case match" ], "laggingIndicators": [ "case study completed", "sales reuse", "customer approval cycle time" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A customer shows strong results, gives positive feedback, renews, expands, completes a successful project, or matches a strategic proof gap.", "requiredEvidence": [ "customer outcome evidence", "before and after context", "customer segment and fit", "story angle", "sales proof gap", "permission and sensitivity status", "account relationship notes", "marketing review rules" ], "aiRole": "AI finds candidate accounts by combining health signals, outcomes, product usage, feedback, segment fit, and advocacy history, then flags permission and story gaps.", "humanReviewPoint": "Customer marketing and the account owner review customer relationship risk, proof strength, permission, sensitive details, and final outreach timing.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI recommends outreach to a customer with hidden risk, weak evidence, or no permission path.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "Customer outcome notes, account owner, health status, or permission process is missing.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "Top 50 healthy accounts or all accounts with recent positive feedback in one quarter", "pilotOwner": "Customer marketing manager", "pilotSuccessThreshold": "At least 80% of shortlisted candidates have account-owner approval, evidence notes, and permission path before outreach.", "workflowDistinction": "Case study candidate selection owns selecting safe, evidence-backed candidates for case studies, not writing the case study or extracting general buyer language. Its proof object is case_study_candidate_readiness_rate from customer success platform, CRM, advocacy tool, survey responses, account notes, permission tracker, with Customer marketing manager accountable for review. Do not merge with testimonial request workflow or buyer-language extraction. Candidate selection is a readiness and risk screen before asking for a story.", "uniqueDataTest": "Sample candidates and verify outcome evidence, account health, segment fit, permission status, owner approval, and outreach disposition. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Do not merge with testimonial request workflow or buyer-language extraction. Candidate selection is a readiness and risk screen before asking for a story.", "sourceRefs": [ "influitive-advocate-identification", "hubspot-value-proposition", "hubspot-stp" ] }, { "id": "warm-introduction-tracking", "name": "Warm Introduction Tracking", "url": "/workflow-library/warm-introduction-tracking", "businessFunction": "Referral systems", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Follow-Up", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 92, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Warm Introduction Tracking is weak when referral systems teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Warm Introduction Tracking comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Partnerships operations manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "warm_introduction_tracking_review_ready_rate", "baselineMetricDescription": "Share of warm introduction tracking records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce, risk review notes", "collectionMethod": "Sample warm introduction tracking records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Low", "dataReadiness": "Messy", "trigger": "A partner, customer, advisor, or contact offers or sends a warm introduction.", "requiredEvidence": [ "introducer name", "recipient and company", "permission or consent context", "reason for introduction", "source relationship", "intro message", "owner", "next action and thank-you rules" ], "aiRole": "AI prepares the warm introduction tracking record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Partnerships operations manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Partnerships operations manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances warm introduction tracking from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Warm Introduction Tracking does not have stable source records, owner fields, or status fields to sample.", "No accountable referral systems owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 warm introduction tracking records, or all records from one referral systems segment over 45 days", "pilotOwner": "Partnerships operations manager", "pilotSuccessThreshold": "At least 90% of sampled warm introduction tracking records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Warm Introduction Tracking is the referral systems control for warm_introduction_tracking_review_ready_rate, using hubspot-sales-automation, salesforce-lead-management, nist-ai-rmf as its source boundary and the workflow terms warm, introduction, tracking. Its audit packet should carry warmintroductiontrackingSourceRecord, warmintroductiontrackingOwnerDecision, warmintroductiontrackingExceptionQueue, warmintroductiontrackingReviewOutcome, and warmintroductiontrackingScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Partnerships operations manager, exception status, and a safe next action for warm introduction tracking specifically.", "uniqueDataTest": "Audit 100 warm introduction tracking records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep warm introduction tracking separate from adjacent referral systems workflows by requiring warm_introduction_tracking_review_ready_rate, the Partnerships operations manager review point, and the source boundary hubspot-sales-automation, salesforce-lead-management, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-sales-automation", "salesforce-lead-management", "nist-ai-rmf" ] }, { "id": "customer-success-handoff", "name": "Customer Success Handoff", "url": "/workflow-library/customer-success-handoff", "businessFunction": "Customer success", "department": "Customer Success", "revenueLeak": "Retention Risk", "kpi": "Retention Rate", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Sales-to-CS handoff breaks when the customer hears the same discovery questions again or when promises made during sales vanish from the success plan. The handoff needs relationship context, success criteria, commitments, stakeholders, risks, and commercial history, not a generic CRM summary.", "economicLogic": "The value is retention-risk prevention at the moment ownership changes. A strong handoff reduces early trust loss, avoids missed promises, and gives CS a realistic starting point for onboarding and expansion planning.", "baselineMetric": "sales_to_cs_handoff_acceptance_rate", "baselineMetricDescription": "Share of closed-won accounts where CS accepts a handoff packet with stakeholders, use case, success criteria, commitments, risks, next steps, and missing-context exceptions documented.", "sourceSystem": "CRM opportunity, call intelligence transcripts, contract/SOW, onboarding project, customer success platform", "collectionMethod": "Compare closed-won records to handoff packet completion, CS acceptance, missing context exceptions, kickoff plan, and first 30-day customer risk notes.", "leadingIndicators": [ "handoff packet completeness", "CS acceptance rate", "promise exception count", "missing stakeholder count" ], "laggingIndicators": [ "first 30-day escalation rate", "onboarding delay rate", "early churn or downgrade signal" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A deal moves to closed-won, a customer is assigned to onboarding, or a kickoff date is scheduled.", "requiredEvidence": [ "deal notes and call summaries", "signed scope or order form", "customer goals and success criteria", "stakeholder map", "promises or commitments made during sales", "implementation requirements", "known risks, objections, and sensitivities", "kickoff date and first-value milestone" ], "aiRole": "AI assembles a handoff packet from opportunity data, call notes, contract/SOW, stakeholder history, success criteria, risks, and open promises, then flags gaps and exceptions. It does not decide that CS has accepted the account.", "humanReviewPoint": "Sales owner confirms commitments and relationship context; CS owner accepts or rejects the packet; delivery or legal reviews any promise, scope, or timeline exception before kickoff.", "evidenceBoundary": "Sources support handoff, onboarding, and call intelligence mechanics. Retention impact must be measured through customer cohorts and early risk signals.", "stopRules": [ "AI summarizes sales conversations but misses unapproved promises.", "The handoff is complete on paper but not accepted by CS." ], "notReadyIf": [ "Closed-won criteria are inconsistent.", "Sales calls or notes are not accessible.", "CS has no acceptance/rejection field for handoff quality." ], "pilotDuration": "45 days", "pilotSampleSize": "First 25 closed-won accounts or all new customers in one segment for a quarter", "pilotOwner": "Customer success operations lead", "pilotSuccessThreshold": "At least 90% of handoff packets are accepted by CS without critical missing context, and all promise exceptions have owner decision before kickoff.", "workflowDistinction": "Customer success handoff is an ownership-transfer workflow. It captures what sales learned and promised so CS can accept the customer. Client onboarding then turns that context into tasks, kickoff, access, and milestones.", "uniqueDataTest": "For closed-won accounts, verify stakeholder map, success criteria, promised outcomes, contract/SOW match, risks, open questions, CS acceptance, kickoff plan, and first 30-day escalation notes. Any unowned promise exception fails the test.", "duplicateGuard": "Keep separate from client onboarding and customer onboarding health checks. Handoff proves CS received and accepted context; onboarding health checks monitor whether the new customer is progressing after launch begins.", "sourceRefs": [ "hubspot-sales-cs-handoff", "hubspot-customer-onboarding", "gong-call-intelligence" ] }, { "id": "support-escalation-summaries", "name": "Support Escalation Summaries", "url": "/workflow-library/support-escalation-summaries", "businessFunction": "Customer success", "department": "Customer Success", "revenueLeak": "Retention Risk", "kpi": "Retention Rate", "workflowType": "Review", "riskLevel": "High", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 92, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Support Escalation Summaries is weak when customer success teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Support Escalation Summaries comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Customer success operations owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "support_escalation_summaries_review_ready_rate", "baselineMetricDescription": "Share of support escalation summaries records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, support platform, project management or knowledge base", "collectionMethod": "Sample support escalation summaries records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, support platform, project management or knowledge base.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A ticket is escalated, severity changes, a customer asks for a manager, or a deadline is missed.", "requiredEvidence": [ "ticket thread and internal notes", "customer account context", "severity and SLA rules", "troubleshooting steps already tried", "customer sentiment and business impact", "promised response time", "current owner and escalation path", "related tickets or known incidents" ], "aiRole": "AI prepares the support escalation summaries record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Customer success operations owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Customer success operations owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances support escalation summaries from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Support Escalation Summaries does not have stable source records, owner fields, or status fields to sample.", "No accountable customer success owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 support escalation summaries records, or all records from one customer success segment over 45 days", "pilotOwner": "Customer success operations owner", "pilotSuccessThreshold": "At least 90% of sampled support escalation summaries records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Support Escalation Summaries is the customer success control for support_escalation_summaries_review_ready_rate, using zendesk-intelligent-triage, zendesk-ticket-summaries, atlassian-priority-levels as its source boundary and the workflow terms support, escalation, summaries. Its audit packet should carry supportescalationsummariesSourceRecord, supportescalationsummariesOwnerDecision, supportescalationsummariesExceptionQueue, supportescalationsummariesReviewOutcome, and supportescalationsummariesScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Customer success operations owner, exception status, and a safe next action for support escalation summaries specifically.", "uniqueDataTest": "Audit 100 support escalation summaries records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep support escalation summaries separate from adjacent customer success workflows by requiring support_escalation_summaries_review_ready_rate, the Customer success operations owner review point, and the source boundary zendesk-intelligent-triage, zendesk-ticket-summaries, atlassian-priority-levels. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "zendesk-intelligent-triage", "zendesk-ticket-summaries", "atlassian-priority-levels" ] }, { "id": "customer-qbr-preparation", "name": "Customer QBR Preparation", "url": "/workflow-library/customer-qbr-preparation", "businessFunction": "Customer success", "department": "Customer Success", "revenueLeak": "Retention Risk", "kpi": "Retention Rate", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 96, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Customer QBR Preparation is weak when customer success teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Customer QBR Preparation comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Customer success operations owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "customer_qbr_preparation_review_ready_rate", "baselineMetricDescription": "Share of customer qbr preparation records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, customer success platform, HubSpot", "collectionMethod": "Sample customer qbr preparation records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, customer success platform, HubSpot.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A QBR is scheduled, a renewal window approaches, or an account owner requests a business review brief.", "requiredEvidence": [ "customer goals and prior commitments", "usage or adoption data", "support and escalation history", "project or delivery outcomes", "renewal and expansion context", "open risks and blockers", "stakeholder list", "last meeting notes and next steps" ], "aiRole": "AI prepares the customer qbr preparation record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Customer success operations owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Customer success operations owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances customer qbr preparation from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Customer QBR Preparation does not have stable source records, owner fields, or status fields to sample.", "No accountable customer success owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 customer qbr preparation records, or all records from one customer success segment over 45 days", "pilotOwner": "Customer success operations owner", "pilotSuccessThreshold": "At least 90% of sampled customer qbr preparation records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Customer QBR Preparation is the customer success control for customer_qbr_preparation_review_ready_rate, using gainsight-qbr-template, pendo-customer-success, hubspot-health-score as its source boundary and the workflow terms customer, qbr, preparation. Its audit packet should carry customerqbrpreparationSourceRecord, customerqbrpreparationOwnerDecision, customerqbrpreparationExceptionQueue, customerqbrpreparationReviewOutcome, and customerqbrpreparationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Customer success operations owner, exception status, and a safe next action for customer qbr preparation specifically.", "uniqueDataTest": "Audit 100 customer qbr preparation records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep customer qbr preparation separate from adjacent customer success workflows by requiring customer_qbr_preparation_review_ready_rate, the Customer success operations owner review point, and the source boundary gainsight-qbr-template, pendo-customer-success, hubspot-health-score. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "gainsight-qbr-template", "pendo-customer-success", "hubspot-health-score" ] }, { "id": "feature-request-triage", "name": "Feature Request Triage", "url": "/workflow-library/feature-request-triage", "businessFunction": "Customer success", "department": "Customer Success", "revenueLeak": "Retention Risk", "kpi": "Retention Rate", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Feature Request Triage is weak when customer success teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Feature Request Triage comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Customer success operations owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "feature_request_triage_review_ready_rate", "baselineMetricDescription": "Share of feature request triage records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, support platform", "collectionMethod": "Sample feature request triage records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, support platform.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "A feature request is submitted through support, sales, customer success, a feedback form, or a customer call.", "requiredEvidence": [ "raw request and source quote", "customer account and segment", "business impact or blocker", "workaround currently used", "request frequency and duplicate matches", "linked tickets or calls", "product area and owner", "roadmap or strategy tags" ], "aiRole": "AI prepares the feature request triage record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Customer success operations owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Customer success operations owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances feature request triage from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Feature Request Triage does not have stable source records, owner fields, or status fields to sample.", "No accountable customer success owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 feature request triage records, or all records from one customer success segment over 45 days", "pilotOwner": "Customer success operations owner", "pilotSuccessThreshold": "At least 90% of sampled feature request triage records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Feature Request Triage is the customer success control for feature_request_triage_review_ready_rate, using productboard-overview, productboard-feature-ideas, zendesk-ticket-summaries as its source boundary and the workflow terms feature, request, triage. Its audit packet should carry featurerequesttriageSourceRecord, featurerequesttriageOwnerDecision, featurerequesttriageExceptionQueue, featurerequesttriageReviewOutcome, and featurerequesttriageScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Customer success operations owner, exception status, and a safe next action for feature request triage specifically.", "uniqueDataTest": "Audit 100 feature request triage records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep feature request triage separate from adjacent customer success workflows by requiring feature_request_triage_review_ready_rate, the Customer success operations owner review point, and the source boundary productboard-overview, productboard-feature-ideas, zendesk-ticket-summaries. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "productboard-overview", "productboard-feature-ideas", "zendesk-ticket-summaries" ] }, { "id": "support-ticket-summarization", "name": "Support Ticket Summarization", "url": "/workflow-library/support-ticket-summarization", "businessFunction": "Customer success", "department": "Customer Success", "revenueLeak": "Retention Risk", "kpi": "Retention Rate", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 92, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Support tickets pile up with long threads, duplicate context, customer frustration, and hidden escalation risk. A short summary helps only if it preserves the customer's issue, attempted fixes, sentiment, product area, SLA status, and what the next agent should do.", "economicLogic": "The value is faster, safer handoff inside support. The workflow should reduce rereading time, make escalation signals visible, and prevent agents from missing commitments or sensitive context when a ticket changes owner.", "baselineMetric": "support_summary_actionability_rate", "baselineMetricDescription": "Share of summarized tickets where issue, customer impact, attempted steps, sentiment, SLA/escalation status, next action, and confidence/review flag are accepted by a support agent.", "sourceSystem": "Support ticketing platform, AI summary tool, knowledge base, SLA records, customer account records", "collectionMethod": "Compare generated summaries to ticket threads, agent edits, escalation status, SLA status, resolution notes, and customer satisfaction or reopen outcomes.", "leadingIndicators": [ "agent summary acceptance", "summary edit rate", "SLA/escalation flag coverage", "duplicate context removed" ], "laggingIndicators": [ "handle time", "reopen rate", "CSAT after summarized handoff" ], "implementationEffort": "Low", "dataReadiness": "Clean", "trigger": "A ticket is reassigned, reopened, escalated, transferred from a bot, or grows beyond a set number of messages.", "requiredEvidence": [ "public ticket conversation", "internal notes", "bot transcript or chat handoff", "customer account context", "steps tried and answers given", "attachments or links", "current owner and status", "deadline or SLA context" ], "aiRole": "AI summarizes the ticket thread into structured fields, detects missing context, highlights sentiment or escalation, and suggests the next internal action. It does not close tickets, promise fixes, or send customer replies without agent review.", "humanReviewPoint": "Support agent reviews summaries used for handoff, escalation, or customer-facing replies, especially when SLA, refund, legal, outage, security, or product-defect language appears.", "evidenceBoundary": "Zendesk sources support ticket summarization and triage mechanics. Handle-time or CSAT impact must be measured by queue and ticket category.", "stopRules": [ "AI compresses away the detail that explains customer impact.", "The summary invents a resolution or commitment." ], "notReadyIf": [ "Ticket threads are inaccessible.", "SLA/escalation status is not captured.", "Agents cannot accept, edit, or reject summaries." ], "pilotDuration": "30 days", "pilotSampleSize": "First 300 tickets in one queue or all tickets in a high-volume support category", "pilotOwner": "Support operations manager", "pilotSuccessThreshold": "At least 85% of summaries are accepted with minor or no edits; critical SLA, escalation, and customer-impact details are not missed in reviewed tickets.", "workflowDistinction": "Support ticket summarization is a context-compression workflow for service operations. It differs from ticket triage because the primary output is an accepted internal summary and next action, not assignment or category routing alone.", "uniqueDataTest": "Sample summarized tickets and compare the summary to the full thread for issue, impact, attempted steps, product area, sentiment, SLA, escalation, next action, and agent edit. Track reopen or escalation misses after summary use.", "duplicateGuard": "Do not merge with support ticket triage or customer health scoring. This workflow owns the summary quality, source fidelity, escalation visibility, and handoff actionability of a ticket thread; triage owns assignment, and health scoring owns account-level risk.", "sourceRefs": [ "zendesk-ticket-summaries", "zendesk-intelligent-triage", "nist-ai-rmf" ] }, { "id": "customer-onboarding-health-checks", "name": "Customer Onboarding Health Checks", "url": "/workflow-library/customer-onboarding-health-checks", "businessFunction": "Customer success", "department": "Customer Success", "revenueLeak": "Retention Risk", "kpi": "Retention Rate", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 96, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "New customers can look fine until the first milestone is missed. Access delays, low product usage, unconfirmed stakeholders, unclear success criteria, and support tickets signal risk early, but those signals often remain separate from the onboarding plan.", "economicLogic": "The value is early intervention before onboarding becomes renewal risk. The workflow should identify customers slipping from launch readiness to stalled adoption and assign corrective action while the relationship is still new.", "baselineMetric": "onboarding_health_exception_resolution_rate", "baselineMetricDescription": "Share of onboarding accounts with health exceptions reviewed and resolved across access, usage, stakeholder, milestone, support, success-criteria, owner-action, and first-value signals.", "sourceSystem": "Onboarding project tool, customer success platform, product analytics, support tickets, CRM account records", "collectionMethod": "Compare onboarding milestones, product usage, access completion, stakeholder confirmations, support tickets, CSM notes, exception actions, and first value status.", "leadingIndicators": [ "access blocker count", "first usage milestone completion", "stakeholder confirmation rate", "onboarding exception age" ], "laggingIndicators": [ "time to first value", "onboarding completion rate", "early churn or escalation signal" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A customer enters onboarding, misses a milestone, goes quiet, or approaches the first-value deadline.", "requiredEvidence": [ "onboarding plan", "milestone status", "access and setup tasks", "stakeholder attendance", "support tickets", "success criteria", "timeline commitments", "owner notes" ], "aiRole": "AI monitors onboarding milestones, access status, usage, support tickets, stakeholder confirmation, and CSM notes, then flags exceptions with likely blocker and recommended internal action. It does not send risk messages or change onboarding commitments without CSM review.", "humanReviewPoint": "CSM or onboarding lead reviews health exceptions, customer-facing outreach, milestone changes, escalation, and any interpretation that could affect the customer's trust in the onboarding plan.", "evidenceBoundary": "Onboarding, product analytics, and health-score sources support mechanics. The link between onboarding signals and retention needs cohort validation.", "stopRules": [ "The workflow confuses normal ramp-up with account risk.", "Health checks trigger customer-facing concern without context." ], "notReadyIf": [ "Onboarding milestones are not defined.", "Product usage or access signals are unavailable.", "Exception actions are not tracked." ], "pilotDuration": "60 days", "pilotSampleSize": "First 50 onboarding accounts or all accounts in one onboarding cohort", "pilotOwner": "Customer success operations lead", "pilotSuccessThreshold": "At least 90% of material onboarding health exceptions have owner, action, and resolution status before the first value milestone is missed.", "workflowDistinction": "Customer onboarding health checks monitor early customer progress after onboarding starts. They differ from client onboarding, which prepares the launch plan, and from general health scoring, which covers the broader customer lifecycle.", "uniqueDataTest": "Review onboarding accounts for milestone status, access completion, product usage, stakeholder confirmation, support tickets, CSM action, exception resolution, and first value outcome. Alerts should be judged against stage-specific expectations.", "duplicateGuard": "Keep separate from client onboarding and customer health scoring. This workflow owns early lifecycle exception detection, not launch packet creation or mature-account health modeling.", "sourceRefs": [ "hubspot-customer-onboarding", "pendo-customer-success", "hubspot-health-score" ] }, { "id": "account-expansion-signals", "name": "Account Expansion Signals", "url": "/workflow-library/account-expansion-signals", "businessFunction": "Customer success", "department": "Customer Success", "revenueLeak": "Retention Risk", "kpi": "Retention Rate", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Account Expansion Signals is weak when customer success teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Account Expansion Signals comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Customer success operations owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "account_expansion_signals_review_ready_rate", "baselineMetricDescription": "Share of account expansion signals records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, customer success platform", "collectionMethod": "Sample account expansion signals records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, customer success platform.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A customer shows higher usage, asks about adjacent needs, reaches a value milestone, expands teams, or enters a review window.", "requiredEvidence": [ "usage or engagement trends", "customer goals", "outcome evidence", "stakeholder requests", "support or risk history", "renewal timing", "current package or scope", "account owner notes" ], "aiRole": "AI prepares the account expansion signals record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Customer success operations owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Customer success operations owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances account expansion signals from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Account Expansion Signals does not have stable source records, owner fields, or status fields to sample.", "No accountable customer success owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 account expansion signals records, or all records from one customer success segment over 45 days", "pilotOwner": "Customer success operations owner", "pilotSuccessThreshold": "At least 90% of sampled account expansion signals records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Account Expansion Signals is the customer success control for account_expansion_signals_review_ready_rate, using pendo-customer-success, hubspot-health-score, gainsight-health-score as its source boundary and the workflow terms account, expansion, signals. Its audit packet should carry accountexpansionsignalsSourceRecord, accountexpansionsignalsOwnerDecision, accountexpansionsignalsExceptionQueue, accountexpansionsignalsReviewOutcome, and accountexpansionsignalsScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Customer success operations owner, exception status, and a safe next action for account expansion signals specifically.", "uniqueDataTest": "Audit 100 account expansion signals records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep account expansion signals separate from adjacent customer success workflows by requiring account_expansion_signals_review_ready_rate, the Customer success operations owner review point, and the source boundary pendo-customer-success, hubspot-health-score, gainsight-health-score. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "pendo-customer-success", "hubspot-health-score", "gainsight-health-score" ] }, { "id": "customer-risk-review", "name": "Customer Risk Review", "url": "/workflow-library/customer-risk-review", "businessFunction": "Customer success", "department": "Customer Success", "revenueLeak": "Retention Risk", "kpi": "Retention Rate", "workflowType": "Review", "riskLevel": "High", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 95, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Customer Risk Review is weak when customer success teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Customer Risk Review comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Customer success operations owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "customer_risk_review_review_ready_rate", "baselineMetricDescription": "Share of customer risk review records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, risk review notes, HubSpot, customer success platform", "collectionMethod": "Sample customer risk review records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, risk review notes, HubSpot, customer success platform.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "An account crosses a risk threshold, usage changes materially, support friction increases, or the CSM schedules a weekly risk review.", "requiredEvidence": [ "usage or activity trends", "customer goal and outcome notes", "support tickets", "CSM notes", "stakeholder changes", "sentiment or survey notes", "renewal timing", "previous risk history" ], "aiRole": "AI prepares the customer risk review record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Customer success operations owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Customer success operations owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances customer risk review from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Customer Risk Review does not have stable source records, owner fields, or status fields to sample.", "No accountable customer success owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 customer risk review records, or all records from one customer success segment over 45 days", "pilotOwner": "Customer success operations owner", "pilotSuccessThreshold": "At least 90% of sampled customer risk review records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Customer Risk Review is the customer success control for customer_risk_review_review_ready_rate, using nist-ai-rmf, hubspot-health-score, gainsight-renewal-center as its source boundary and the workflow terms customer, risk, review. Its audit packet should carry customerriskreviewSourceRecord, customerriskreviewOwnerDecision, customerriskreviewExceptionQueue, customerriskreviewReviewOutcome, and customerriskreviewScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Customer success operations owner, exception status, and a safe next action for customer risk review specifically.", "uniqueDataTest": "Audit 100 customer risk review records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep customer risk review separate from adjacent customer success workflows by requiring customer_risk_review_review_ready_rate, the Customer success operations owner review point, and the source boundary nist-ai-rmf, hubspot-health-score, gainsight-renewal-center. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "nist-ai-rmf", "hubspot-health-score", "gainsight-renewal-center" ] }, { "id": "offer-audit", "name": "Offer Audit", "url": "/workflow-library/offer-audit", "businessFunction": "Offer clarity", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Offer audit is weak when an offer page or sales package can be appealing but still unclear about buyer, promise, deliverables, proof, exclusions, and next step. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in offer audit. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "offer_clarity_exception_rate", "baselineMetricDescription": "Share of audited offer elements with unresolved buyer-fit, promise, deliverable, proof, exclusion, pricing, or CTA exceptions after owner review.", "sourceSystem": "website CMS, sales collateral, proposal templates, CRM objection notes, customer interview repository", "collectionMethod": "Score each offer element against fit, promise, evidence, scope, pricing, CTA, and owner approval fields before publishing.", "leadingIndicators": [ "asset consistency score", "scope conflict count", "proof coverage", "poor-fit objection count" ], "laggingIndicators": [ "proposal clarification reduction", "poor-fit lead reduction", "delivery expectation conflict" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "A service offer, proposal, pricing page, or sales page is underperforming, being relaunched, or being prepared for a campaign.", "requiredEvidence": [ "current offer page or proposal", "target buyer and use case", "customer language and sales-call notes", "proof points and case examples", "scope, exclusions, and delivery capacity", "price or pricing logic", "objections and FAQ", "desired next step" ], "aiRole": "AI prepares an offer clarity brief by comparing page language, collateral, objections, and proof assets, then flags missing claims, exclusions, unclear CTAs, and unsupported promises.", "humanReviewPoint": "The offer owner approves the buyer promise, pricing or scope language, proof claims, exclusions, and any recommendation that changes the customer-facing offer.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI recommends a stronger offer promise without proof, delivery capacity, or margin review.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "There is no named offer owner, current offer page, proof inventory, or list of common buyer objections.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "One primary service offer plus the first 30 related sales calls, objections, proposals, and website inquiries", "pilotOwner": "Growth lead", "pilotSuccessThreshold": "At least 90% of audited offer elements have an owner decision and no unresolved critical clarity exception before page or collateral update.", "workflowDistinction": "Offer audit owns auditing the commercial offer as a promise, proof, scope, and CTA system, not creating new positioning or writing generic website copy. Its proof object is offer_clarity_exception_rate from website CMS, sales collateral, proposal templates, CRM objection notes, customer interview repository, with Growth lead accountable for review. Do not merge with service package creation or pricing page clarity. Offer audit evaluates an existing offer's promise and evidence; package creation designs the package, while pricing clarity focuses on price and plan explanation.", "uniqueDataTest": "Compare every offer claim to source proof, objections, proposal scope, and owner approval so the audit produces a decision queue rather than copy suggestions. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Do not merge with service package creation or pricing page clarity. Offer audit evaluates an existing offer's promise and evidence; package creation designs the package, while pricing clarity focuses on price and plan explanation.", "sourceRefs": [ "hubspot-value-proposition", "hubspot-stp", "nist-ai-rmf" ] }, { "id": "service-package-creation", "name": "Service Package Creation", "url": "/workflow-library/service-package-creation", "businessFunction": "Offer clarity", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Directional", "buyerProblem": "Service package creation is weak when services get packaged around internal activities instead of buyer problem, deliverables, scope boundary, proof, price logic, and delivery readiness. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in service package creation. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "package_readiness_exception_rate", "baselineMetricDescription": "Share of proposed service package fields with unresolved buyer, deliverable, proof, scope, pricing, approval, or delivery-capacity exceptions.", "sourceSystem": "service catalog, proposal templates, CRM closed-won notes, delivery playbooks, approval workflow", "collectionMethod": "Review package drafts against buyer problem, deliverable inventory, scope boundary, proof source, price driver, and delivery owner fields.", "leadingIndicators": [ "deliverable definition", "exclusion coverage", "price basis clarity", "delivery approval" ], "laggingIndicators": [ "proposal reuse", "scope clarification reduction", "delivery margin exception count" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A service needs to be packaged, productized, simplified, or turned into a repeatable offer.", "requiredEvidence": [ "existing service descriptions", "past proposals and SOWs", "delivery tasks and milestones", "common client outcomes", "scope boundaries and exclusions", "timeline and dependencies", "pricing or margin requirements", "acceptance criteria and review rounds" ], "aiRole": "AI assembles package options from existing proposals, delivery playbooks, buyer objections, and proof assets, then flags missing scope, proof, capacity, and approval fields.", "humanReviewPoint": "Service leadership reviews deliverables, exclusions, proof claims, margin assumptions, price language, delivery capacity, and customer-facing package language.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI creates a package that sounds saleable but cannot be delivered profitably or consistently.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "The business lacks reusable proposal, delivery, and proof assets for the service area.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "Three proposed service packages or one package with 20 related proposals and delivery notes", "pilotOwner": "Service line owner", "pilotSuccessThreshold": "At least 90% of required package fields receive an owner decision and no package launches with unresolved scope or proof exceptions.", "workflowDistinction": "Service package creation owns building a review-ready service package from existing delivery and buyer evidence, not auditing a live offer or clarifying a pricing page. Its proof object is package_readiness_exception_rate from service catalog, proposal templates, CRM closed-won notes, delivery playbooks, approval workflow, with Service line owner accountable for review. Do not merge with offer audit. Package creation designs the deliverable bundle, delivery assumptions, approval path, and launch readiness; offer audit evaluates a live market-facing promise already in use.", "uniqueDataTest": "Trace each proposed package field to a source proposal, delivery playbook, buyer objection, proof asset, or approval decision. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Do not merge with offer audit. Package creation designs the deliverable bundle, delivery assumptions, approval path, and launch readiness; offer audit evaluates a live market-facing promise already in use.", "sourceRefs": [ "hubspot-value-proposition", "hubspot-stp", "pandadoc-approvals" ] }, { "id": "offer-comparison-pages", "name": "Offer Comparison Pages", "url": "/workflow-library/offer-comparison-pages", "businessFunction": "Offer clarity", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "High", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 95, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Offer comparison pages stays weak when comparison pages overstate alternatives, hide fit boundaries, or make unsupported claims about competitors, packages, and buyer tradeoffs. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making offer comparison pages measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "comparison_claim_review_rate", "baselineMetricDescription": "Share of comparison-page claims with source evidence, comparison dimension, buyer segment, fit boundary, owner approval, and review date.", "sourceSystem": "website CMS, competitive notes, sales calls, product or service catalog, proof library, legal review queue", "collectionMethod": "Audit comparison-page claims against source evidence, owner approval, correction requests, and post-publication review outcomes.", "leadingIndicators": [ "claim evidence coverage", "buyer-fit clarity", "review approval", "stale competitor claim count" ], "laggingIndicators": [ "comparison-page assisted conversations", "sales objection reuse", "claim correction requests" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "The company needs a comparison page, alternatives page, service comparison, or buyer-decision page.", "requiredEvidence": [ "target comparison or decision keyword", "offer positioning and audience", "competitor or alternative notes", "buyer questions and objections", "proof and case examples", "pricing or cost model notes", "limitations and not-a-fit criteria", "legal or brand review rules" ], "aiRole": "AI drafts comparison dimensions from buyer questions and approved offer evidence, flags unsupported competitor claims, and separates factual claims from positioning language.", "humanReviewPoint": "Marketing, legal, or offer owner reviews competitor references, proof claims, fit boundaries, pricing implications, and publication approval.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI creates unfair, inaccurate, or unsupported competitor comparisons.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Comparison dimensions, proof sources, competitor policy, or offer owner are undefined.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 10 comparison pages or 100 comparison claims across one offer family", "pilotOwner": "Product marketing lead", "pilotSuccessThreshold": "100% of competitor or proof claims have source evidence and owner approval before publication.", "workflowDistinction": "Offer comparison pages handles building comparison-page claims with source evidence, fit boundaries, and approval controls. The audit sample checks check each comparison claim for source evidence, segment, comparison dimension, fit boundary, owner review, and correction status. Keep separate from competitive positioning summary and pricing page clarity. Comparison pages are public content artifacts with claim approval requirements.", "uniqueDataTest": "Check each comparison claim for source evidence, segment, comparison dimension, fit boundary, owner review, and correction status. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from competitive positioning summary and pricing page clarity. Comparison pages are public content artifacts with claim approval requirements.", "sourceRefs": [ "hubspot-value-proposition", "hubspot-stp", "nng-pricing-visibility" ] }, { "id": "pricing-page-clarity", "name": "Pricing Page Clarity", "url": "/workflow-library/pricing-page-clarity", "businessFunction": "Offer clarity", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "High", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 95, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Pricing page clarity is weak when buyers leave pricing pages with unanswered plan-fit, fee, qualification, and next-step questions that sales later has to repair. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in pricing page clarity. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "pricing_question_resolution_rate", "baselineMetricDescription": "Share of recurring pricing-page questions mapped to a page section, FAQ, plan boundary, CTA, or sales-qualification rule with owner approval.", "sourceSystem": "website CMS, analytics events, sales call notes, chat transcripts, CRM objection fields, support tickets", "collectionMethod": "Cluster pricing questions and compare them to page content, CTA behavior, plan-fit fields, and post-page sales objections.", "leadingIndicators": [ "price basis visibility", "plan-difference clarity", "FAQ coverage", "pricing claim approval" ], "laggingIndicators": [ "pricing clarification requests", "pricing-page assisted conversion", "poor-fit booking reduction" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A pricing page is being launched, revised, tested, or causing repeated buyer questions.", "requiredEvidence": [ "current pricing page", "plan or package details", "target buyer segments", "included and excluded items", "price drivers and usage rules", "common sales questions", "discount or custom quote rules", "desired CTA and qualification path" ], "aiRole": "AI clusters pricing questions, identifies unclear plan boundaries and missing FAQ items, and drafts page-level clarification options with evidence from buyer behavior and objections.", "humanReviewPoint": "The pricing owner reviews price, discount, plan boundary, custom quote, exclusion, fee, and margin-sensitive wording before any page change.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI simplifies or changes price, fee, discount, or plan language in a way that creates sales or margin risk.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "Pricing page events, common questions, plan boundaries, or owner approval rules are not captured.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "One pricing page plus 60 pricing-page visits with related chats, form submissions, calls, or CRM objections", "pilotOwner": "Growth marketing owner", "pilotSuccessThreshold": "Resolve 85% of recurring pricing questions into approved page, FAQ, or routing decisions without adding unapproved pricing promises.", "workflowDistinction": "Pricing page clarity owns resolving buyer confusion on the pricing page, not designing the offer, changing the pricing model, or approving discounts. Its proof object is pricing_question_resolution_rate from website CMS, analytics events, sales call notes, chat transcripts, CRM objection fields, support tickets, with Growth marketing owner accountable for review. Do not merge with offer audit or service package creation. Pricing clarity is about plan, fee, and CTA comprehension on one page; the others cover broader offer design or packaging.", "uniqueDataTest": "Match pricing-page sessions, questions, chats, and sales objections to specific page sections and owner-approved fixes. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Do not merge with offer audit or service package creation. Pricing clarity is about plan, fee, and CTA comprehension on one page; the others cover broader offer design or packaging.", "sourceRefs": [ "nng-pricing-visibility", "hubspot-value-proposition", "hubspot-stp" ] }, { "id": "sales-page-offer-review", "name": "Sales Page Offer Review", "url": "/workflow-library/sales-page-offer-review", "businessFunction": "Offer clarity", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Sales page offer review stays weak when sales pages make claims, proof, pricing cues, CTAs, and scope promises that may not match offer reality or buyer evidence. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making sales page offer review measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "sales_page_offer_exception_rate", "baselineMetricDescription": "Share of sales page offer elements with reviewed buyer fit, promise, proof, pricing cue, CTA intent, scope boundary, risk exception, and owner approval before publication.", "sourceSystem": "website CMS, proof library, sales calls, CRM objections, analytics events, offer brief", "collectionMethod": "Review page sections against offer proof, buyer questions, CTA behavior, owner approval, and post-launch correction requests.", "leadingIndicators": [ "claim support coverage", "ICP fit clarity", "objection coverage", "delivery owner approval" ], "laggingIndicators": [ "poor-fit inquiry rate", "sales clarification requests", "page-assisted qualified conversion" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A sales page is being launched, revised, audited, or used for a campaign.", "requiredEvidence": [ "sales page copy and structure", "target buyer and awareness stage", "offer details and deliverables", "proof points and testimonials", "pricing or CTA path", "objections and FAQs", "risk reversal or guarantee language", "analytics and sales feedback" ], "aiRole": "AI audits sales page sections for unclear promise, weak proof, missing scope boundaries, mismatched CTA, and unsupported claims using buyer and offer evidence.", "humanReviewPoint": "Offer owner reviews claims, proof, pricing cues, guarantee language, scope boundaries, and any page change that affects buyer expectations.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI strengthens sales copy into claims the business cannot prove or deliver.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "No offer brief, proof inventory, page owner, or buyer-question source exists.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "One primary sales page plus 50 related sales conversations, chats, or objections", "pilotOwner": "Offer owner", "pilotSuccessThreshold": "90% of critical page exceptions receive owner decisions and 100% of proof, price, guarantee, or scope changes are approved before publication.", "workflowDistinction": "Sales page offer review handles reviewing sales-page offer claims and conversion path against proof and scope boundaries. The audit sample checks map each sales page claim to buyer segment, offer proof, source objection, cta intent, scope boundary, and owner decision. Keep separate from website messaging review and offer audit. Sales page review is page-specific and conversion-path focused; offer audit evaluates the whole commercial promise.", "uniqueDataTest": "Map each sales page claim to buyer segment, offer proof, source objection, CTA intent, scope boundary, and owner decision. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from website messaging review and offer audit. Sales page review is page-specific and conversion-path focused; offer audit evaluates the whole commercial promise.", "sourceRefs": [ "hubspot-value-proposition", "hubspot-stp", "nist-ai-rmf" ] }, { "id": "proposal-offer-alignment", "name": "Proposal Offer Alignment", "url": "/workflow-library/proposal-offer-alignment", "businessFunction": "Offer clarity", "department": "Sales", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "High", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 95, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Proposals drift from the offer that marketing and sales promised. Scope expands, deliverables blur, proof claims get stretched, and pricing context changes until the proposal looks impressive but no longer matches the actual package, positioning, or delivery model.", "economicLogic": "The value is margin and trust protection. Aligned proposals reduce delivery surprises, preserve offer clarity, and help leaders see when sellers are modifying the offer to win deals without approval. The pilot should expose where customization is useful versus where it creates unsupported scope or proof risk.", "baselineMetric": "proposal_offer_alignment_exception_rate", "baselineMetricDescription": "Share of proposal drafts with unresolved mismatches between approved offer, scope, pricing, proof, exclusions, buyer segment, delivery assumptions, and owner decision before the document is sent.", "sourceSystem": "Proposal tool, approved offer pages, pricing sheets, service catalog, CRM opportunity data, delivery templates", "collectionMethod": "Compare proposal sections to approved offer assets, pricing context, delivery assumptions, exclusions, segment fit, comments, and approval decisions.", "leadingIndicators": [ "scope mismatch count", "unapproved proof claim count", "pricing context exception", "delivery assumption conflict" ], "laggingIndicators": [ "proposal rework rate", "delivery handoff exception rate", "margin or scope escalation rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A proposal, SOW, or quote is drafted for a service package, custom project, or high-value buyer.", "requiredEvidence": [ "draft proposal", "approved offer or package", "discovery notes", "scope and exclusions", "timeline and milestones", "pricing logic", "acceptance criteria", "buyer requirements" ], "aiRole": "AI compares proposal draft language against approved offer, proof, pricing, scope, exclusions, and delivery assumptions, then flags mismatches and suggested fixes. It does not approve off-menu scope or rewrite the offer strategy.", "humanReviewPoint": "Sales enablement, offer owner, pricing, and delivery leadership review any mismatch involving scope, pricing, proof, exclusions, timelines, or delivery promises before send.", "evidenceBoundary": "Sources support proposal approvals, value proposition mechanics, and CLM process. Alignment value must be proven through rework, handoff, and scope exception data.", "stopRules": [ "AI normalizes off-menu scope because similar language appears in prior proposals.", "The proposal uses proof from the wrong segment or service line." ], "notReadyIf": [ "Approved offer source is not defined.", "Service exclusions are missing.", "Delivery assumptions are not documented." ], "pilotDuration": "30 days", "pilotSampleSize": "First 30 proposals tied to one core offer or package", "pilotOwner": "Sales enablement lead", "pilotSuccessThreshold": "At least 90% of proposals tied to the pilot offer have scope, proof, exclusions, pricing context, and delivery assumptions reviewed; unresolved critical mismatches are zero before send.", "workflowDistinction": "Proposal offer alignment checks whether a specific draft stays faithful to an approved offer and delivery model. It is not a general compliance review; the main concern is commercial promise, scope, proof, and packaging consistency.", "uniqueDataTest": "Compare proposals to the approved offer source, service catalog, proof asset tags, exclusions, pricing context, and delivery assumptions. Count mismatches by severity and verify owner decision before send.", "duplicateGuard": "Keep this separate from proposal compliance review. Compliance review catches policy and approval risk; offer alignment catches drift from the commercial promise and delivery capacity.", "sourceRefs": [ "pandadoc-approvals", "hubspot-value-proposition", "docusign-clm" ] }, { "id": "offer-faq-generation", "name": "Offer FAQ Generation", "url": "/workflow-library/offer-faq-generation", "businessFunction": "Offer clarity", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Offer FAQ generation stays weak when FAQ pages are written from internal assumptions rather than buyer questions, objection evidence, support transcripts, scope boundaries, and approved proof. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making offer FAQ generation measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "faq_answer_evidence_approval_rate", "baselineMetricDescription": "Share of offer FAQ answers with source question, buyer segment, approved answer, proof link, scope boundary, owner decision, and review date.", "sourceSystem": "sales call transcripts, support tickets, website chat, CRM objection notes, offer page, proof library", "collectionMethod": "Compare FAQ drafts to recurring questions, source snippets, owner approvals, published answer status, and post-publication corrections.", "leadingIndicators": [ "source question coverage", "approved answer rate", "claim evidence", "duplicate question clustering" ], "laggingIndicators": [ "repeat question reduction", "sales clarification load", "FAQ-assisted conversion or qualification" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A sales page, pricing page, proposal template, or offer page needs clearer buyer questions and answers.", "requiredEvidence": [ "sales call notes", "form questions", "proposal objections", "pricing questions", "support or onboarding questions", "scope and exclusion notes", "proof and policy references", "offer owner review rules" ], "aiRole": "AI clusters recurring buyer questions and drafts answer candidates with source snippets, scope boundaries, proof links, and confidence flags for owner review.", "humanReviewPoint": "The offer owner reviews answer accuracy, proof strength, legal or scope-sensitive wording, pricing implications, and final publication.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI answers a pricing, guarantee, or scope question with unsupported promise language.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Questions are not captured from sales, support, or chat sources, or no owner can approve offer answers.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "Top 50 recurring offer questions from calls, tickets, chats, and CRM objections", "pilotOwner": "Growth content lead", "pilotSuccessThreshold": "90% of published FAQ answers link to a source question and owner approval, with 0 pricing or scope-sensitive answers published without review.", "workflowDistinction": "Offer FAQ generation handles turning recurring buyer questions into source-backed, owner-approved FAQ answers for a specific offer. The audit sample checks map each faq answer to source question, segment, proof, scope boundary, owner decision, and published revision. Keep separate from sales page offer review and offer audit. FAQ generation produces approved answer units; review and audit workflows evaluate the broader page or offer system.", "uniqueDataTest": "Map each FAQ answer to source question, segment, proof, scope boundary, owner decision, and published revision. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from sales page offer review and offer audit. FAQ generation produces approved answer units; review and audit workflows evaluate the broader page or offer system.", "sourceRefs": [ "gong-call-intelligence", "zendesk-ticket-summaries", "hubspot-value-proposition" ] }, { "id": "deliverable-scope-clarification", "name": "Deliverable Scope Clarification", "url": "/workflow-library/deliverable-scope-clarification", "businessFunction": "Offer clarity", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Deliverable Scope Clarification is weak when offer clarity teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Deliverable Scope Clarification comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Service line owner, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "deliverable_scope_clarification_review_ready_rate", "baselineMetricDescription": "Share of deliverable scope clarification records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, CLM, proposal tool, HubSpot", "collectionMethod": "Sample deliverable scope clarification records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, CLM, proposal tool, HubSpot.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A package, proposal, SOW, or project plan includes deliverables that could be interpreted more than one way.", "requiredEvidence": [ "proposal or SOW", "deliverable names", "delivery process notes", "customer dependencies", "revision rules", "exclusions", "timeline and milestones", "acceptance criteria" ], "aiRole": "AI prepares the deliverable scope clarification record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Service line owner; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Service line owner reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances deliverable scope clarification from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Deliverable Scope Clarification does not have stable source records, owner fields, or status fields to sample.", "No accountable offer clarity owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 deliverable scope clarification records, or all records from one offer clarity segment over 45 days", "pilotOwner": "Service line owner", "pilotSuccessThreshold": "At least 90% of sampled deliverable scope clarification records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Deliverable Scope Clarification is the offer clarity control for deliverable_scope_clarification_review_ready_rate, using docusign-clm, pandadoc-approvals, hubspot-value-proposition as its source boundary and the workflow terms deliverable, scope, clarification. Its audit packet should carry deliverablescopeclarificationSourceRecord, deliverablescopeclarificationOwnerDecision, deliverablescopeclarificationExceptionQueue, deliverablescopeclarificationReviewOutcome, and deliverablescopeclarificationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Service line owner, exception status, and a safe next action for deliverable scope clarification specifically.", "uniqueDataTest": "Audit 100 deliverable scope clarification records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep deliverable scope clarification separate from adjacent offer clarity workflows by requiring deliverable_scope_clarification_review_ready_rate, the Service line owner review point, and the source boundary docusign-clm, pandadoc-approvals, hubspot-value-proposition. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "docusign-clm", "pandadoc-approvals", "hubspot-value-proposition" ] }, { "id": "positioning-audit", "name": "Positioning Audit", "url": "/workflow-library/positioning-audit", "businessFunction": "Positioning clarity", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Positioning audit is weak when homepage, sales, and deck language drift into inconsistent claims that do not match the ICP, use case, proof, or sales conversation. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in positioning audit. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "positioning_consistency_review_rate", "baselineMetricDescription": "Share of audited positioning assets with ICP, problem, alternative, proof, and differentiation fields reviewed against current buyer evidence.", "sourceSystem": "website CMS, sales deck, CRM win-loss notes, call transcripts, campaign landing pages", "collectionMethod": "Audit each asset for ICP, problem, alternative, claim, proof, and owner decision, then track unresolved conflicts.", "leadingIndicators": [ "ICP specificity", "alternative clarity", "proof coverage", "generic language count" ], "laggingIndicators": [ "message consistency", "sales story reuse", "poor-fit lead reduction" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "Messaging feels unclear, lead quality is weak, a website is being revised, or sales and marketing disagree on the offer.", "requiredEvidence": [ "homepage and offer pages", "sales-call notes", "customer interviews", "win/loss notes", "competitor or alternative notes", "proof points", "current positioning statement", "sales objections" ], "aiRole": "AI inventories positioning claims across pages and collateral, maps them to ICP and proof evidence, and highlights conflicts, vague claims, and missing buyer-language support.", "humanReviewPoint": "Marketing leadership reviews ICP boundaries, differentiation, proof strength, competitor language, and any public copy change before publication.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI rewrites strategy from a shallow pattern match and removes important category, buyer, or compliance context.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "No ICP definition, proof inventory, current asset list, or owner for positioning decisions exists.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "Homepage, main service page, sales deck, and 50 recent sales or customer conversations", "pilotOwner": "Head of marketing", "pilotSuccessThreshold": "Resolve or assign 90% of critical positioning conflicts and approve every public-facing claim change before release.", "workflowDistinction": "Positioning audit owns checking whether existing positioning assets agree with buyer evidence, not generating a new market category or summarizing competitors. Its proof object is positioning_consistency_review_rate from website CMS, sales deck, CRM win-loss notes, call transcripts, campaign landing pages, with Head of marketing accountable for review. Keep distinct from market category mapping and website messaging review. Positioning audit tests strategic consistency; category mapping researches the frame, while messaging review edits page-level clarity.", "uniqueDataTest": "Sample live pages, sales deck slides, and call excerpts, then verify every positioning claim has an ICP tag, proof link, and owner decision. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Keep distinct from market category mapping and website messaging review. Positioning audit tests strategic consistency; category mapping researches the frame, while messaging review edits page-level clarity.", "sourceRefs": [ "hubspot-stp", "hubspot-value-proposition", "hubspot-sales-automation" ] }, { "id": "icp-refinement", "name": "ICP Refinement", "url": "/workflow-library/icp-refinement", "businessFunction": "Positioning clarity", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "ICP Refinement is weak when positioning clarity teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of ICP Refinement comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Product marketing lead, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "icp_refinement_review_ready_rate", "baselineMetricDescription": "Share of icp refinement records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce", "collectionMethod": "Sample icp refinement records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, Salesforce.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "Lead quality is inconsistent, sales cycles are drifting, campaigns underperform, or the business is revising positioning.", "requiredEvidence": [ "best customer list", "poor-fit customer list", "won and lost deals", "sales cycle length", "retention or churn notes", "delivery fit notes", "buyer interviews", "firmographic and trigger data" ], "aiRole": "AI prepares the icp refinement record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Product marketing lead; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Product marketing lead reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances icp refinement from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "ICP Refinement does not have stable source records, owner fields, or status fields to sample.", "No accountable positioning clarity owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 icp refinement records, or all records from one positioning clarity segment over 45 days", "pilotOwner": "Product marketing lead", "pilotSuccessThreshold": "At least 90% of sampled icp refinement records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "ICP Refinement is the positioning clarity control for icp_refinement_review_ready_rate, using hubspot-stp, hubspot-value-proposition, salesforce-pipeline-inspection as its source boundary and the workflow terms icp, refinement. Its audit packet should carry icprefinementSourceRecord, icprefinementOwnerDecision, icprefinementExceptionQueue, icprefinementReviewOutcome, and icprefinementScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Product marketing lead, exception status, and a safe next action for icp refinement specifically.", "uniqueDataTest": "Audit 100 icp refinement records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep icp refinement separate from adjacent positioning clarity workflows by requiring icp_refinement_review_ready_rate, the Product marketing lead review point, and the source boundary hubspot-stp, hubspot-value-proposition, salesforce-pipeline-inspection. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-stp", "hubspot-value-proposition", "salesforce-pipeline-inspection" ] }, { "id": "website-messaging-review", "name": "Website Messaging Review", "url": "/workflow-library/website-messaging-review", "businessFunction": "Positioning clarity", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Website messaging review is weak when website copy can be polished while still hiding the buyer, problem, proof, next step, pricing expectation, or differentiation. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in website messaging review. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "message_clarity_issue_resolution_rate", "baselineMetricDescription": "Share of website messaging issues assigned to an owner decision for buyer clarity, problem clarity, proof support, CTA, differentiation, or pricing expectation.", "sourceSystem": "website CMS, analytics events, CRM source notes, call transcripts, chat logs, objection repository", "collectionMethod": "Audit target pages against buyer-language evidence, proof assets, CTA behavior, and sales objections, then track approved fixes.", "leadingIndicators": [ "ICP signal coverage", "proof coverage", "CTA clarity", "generic claim count" ], "laggingIndicators": [ "qualified conversion quality", "sales clarification questions", "poor-fit inquiry reduction" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A website, homepage, landing page, or offer page is being revised or sales feedback shows buyer confusion.", "requiredEvidence": [ "homepage and offer page copy", "buyer profile", "sales-call notes", "form questions", "proof points", "competitor or alternative notes", "current CTA", "analytics or sales feedback" ], "aiRole": "AI compares website claims to buyer language, objections, page behavior, and proof assets, then identifies unclear claims, missing proof, weak CTAs, and unsupported differentiators.", "humanReviewPoint": "Marketing reviews strategic message, proof claims, compliance-sensitive language, competitor framing, and any copy that changes the offer promise.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI rewrites messaging into generic claims that weaken positioning or create unsupported promises.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "No page inventory, proof library, or recent buyer-language source exists.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "Homepage plus top 5 conversion pages and 50 recent related sales or chat interactions", "pilotOwner": "Website owner", "pilotSuccessThreshold": "Assign owner decisions to 90% of critical clarity issues and publish only copy changes with approved proof or strategy rationale.", "workflowDistinction": "Website messaging review owns reviewing page-level clarity and proof support, not defining the entire market position or auditing the offer economics. Its proof object is message_clarity_issue_resolution_rate from website CMS, analytics events, CRM source notes, call transcripts, chat logs, objection repository, with Website owner accountable for review. Keep distinct from positioning audit and pricing page clarity. Website messaging review covers page clarity across the site; the others address strategy consistency or pricing-specific comprehension.", "uniqueDataTest": "For each page claim, verify ICP, source evidence, proof link, CTA intent, and owner decision before copy changes are accepted. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Keep distinct from positioning audit and pricing page clarity. Website messaging review covers page clarity across the site; the others address strategy consistency or pricing-specific comprehension.", "sourceRefs": [ "hubspot-value-proposition", "hubspot-stp", "nng-pricing-visibility" ] }, { "id": "competitive-positioning-summary", "name": "Competitive Positioning Summary", "url": "/workflow-library/competitive-positioning-summary", "businessFunction": "Positioning clarity", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "High", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 95, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Competitive positioning summary is weak when competitive notes are scattered across deals and become biased narratives instead of source-backed comparison points. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in competitive positioning summary. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "competitive_claim_source_rate", "baselineMetricDescription": "Share of competitive positioning claims with source account, competitor named, buyer context, evidence quote, owner review, and approved use decision.", "sourceSystem": "CRM opportunity notes, call transcripts, win-loss notes, sales enablement repository, competitor battlecards", "collectionMethod": "Sample competitive summary claims and verify each one against source evidence, segment context, deal outcome, and enablement owner approval.", "leadingIndicators": [ "claim source coverage", "tradeoff clarity", "currentness review", "sales acceptance" ], "laggingIndicators": [ "battlecard reuse", "competitive objection handling", "claim correction requests" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "Sales repeatedly gets competitor questions, a comparison page is planned, or positioning needs clearer alternative framing.", "requiredEvidence": [ "competitor or alternative list", "win/loss notes", "sales-call mentions", "public competitor pages", "customer proof", "objections", "pricing or packaging notes", "legal or brand review rules" ], "aiRole": "AI extracts competitor mentions, buyer comparison criteria, win-loss reasons, and source quotes into a draft summary with confidence and segment tags.", "humanReviewPoint": "Product marketing or sales enablement reviews accuracy, legal sensitivity, competitor claims, segment fit, and whether the summary can be used in sales materials.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI turns rep anecdotes into unsupported competitor claims.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "Competitor mentions, win-loss notes, or call transcripts are not captured consistently.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "100 competitive opportunity notes or calls from one segment over one quarter", "pilotOwner": "Sales enablement manager", "pilotSuccessThreshold": "90% of accepted competitive claims include source evidence and owner approval before entering enablement content.", "workflowDistinction": "Competitive positioning summary owns summarizing competitor-specific evidence for enablement review, not mapping the broader market category or auditing positioning strategy. Its proof object is competitive_claim_source_rate from CRM opportunity notes, call transcripts, win-loss notes, sales enablement repository, competitor battlecards, with Sales enablement manager accountable for review. Keep separate from market category mapping and positioning audit. Competitive summary focuses on named alternatives inside sales evidence, with enablement approval before claims can enter battlecards or customer conversations.", "uniqueDataTest": "Trace each competitor claim to account, segment, call or note source, deal outcome, and approved enablement use. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Keep separate from market category mapping and positioning audit. Competitive summary focuses on named alternatives inside sales evidence, with enablement approval before claims can enter battlecards or customer conversations.", "sourceRefs": [ "hubspot-stp", "hubspot-value-proposition", "salesforce-pipeline-inspection" ] }, { "id": "case-study-positioning-extraction", "name": "Case Study Positioning Extraction", "url": "/workflow-library/case-study-positioning-extraction", "businessFunction": "Positioning clarity", "department": "Marketing Ops", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Marketing Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 94, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Case Study Positioning Extraction is weak when positioning clarity teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Case Study Positioning Extraction comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Product marketing lead, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "case_study_positioning_extraction_review_ready_rate", "baselineMetricDescription": "Share of case study positioning extraction records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, risk review notes", "collectionMethod": "Sample case study positioning extraction records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A case study is published, approved for reuse, or being reviewed for sales and website messaging.", "requiredEvidence": [ "case study text or interview notes", "customer permission status", "before and after context", "outcome evidence", "buyer quotes", "objections and alternatives", "industry and use case", "public-use restrictions" ], "aiRole": "AI prepares the case study positioning extraction record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Product marketing lead; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Product marketing lead reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances case study positioning extraction from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Case Study Positioning Extraction does not have stable source records, owner fields, or status fields to sample.", "No accountable positioning clarity owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 case study positioning extraction records, or all records from one positioning clarity segment over 45 days", "pilotOwner": "Product marketing lead", "pilotSuccessThreshold": "At least 90% of sampled case study positioning extraction records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Case Study Positioning Extraction is the positioning clarity control for case_study_positioning_extraction_review_ready_rate, using hubspot-value-proposition, influitive-advocate-identification, nist-ai-rmf as its source boundary and the workflow terms case, study, positioning, extraction. Its audit packet should carry casestudypositioningextractionSourceRecord, casestudypositioningextractionOwnerDecision, casestudypositioningextractionExceptionQueue, casestudypositioningextractionReviewOutcome, and casestudypositioningextractionScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Product marketing lead, exception status, and a safe next action for case study positioning extraction specifically.", "uniqueDataTest": "Audit 100 case study positioning extraction records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep case study positioning extraction separate from adjacent positioning clarity workflows by requiring case_study_positioning_extraction_review_ready_rate, the Product marketing lead review point, and the source boundary hubspot-value-proposition, influitive-advocate-identification, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "hubspot-value-proposition", "influitive-advocate-identification", "nist-ai-rmf" ] }, { "id": "sales-call-positioning-insights", "name": "Sales Call Positioning Insights", "url": "/workflow-library/sales-call-positioning-insights", "businessFunction": "Positioning clarity", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Sales Call Positioning Insights is weak when positioning clarity teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Sales Call Positioning Insights comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Product marketing lead, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "sales_call_positioning_insights_review_ready_rate", "baselineMetricDescription": "Share of sales call positioning insights records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, call intelligence, HubSpot", "collectionMethod": "Sample sales call positioning insights records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, call intelligence, HubSpot.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A set of sales calls is available for review or messaging needs evidence from buyer conversations.", "requiredEvidence": [ "sales call transcripts", "deal stage and outcome", "buyer segment", "objections", "competitor mentions", "proof requests", "confusion points", "next-step notes" ], "aiRole": "AI prepares the sales call positioning insights record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Product marketing lead; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Product marketing lead reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances sales call positioning insights from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Sales Call Positioning Insights does not have stable source records, owner fields, or status fields to sample.", "No accountable positioning clarity owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 sales call positioning insights records, or all records from one positioning clarity segment over 45 days", "pilotOwner": "Product marketing lead", "pilotSuccessThreshold": "At least 90% of sampled sales call positioning insights records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Sales Call Positioning Insights is the positioning clarity control for sales_call_positioning_insights_review_ready_rate, using gong-call-intelligence, hubspot-value-proposition, hubspot-stp as its source boundary and the workflow terms sales, call, positioning, insights. Its audit packet should carry salescallpositioninginsightsSourceRecord, salescallpositioninginsightsOwnerDecision, salescallpositioninginsightsExceptionQueue, salescallpositioninginsightsReviewOutcome, and salescallpositioninginsightsScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Product marketing lead, exception status, and a safe next action for sales call positioning insights specifically.", "uniqueDataTest": "Audit 100 sales call positioning insights records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep sales call positioning insights separate from adjacent positioning clarity workflows by requiring sales_call_positioning_insights_review_ready_rate, the Product marketing lead review point, and the source boundary gong-call-intelligence, hubspot-value-proposition, hubspot-stp. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "gong-call-intelligence", "hubspot-value-proposition", "hubspot-stp" ] }, { "id": "market-category-mapping", "name": "Market Category Mapping", "url": "/workflow-library/market-category-mapping", "businessFunction": "Positioning clarity", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Market category mapping is weak when positioning work jumps from anecdotes to category claims without tracking buyer language, alternatives, segments, and proof limits. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in market category mapping. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "category_evidence_coverage_rate", "baselineMetricDescription": "Share of category maps that connect target segment, buyer language, competitor alternatives, source quote, and positioning implication in a reviewable evidence table.", "sourceSystem": "CRM notes, call intelligence transcripts, website analytics, win-loss notes, competitive research repository", "collectionMethod": "Review category-map rows for source quote, segment tag, alternative named, owner review, and downstream positioning decision.", "leadingIndicators": [ "buyer phrase coverage", "alternative set completeness", "competitor/source freshness", "positioning implication review" ], "laggingIndicators": [ "message consistency", "sales comparison clarity", "category page quality" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "The company is revising positioning, launching a new offer, entering a new market, or creating comparison content.", "requiredEvidence": [ "buyer problem language", "competitor list", "indirect alternatives", "known market categories", "sales-call mentions", "search terms", "proof and use cases", "current positioning" ], "aiRole": "AI clusters buyer phrases, competitor references, use-case labels, and category alternatives into a draft evidence map with source citations and confidence flags.", "humanReviewPoint": "The positioning owner reviews category names, competitor interpretation, segment boundaries, proof claims, and any language that will be used publicly.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI invents a category, competitor position, or buyer priority that is not present in source evidence.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "Sales notes, call transcripts, or buyer feedback are unavailable or cannot be segmented by ICP.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "100 recent sales calls, support tickets, CRM notes, and website-search terms from one target segment", "pilotOwner": "Product marketing lead", "pilotSuccessThreshold": "At least 85% of category claims in the draft map link to source evidence and all public-facing category language receives owner approval.", "workflowDistinction": "Market category mapping owns mapping the language and alternatives that define a market category, not rewriting website copy or summarizing competitive features. Its proof object is category_evidence_coverage_rate from CRM notes, call intelligence transcripts, website analytics, win-loss notes, competitive research repository, with Product marketing lead accountable for review. Keep separate from positioning audit and competitive positioning summary. Category mapping identifies the market frame and alternatives; the other workflows evaluate current positioning or summarize named competitors.", "uniqueDataTest": "Pull source quotes from calls, CRM notes, and support records, then verify that every proposed category label has multiple buyer-language examples and a segment tag. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Keep separate from positioning audit and competitive positioning summary. Category mapping identifies the market frame and alternatives; the other workflows evaluate current positioning or summarize named competitors.", "sourceRefs": [ "hubspot-stp", "hubspot-value-proposition", "gong-call-intelligence" ] }, { "id": "buyer-language-extraction", "name": "Buyer Language Extraction", "url": "/workflow-library/buyer-language-extraction", "businessFunction": "Positioning clarity", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Buyer language extraction is weak when teams quote buyers loosely and turn a few memorable phrases into broad messaging without segment, context, or source controls. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in buyer language extraction. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "buyer_phrase_source_coverage_rate", "baselineMetricDescription": "Share of extracted buyer phrases with source transcript, segment, use case, sentiment, context note, and approved messaging use decision.", "sourceSystem": "call intelligence transcripts, CRM notes, support tickets, customer interviews, website chat logs", "collectionMethod": "Sample extracted phrases and verify source link, segment tag, use case, context, owner decision, and downstream content use.", "leadingIndicators": [ "exact quote retention", "segment tagging", "theme clustering", "reuse approval" ], "laggingIndicators": [ "message library adoption", "generic copy reduction", "sales objection language reuse" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "Messaging is being revised, sales objections repeat, or a set of customer conversations is ready for review.", "requiredEvidence": [ "sales call transcripts", "form submissions", "customer interviews", "reviews or testimonials", "support tickets", "deal outcomes", "buyer segment", "public-use rules" ], "aiRole": "AI extracts recurring buyer phrases, pain words, desired outcomes, objections, and alternatives with source citations and segment tags for human messaging review.", "humanReviewPoint": "Marketing or product marketing reviews representativeness, segment fit, quote context, privacy sensitivity, and whether a phrase can influence public messaging.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI overgeneralizes a few quotes or exposes sensitive customer language.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "Conversation or feedback sources are unavailable, untagged, or not permitted for messaging research.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "200 source snippets from sales calls, support tickets, chats, and interviews in one ICP segment", "pilotOwner": "Product marketing manager", "pilotSuccessThreshold": "At least 90% of accepted phrases include source, segment, and context fields, and 0 public quotes are used without approval.", "workflowDistinction": "Buyer language extraction owns extracting source-cited buyer language for review, not producing final positioning, website copy, or case study narratives. Its proof object is buyer_phrase_source_coverage_rate from call intelligence transcripts, CRM notes, support tickets, customer interviews, website chat logs, with Product marketing manager accountable for review. Keep separate from website messaging review and case-study candidate selection. Buyer-language extraction builds the evidence bank those workflows may later use.", "uniqueDataTest": "Verify each accepted phrase against transcript, customer segment, use case, privacy status, and approved downstream use. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Keep separate from website messaging review and case-study candidate selection. Buyer-language extraction builds the evidence bank those workflows may later use.", "sourceRefs": [ "gong-call-intelligence", "hubspot-value-proposition", "zendesk-ticket-summaries" ] }, { "id": "executive-decision-briefs", "name": "Executive Decision Briefs", "url": "/workflow-library/executive-decision-briefs", "businessFunction": "Executive decision support", "department": "Customer Success", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "High", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 95, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Executive Decision Briefs is weak when executive decision support teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Executive Decision Briefs comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Strategy operations lead, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "executive_decision_briefs_review_ready_rate", "baselineMetricDescription": "Share of executive decision briefs records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, risk review notes", "collectionMethod": "Sample executive decision briefs records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A leadership decision needs structured options, evidence, risk framing, or approval.", "requiredEvidence": [ "decision question", "background context", "options", "supporting evidence", "tradeoffs", "risk notes", "stakeholder input", "deadline and decision owner" ], "aiRole": "AI prepares the executive decision briefs record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Strategy operations lead; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Strategy operations lead reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances executive decision briefs from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Executive Decision Briefs does not have stable source records, owner fields, or status fields to sample.", "No accountable executive decision support owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 executive decision briefs records, or all records from one executive decision support segment over 45 days", "pilotOwner": "Strategy operations lead", "pilotSuccessThreshold": "At least 90% of sampled executive decision briefs records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Executive Decision Briefs is the executive decision support control for executive_decision_briefs_review_ready_rate, using asana-action-log, asana-meeting-minutes, nist-ai-rmf as its source boundary and the workflow terms executive, decision, briefs. Its audit packet should carry executivedecisionbriefsSourceRecord, executivedecisionbriefsOwnerDecision, executivedecisionbriefsExceptionQueue, executivedecisionbriefsReviewOutcome, and executivedecisionbriefsScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Strategy operations lead, exception status, and a safe next action for executive decision briefs specifically.", "uniqueDataTest": "Audit 100 executive decision briefs records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep executive decision briefs separate from adjacent executive decision support workflows by requiring executive_decision_briefs_review_ready_rate, the Strategy operations lead review point, and the source boundary asana-action-log, asana-meeting-minutes, nist-ai-rmf. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "asana-action-log", "asana-meeting-minutes", "nist-ai-rmf" ] }, { "id": "vendor-evaluation", "name": "Vendor Evaluation", "url": "/workflow-library/vendor-evaluation", "businessFunction": "Executive decision support", "department": "Customer Success", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Scoring", "riskLevel": "High", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 92, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Vendor Evaluation is weak when executive decision support teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Vendor Evaluation comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Strategy operations lead, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "vendor_evaluation_review_ready_rate", "baselineMetricDescription": "Share of vendor evaluation records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, risk review notes, CLM", "collectionMethod": "Sample vendor evaluation records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, risk review notes, CLM.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A team is selecting a vendor, comparing proposals, renewing a supplier, or evaluating a tool purchase.", "requiredEvidence": [ "business requirements", "vendor proposals", "evaluation criteria", "score weights", "pricing and contract notes", "security or risk notes", "implementation requirements", "reviewer feedback" ], "aiRole": "AI prepares the vendor evaluation record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Strategy operations lead; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Strategy operations lead reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances vendor evaluation from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Vendor Evaluation does not have stable source records, owner fields, or status fields to sample.", "No accountable executive decision support owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 vendor evaluation records, or all records from one executive decision support segment over 45 days", "pilotOwner": "Strategy operations lead", "pilotSuccessThreshold": "At least 90% of sampled vendor evaluation records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Vendor Evaluation is the executive decision support control for vendor_evaluation_review_ready_rate, using nist-ai-rmf, docusign-clm, asana-action-log as its source boundary and the workflow terms vendor, evaluation. Its audit packet should carry vendorevaluationSourceRecord, vendorevaluationOwnerDecision, vendorevaluationExceptionQueue, vendorevaluationReviewOutcome, and vendorevaluationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Strategy operations lead, exception status, and a safe next action for vendor evaluation specifically.", "uniqueDataTest": "Audit 100 vendor evaluation records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep vendor evaluation separate from adjacent executive decision support workflows by requiring vendor_evaluation_review_ready_rate, the Strategy operations lead review point, and the source boundary nist-ai-rmf, docusign-clm, asana-action-log. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "nist-ai-rmf", "docusign-clm", "asana-action-log" ] }, { "id": "ai-use-case-prioritization", "name": "AI Use Case Prioritization", "url": "/workflow-library/ai-use-case-prioritization", "businessFunction": "Executive decision support", "department": "Customer Success", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Scoring", "riskLevel": "High", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 95, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "AI Use Case Prioritization is weak when executive decision support teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of AI Use Case Prioritization comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Strategy operations lead, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "ai_use_case_prioritization_review_ready_rate", "baselineMetricDescription": "Share of ai use case prioritization records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, risk review notes, project management or knowledge base", "collectionMethod": "Sample ai use case prioritization records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, risk review notes, project management or knowledge base.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Messy", "trigger": "The company has multiple AI ideas and needs to decide which workflows to implement first.", "requiredEvidence": [ "candidate use cases", "business problem", "process volume", "current cost or bottleneck", "data availability", "system access", "risk level", "business owner and metric" ], "aiRole": "AI prepares the ai use case prioritization record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Strategy operations lead; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Strategy operations lead reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances ai use case prioritization from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "AI Use Case Prioritization does not have stable source records, owner fields, or status fields to sample.", "No accountable executive decision support owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 ai use case prioritization records, or all records from one executive decision support segment over 45 days", "pilotOwner": "Strategy operations lead", "pilotSuccessThreshold": "At least 90% of sampled ai use case prioritization records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "AI Use Case Prioritization is the executive decision support control for ai_use_case_prioritization_review_ready_rate, using nist-ai-rmf, microsoft-responsible-ai-tools, atlassian-okrs as its source boundary and the workflow terms ai, use, case, prioritization. Its audit packet should carry aiusecaseprioritizationSourceRecord, aiusecaseprioritizationOwnerDecision, aiusecaseprioritizationExceptionQueue, aiusecaseprioritizationReviewOutcome, and aiusecaseprioritizationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Strategy operations lead, exception status, and a safe next action for ai use case prioritization specifically.", "uniqueDataTest": "Audit 100 ai use case prioritization records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep ai use case prioritization separate from adjacent executive decision support workflows by requiring ai_use_case_prioritization_review_ready_rate, the Strategy operations lead review point, and the source boundary nist-ai-rmf, microsoft-responsible-ai-tools, atlassian-okrs. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "nist-ai-rmf", "microsoft-responsible-ai-tools", "atlassian-okrs" ] }, { "id": "investment-memo-drafting", "name": "Investment Memo Drafting", "url": "/workflow-library/investment-memo-drafting", "businessFunction": "Executive decision support", "department": "Customer Success", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "High", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 93, "publicClaimLevel": "Directional", "buyerProblem": "Investment memo drafting is weak when approval memos mix assumptions, risks, options, and decision history without a clear evidence trail for leaders. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in investment memo drafting. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "memo_decision_readiness_rate", "baselineMetricDescription": "Share of investment memos that include decision owner, options compared, financial assumption source, risk register, open questions, and final decision log before review.", "sourceSystem": "project tracker, OKR system, finance model, meeting decision log, risk review notes", "collectionMethod": "Sample memo drafts and compare required decision fields against source links, comments, approval status, and downstream decision outcomes.", "leadingIndicators": [ "assumption evidence coverage", "downside case inclusion", "risk owner coverage", "decision condition clarity" ], "laggingIndicators": [ "post-investment review quality", "assumption miss tracking", "capital allocation learning" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "An investment, acquisition, major purchase, fund allocation, or strategic bet needs a written decision memo.", "requiredEvidence": [ "investment opportunity", "source materials", "financial model or assumptions", "market and customer evidence", "risk notes", "due diligence findings", "open questions", "decision criteria" ], "aiRole": "AI prepares a decision packet by extracting assumptions, open questions, risks, owners, prior decisions, and source links; it does not choose the investment or approve financial claims.", "humanReviewPoint": "The executive sponsor reviews assumptions, financial interpretation, strategic fit, risk framing, and any recommendation before the memo is circulated or treated as approved.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI states a preferred investment decision without accountable executive approval.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "No consistent memo template, owner field, source-link field, or approval status exists.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 20 investment or initiative memos reviewed in one planning cycle", "pilotOwner": "Strategy operations lead", "pilotSuccessThreshold": "At least 90% of sampled memos include the required evidence fields before review and fewer than 10% need rework for missing assumptions.", "workflowDistinction": "Investment memo drafting owns turning messy initiative evidence into a review-ready decision packet, not making the investment decision itself. Its proof object is memo_decision_readiness_rate from project tracker, OKR system, finance model, meeting decision log, risk review notes, with Strategy operations lead accountable for review. Do not merge this with executive KPI summaries or quarterly planning synthesis. Investment memo drafting is about one decision package and its assumptions, not broad performance reporting or planning-rollup narrative.", "uniqueDataTest": "Trace each memo section to an OKR, task, finance source, risk note, and meeting decision so unsupported claims are visible before the review meeting. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Do not merge this with executive KPI summaries or quarterly planning synthesis. Investment memo drafting is about one decision package and its assumptions, not broad performance reporting or planning-rollup narrative.", "sourceRefs": [ "asana-action-log", "nist-ai-rmf", "atlassian-okrs" ] }, { "id": "risk-review-preparation", "name": "Risk Review Preparation", "url": "/workflow-library/risk-review-preparation", "businessFunction": "Executive decision support", "department": "Customer Success", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "High", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 92, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Risk Review Preparation is weak when executive decision support teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Risk Review Preparation comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Strategy operations lead, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "risk_review_preparation_review_ready_rate", "baselineMetricDescription": "Share of risk review preparation records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, risk review notes", "collectionMethod": "Sample risk review preparation records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, risk review notes.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A decision, automation, vendor, customer issue, project, or executive review requires explicit risk assessment.", "requiredEvidence": [ "risk topic", "source evidence", "affected process", "likelihood and impact notes", "current controls", "proposed mitigation", "owner and escalation path", "decision or acceptance criteria" ], "aiRole": "AI prepares the risk review preparation record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Strategy operations lead; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Strategy operations lead reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances risk review preparation from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Risk Review Preparation does not have stable source records, owner fields, or status fields to sample.", "No accountable executive decision support owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 risk review preparation records, or all records from one executive decision support segment over 45 days", "pilotOwner": "Strategy operations lead", "pilotSuccessThreshold": "At least 90% of sampled risk review preparation records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Risk Review Preparation is the executive decision support control for risk_review_preparation_review_ready_rate, using nist-ai-rmf, microsoft-responsible-ai-tools, asana-action-log as its source boundary and the workflow terms risk, review, preparation. Its audit packet should carry riskreviewpreparationSourceRecord, riskreviewpreparationOwnerDecision, riskreviewpreparationExceptionQueue, riskreviewpreparationReviewOutcome, and riskreviewpreparationScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Strategy operations lead, exception status, and a safe next action for risk review preparation specifically.", "uniqueDataTest": "Audit 100 risk review preparation records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep risk review preparation separate from adjacent executive decision support workflows by requiring risk_review_preparation_review_ready_rate, the Strategy operations lead review point, and the source boundary nist-ai-rmf, microsoft-responsible-ai-tools, asana-action-log. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "nist-ai-rmf", "microsoft-responsible-ai-tools", "asana-action-log" ] }, { "id": "meeting-decision-logs", "name": "Meeting Decision Logs", "url": "/workflow-library/meeting-decision-logs", "businessFunction": "Executive decision support", "department": "Customer Success", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 92, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Meeting decision logs is weak when meeting notes capture discussion but lose the actual decision, owner, date, dissent, dependency, and follow-up action. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in meeting decision logs. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "meeting_decision_capture_rate", "baselineMetricDescription": "Share of meetings with explicit decision, owner, due date, source discussion, dependency, dissent or unresolved question, and follow-up task captured.", "sourceSystem": "meeting notes, calendar, project tracker, action log, OKR system, decision register", "collectionMethod": "Compare meeting summaries to action tasks, decision fields, owner acceptance, follow-up completion, and later decision reversals.", "leadingIndicators": [ "decision statement coverage", "owner assignment", "due date coverage", "task link coverage" ], "laggingIndicators": [ "decision follow-through", "reopened decision count", "orphaned action reduction" ], "implementationEffort": "Low", "dataReadiness": "Mixed", "trigger": "A leadership, project, client, or operating meeting ends and decisions need to be recorded.", "requiredEvidence": [ "meeting notes or transcript", "agenda", "attendees", "candidate decisions", "action items", "owners", "deadlines", "project or account context" ], "aiRole": "AI extracts proposed decisions, owners, due dates, unresolved questions, dependencies, and follow-up actions from notes, then flags ambiguous or unapproved decisions.", "humanReviewPoint": "The meeting owner confirms final decisions, owners, due dates, sensitive topics, dissent, and any action that changes priorities or commitments.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI treats discussion, suggestion, or brainstorming as an approved decision.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "Meetings lack notes, owners, action tracking, or a place to store decisions.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "100 recurring operating meetings or all leadership meetings over 45 days", "pilotOwner": "Operations manager", "pilotSuccessThreshold": "90% of meetings have decision and action fields confirmed within 24 hours, with unresolved decisions explicitly marked.", "workflowDistinction": "Meeting decision logs owns capturing meeting-level decisions, action owners, due dates, dissent, dependencies, unresolved questions, and follow-up task status. Its proof object is meeting_decision_capture_rate from meeting notes, calendar, project tracker, action log, OKR system, decision register, with Operations manager accountable for review. Keep separate from meeting notes to SOPs and quarterly planning synthesis. Decision logs record confirmed outcomes from individual meetings, including owner acceptance, due date, dependency, action status, and unresolved decision state.", "uniqueDataTest": "Audit notes for decision, owner, due date, dependency, unresolved question, follow-up task, owner confirmation, and later status. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Keep separate from meeting notes to SOPs and quarterly planning synthesis. Decision logs record confirmed outcomes from individual meetings, including owner acceptance, due date, dependency, action status, and unresolved decision state.", "sourceRefs": [ "asana-meeting-minutes", "asana-action-log", "atlassian-okrs" ] }, { "id": "quarterly-planning-synthesis", "name": "Quarterly Planning Synthesis", "url": "/workflow-library/quarterly-planning-synthesis", "businessFunction": "Executive decision support", "department": "Customer Success", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "Medium", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Quarterly planning synthesis is weak when planning inputs, OKRs, project updates, blockers, and decisions scatter across meetings and tools before leaders make tradeoff decisions. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in quarterly planning synthesis. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "planning_input_traceability_rate", "baselineMetricDescription": "Share of quarterly planning recommendations that link to source input, OKR, owner, dependency, risk, decision status, and unresolved question.", "sourceSystem": "OKR tool, project tracker, meeting notes, dependency log, executive decision log", "collectionMethod": "Review planning synthesis outputs for source links, owner fields, tradeoff notes, open decisions, and approved changes to priorities.", "leadingIndicators": [ "capacity constraint coverage", "priority conflict count", "owner assignment", "metric coverage" ], "laggingIndicators": [ "priority churn", "carryover reduction", "quarterly outcome review quality" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A quarterly planning cycle begins or leadership needs to align on the next quarter’s priorities.", "requiredEvidence": [ "prior quarter goals and results", "open commitments", "KPI trends", "team capacity", "proposed initiatives", "risks and constraints", "customer or market signals", "decision topics" ], "aiRole": "AI consolidates planning inputs into themes, dependency maps, unresolved questions, risk flags, and owner-specific decision briefs without making final priority calls.", "humanReviewPoint": "Leadership reviews priority tradeoffs, resource commitments, OKR changes, risk acceptance, and any decision that moves budget, people, or deadlines.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI turns incomplete planning inputs into a confident priority recommendation.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "Planning inputs do not have owners, source links, OKR mapping, or a decision log.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "One quarterly planning cycle with all department inputs and decision meetings", "pilotOwner": "Chief of staff", "pilotSuccessThreshold": "At least 90% of planning decisions link to source inputs and every priority change has an owner-approved decision record.", "workflowDistinction": "Quarterly planning synthesis owns building a quarterly tradeoff packet from OKRs, dependencies, risks, department inputs, resource constraints, and unresolved priority choices. Its proof object is planning_input_traceability_rate from OKR tool, project tracker, meeting notes, dependency log, executive decision log, with Chief of staff accountable for review. Keep separate from investment memo drafting and meeting decision logs. Quarterly planning synthesis aggregates many planning inputs into priority tradeoffs, dependency exposure, owner commitments, and unresolved leadership choices for the quarter.", "uniqueDataTest": "Check each planning recommendation against OKR source, project status, dependency, risk, owner, and final decision log. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Keep separate from investment memo drafting and meeting decision logs. Quarterly planning synthesis aggregates many planning inputs into priority tradeoffs, dependency exposure, owner commitments, and unresolved leadership choices for the quarter.", "sourceRefs": [ "atlassian-quarterly-planning", "atlassian-okrs", "asana-action-log" ] }, { "id": "automation-governance-review", "name": "Automation Governance Review", "url": "/workflow-library/automation-governance-review", "businessFunction": "Executive decision support", "department": "Customer Success", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Review", "riskLevel": "High", "ownerRole": "Customer Success", "deployabilityBand": "High Readiness", "deployabilityScore": 90, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Automation Governance Review is weak when executive decision support teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Automation Governance Review comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Strategy operations lead, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "automation_governance_review_review_ready_rate", "baselineMetricDescription": "Share of automation governance review records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, risk review notes, project management or knowledge base", "collectionMethod": "Sample automation governance review records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, risk review notes, project management or knowledge base.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "An automation, AI workflow, agent, integration, or scheduled process is proposed, changed, or reviewed.", "requiredEvidence": [ "automation purpose", "data access", "allowed actions", "system permissions", "risk tier", "human approval gates", "audit log requirements", "owner and pause plan" ], "aiRole": "AI prepares the automation governance review record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Strategy operations lead; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Strategy operations lead reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances automation governance review from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Automation Governance Review does not have stable source records, owner fields, or status fields to sample.", "No accountable executive decision support owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 automation governance review records, or all records from one executive decision support segment over 45 days", "pilotOwner": "Strategy operations lead", "pilotSuccessThreshold": "At least 90% of sampled automation governance review records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Automation Governance Review is the executive decision support control for automation_governance_review_review_ready_rate, using nist-ai-rmf, microsoft-responsible-ai-tools, atlassian-change-record as its source boundary and the workflow terms automation, governance, review. Its audit packet should carry automationgovernancereviewSourceRecord, automationgovernancereviewOwnerDecision, automationgovernancereviewExceptionQueue, automationgovernancereviewReviewOutcome, and automationgovernancereviewScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Strategy operations lead, exception status, and a safe next action for automation governance review specifically.", "uniqueDataTest": "Audit 100 automation governance review records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep automation governance review separate from adjacent executive decision support workflows by requiring automation_governance_review_review_ready_rate, the Strategy operations lead review point, and the source boundary nist-ai-rmf, microsoft-responsible-ai-tools, atlassian-change-record. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "nist-ai-rmf", "microsoft-responsible-ai-tools", "atlassian-change-record" ] }, { "id": "pipeline-prioritization-underworked-accounts", "name": "Pipeline Prioritization From Underworked Accounts", "url": "/workflow-library/pipeline-prioritization-underworked-accounts", "businessFunction": "Pipeline management", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Routing", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Good accounts go quiet because teams focus on the loudest opportunities. High-fit accounts with stale activity, buying signals, upcoming renewals, or open intent can sit underworked while reps spend time on lower-quality noise.", "economicLogic": "The value is attention recovery. The workflow should find accounts where commercial potential and low recent activity intersect, then create a reviewed action queue that managers can compare against meetings, opportunities, and reactivation outcomes.", "baselineMetric": "underworked_account_action_conversion_rate", "baselineMetricDescription": "Share of underworked high-fit accounts with reason, last activity, signal evidence, owner action, manager review, and resulting meeting, opportunity, reactivation, or no-action disposition.", "sourceSystem": "CRM accounts and opportunities, pipeline inspection, sales engagement activity, lead scoring, intent or marketing engagement data", "collectionMethod": "Compare account fit, activity gap, open signals, owner assignment, recommended action, manager review, outreach completion, and resulting commercial outcome.", "leadingIndicators": [ "underworked account queue size", "owner action completion", "manager review rate", "false-positive account rate" ], "laggingIndicators": [ "meeting creation from underworked accounts", "opportunity creation or reactivation", "pipeline added from prioritized accounts" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A sales manager, RevOps owner, or account owner reviews underworked accounts, stale territories, neglected segments, or pipeline creation gaps.", "requiredEvidence": [ "account list or segment", "CRM records and owner fields", "last activity and next-step status", "call notes and transcripts", "email thread context", "usage or product signals", "GTM updates and account notes", "approved outreach rules" ], "aiRole": "AI identifies high-fit accounts with low recent activity and relevant buying or pipeline signals, explains the reason, checks exclusions, and recommends owner action. It does not force outreach to disqualified or sensitive accounts.", "humanReviewPoint": "Sales manager reviews queue rules, high-value account recommendations, disqualification conflicts, territory issues, and recurring false positives before scaling task creation.", "evidenceBoundary": "Pipeline inspection, automation, and scoring sources support mechanics. Pipeline creation from underworked accounts must be measured from actions and outcomes.", "stopRules": [ "The queue rewards stale accounts that are stale for good reasons.", "The workflow creates busywork instead of pipeline." ], "notReadyIf": [ "Account fit scoring is absent.", "Recent sales activity is unreliable.", "Owners do not record no-action or rejection reasons." ], "pilotDuration": "45 days", "pilotSampleSize": "Top 150 high-fit accounts with no meaningful sales activity in the last 30 to 90 days", "pilotOwner": "Sales operations manager", "pilotSuccessThreshold": "At least 80% of queued accounts receive owner action or reviewed no-action reason; meetings or opportunity movement are tracked separately from activity completion.", "workflowDistinction": "Pipeline prioritization from underworked accounts is an account-attention workflow. It finds neglected commercial potential and creates an action queue. It is different from deal risk detection, which focuses on active opportunities already in motion.", "uniqueDataTest": "Build a queue of high-fit accounts with activity gaps, then verify fit, last meaningful activity, open opportunity status, disqualification reason, owner action, manager review, outreach outcome, and opportunity or meeting creation.", "duplicateGuard": "Keep this separate from priority lead routing. Lead routing assigns new inbound records; underworked-account prioritization searches existing account coverage for neglected commercial opportunities.", "sourceRefs": [ "salesforce-pipeline-inspection", "hubspot-sales-automation", "hubspot-lead-scoring" ] }, { "id": "meeting-prep-and-follow-up", "name": "Meeting Prep And Follow-Up", "url": "/workflow-library/meeting-prep-and-follow-up", "businessFunction": "Sales enablement", "department": "Sales", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Follow-Up", "riskLevel": "Medium", "ownerRole": "Sales Ops", "deployabilityBand": "High Readiness", "deployabilityScore": 96, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Meeting Prep And Follow-Up is weak when sales enablement teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Meeting Prep And Follow-Up comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales enablement manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "meeting_prep_and_follow_up_review_ready_rate", "baselineMetricDescription": "Share of meeting prep and follow-up records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, call intelligence, HubSpot, Salesforce", "collectionMethod": "Sample meeting prep and follow-up records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, call intelligence, HubSpot, Salesforce.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A customer meeting is scheduled, completed, or transcribed and the seller needs a prep brief, follow-up, recap, or CRM update.", "requiredEvidence": [ "calendar invite and meeting objective", "CRM account notes", "prior calls and transcripts", "email threads", "usage or support context", "renewal, expansion, or proposal materials", "post-meeting notes or transcript", "approved follow-up rules" ], "aiRole": "AI prepares the meeting prep and follow-up record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales enablement manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales enablement manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances meeting prep and follow-up from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Meeting Prep And Follow-Up does not have stable source records, owner fields, or status fields to sample.", "No accountable sales enablement owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 meeting prep and follow-up records, or all records from one sales enablement segment over 45 days", "pilotOwner": "Sales enablement manager", "pilotSuccessThreshold": "At least 90% of sampled meeting prep and follow-up records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Meeting Prep And Follow-Up is the sales enablement control for meeting_prep_and_follow_up_review_ready_rate, using gong-call-intelligence, hubspot-sales-automation, salesforce-lead-management as its source boundary and the workflow terms meeting, prep, and, follow, up. Its audit packet should carry meetingprepandfollowupSourceRecord, meetingprepandfollowupOwnerDecision, meetingprepandfollowupExceptionQueue, meetingprepandfollowupReviewOutcome, and meetingprepandfollowupScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales enablement manager, exception status, and a safe next action for meeting prep and follow-up specifically.", "uniqueDataTest": "Audit 100 meeting prep and follow-up records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep meeting prep and follow-up separate from adjacent sales enablement workflows by requiring meeting_prep_and_follow_up_review_ready_rate, the Sales enablement manager review point, and the source boundary gong-call-intelligence, hubspot-sales-automation, salesforce-lead-management. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "gong-call-intelligence", "hubspot-sales-automation", "salesforce-lead-management" ] }, { "id": "forecast-risk-review", "name": "Forecast Risk Review", "url": "/workflow-library/forecast-risk-review", "businessFunction": "Pipeline management", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Follow-Up", "riskLevel": "High", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 95, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Forecast risk review is weak when forecast risk hides in stage age, close-date movement, amount changes, missing activity, and rep narrative until commit calls are unreliable. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.", "economicLogic": "The value comes from reducing rework, missed review points, and unsupported decisions in forecast risk review. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.", "baselineMetric": "forecast_exception_review_coverage", "baselineMetricDescription": "Share of forecasted deals with reviewed risk flags for stage age, close-date movement, amount change, activity gap, next step, and manager decision.", "sourceSystem": "CRM opportunity fields, forecast tool, pipeline inspection view, activity history, manager notes", "collectionMethod": "Compare risk flags to forecast category, manager overrides, deal updates, close outcome, and post-period forecast miss reasons.", "leadingIndicators": [ "risk flag coverage", "buyer evidence coverage", "manager review", "category change explanation" ], "laggingIndicators": [ "forecast miss review quality", "commit slip reduction", "stale forecast cleanup" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "A weekly forecast call, month-end review, manager inspection, or owner update requires a sourced view of commit risk and deal movement.", "requiredEvidence": [ "forecast snapshot", "CRM opportunity records", "stage, amount, close date, and forecast category", "call notes and transcripts", "email and deal thread context", "support, legal, or procurement status", "usage or success signals", "owner notes and manager rules" ], "aiRole": "AI highlights forecast exceptions, summarizes evidence, compares deal movement to forecast category, and drafts manager review questions without changing commit status.", "humanReviewPoint": "Sales manager reviews forecast category, commit changes, amount movement, close date, strategic deal context, and any customer-facing next action.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI changes forecast category or labels a deal at risk without manager judgment.", "Source references are treated as proof of business outcome rather than support for workflow mechanics." ], "notReadyIf": [ "Forecast categories, activity data, close-date history, or manager review rules are not maintained.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "All forecasted opportunities in one team for one forecast period", "pilotOwner": "Sales operations leader", "pilotSuccessThreshold": "95% of high-risk forecast exceptions receive manager review before the forecast call and every commit change has a logged reason.", "workflowDistinction": "Forecast risk review owns reviewing risk inside forecasted deals, not broad pipeline review, deal risk detection, or stage progression monitoring. Its proof object is forecast_exception_review_coverage from CRM opportunity fields, forecast tool, pipeline inspection view, activity history, manager notes, with Sales operations leader accountable for review. Keep separate from pipeline review and deal risk detection. Forecast risk review is tied to forecast category, commit governance, manager override reasons, and period-specific forecast calls.", "uniqueDataTest": "Audit forecasted deals for category, stage age, date movement, amount change, activity gap, risk flag, manager decision, and final outcome. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.", "duplicateGuard": "Keep separate from pipeline review and deal risk detection. Forecast risk review is tied to forecast category, commit governance, manager override reasons, and period-specific forecast calls.", "sourceRefs": [ "salesforce-forecasting", "salesforce-pipeline-inspection", "hubspot-forecast-tool" ] }, { "id": "strategic-account-plan-refresh", "name": "Strategic Account Plan Refresh", "url": "/workflow-library/strategic-account-plan-refresh", "businessFunction": "Pipeline management", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Workflow Support", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 96, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Strategic Account Plan Refresh is weak when pipeline management teams rely on scattered notes, incomplete fields, and informal judgment instead of a source-backed operating record. The problem is not a missing AI draft; it is the missing owner, evidence, exception status, and review path that decide whether the work can safely move forward.", "economicLogic": "The value of Strategic Account Plan Refresh comes from reducing avoidable rework, misrouting, stalled decisions, and unsupported customer or revenue actions. The pilot should prove that required evidence is captured earlier, exceptions are reviewed by Sales operations manager, and the team can measure readiness without claiming validated outcome lift.", "baselineMetric": "strategic_account_plan_refresh_review_ready_rate", "baselineMetricDescription": "Share of strategic account plan refresh records with source evidence, required business fields, named owner, human review status, exception outcome, and measurable follow-up result before the workflow is expanded.", "sourceSystem": "CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, customer success platform", "collectionMethod": "Sample strategic account plan refresh records and compare source evidence, owner decision, exception status, downstream action, and outcome notes across CRM record store, workflow owner notes, pilot evidence log, exception review queue, HubSpot, customer success platform.", "leadingIndicators": [ "source evidence capture rate", "owner review completion rate", "exception queue age", "missing required field rate" ], "laggingIndicators": [ "rework rate after owner review", "misroute or correction rate", "stalled record disposition rate" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "An account plan is stale, a review is scheduled, an expansion or renewal moment is approaching, or the account team needs a current strategy pack.", "requiredEvidence": [ "CRM account and opportunity records", "recent calls and transcripts", "account email threads", "usage and product signals", "support and customer success notes", "prior account plan", "approved proof points and assets", "company news and account context" ], "aiRole": "AI prepares the strategic account plan refresh record by extracting source evidence, checking required fields, flagging missing context, drafting next-action options, and routing exceptions to Sales operations manager; it does not approve customer-visible, revenue-impacting, or policy-sensitive actions.", "humanReviewPoint": "Sales operations manager reviews low-confidence records, high-impact exceptions, customer-visible output, ownership changes, and any recommendation that changes priority, status, commitment, or business interpretation.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI advances strategic account plan refresh from incomplete source evidence or without the accountable owner reviewing exceptions.", "Workflow sources are presented as validated performance proof rather than support for mechanics and control design." ], "notReadyIf": [ "Strategic Account Plan Refresh does not have stable source records, owner fields, or status fields to sample.", "No accountable pipeline management owner can approve exceptions or customer-visible actions.", "The team cannot track timestamp, source, owner, exception, and outcome fields across the pilot sample." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "First 100 strategic account plan refresh records, or all records from one pipeline management segment over 45 days", "pilotOwner": "Sales operations manager", "pilotSuccessThreshold": "At least 90% of sampled strategic account plan refresh records include source evidence, owner decision, and exception status; 100% of high-impact or customer-visible exceptions receive human review before action.", "workflowDistinction": "Strategic Account Plan Refresh is the pipeline management control for strategic_account_plan_refresh_review_ready_rate, using pendo-customer-success, hubspot-health-score, gainsight-renewal-center as its source boundary and the workflow terms strategic, account, plan, refresh. Its audit packet should carry strategicaccountplanrefreshSourceRecord, strategicaccountplanrefreshOwnerDecision, strategicaccountplanrefreshExceptionQueue, strategicaccountplanrefreshReviewOutcome, and strategicaccountplanrefreshScaleGate fields. That operating fingerprint keeps the page from becoming a generic AI drafting task: the record must show source proof, owner acceptance by Sales operations manager, exception status, and a safe next action for strategic account plan refresh specifically.", "uniqueDataTest": "Audit 100 strategic account plan refresh records for source link, required fields, timestamp, owner, exception status, review decision, downstream action, and result. The test passes only when the workflow can separate approved action from blocked, low-confidence, or not-ready records.", "duplicateGuard": "Keep strategic account plan refresh separate from adjacent pipeline management workflows by requiring strategic_account_plan_refresh_review_ready_rate, the Sales operations manager review point, and the source boundary pendo-customer-success, hubspot-health-score, gainsight-renewal-center. Adjacent pages may share data, but this record owns the sampled decision path and exception outcome.", "sourceRefs": [ "pendo-customer-success", "hubspot-health-score", "gainsight-renewal-center" ] }, { "id": "stalled-deal-diagnosis", "name": "Stalled Deal Diagnosis", "url": "/workflow-library/stalled-deal-diagnosis", "businessFunction": "Pipeline management", "department": "Operations", "revenueLeak": "Capacity Leak", "kpi": "Capacity Recovered", "workflowType": "Workflow Support", "riskLevel": "Medium", "ownerRole": "Operations", "deployabilityBand": "High Readiness", "deployabilityScore": 97, "publicClaimLevel": "Pilot-shaped", "buyerProblem": "Stalled deal diagnosis stays weak when stalled opportunities are treated as generic follow-up problems instead of diagnosing missing stakeholder, next step, business case, objection, procurement, or activity evidence. The business problem is not missing AI output; it is missing evidence, owner review, and exception handling that determine whether the workflow can safely move forward.", "economicLogic": "The value comes from making stalled deal diagnosis measurable before automation expands it. The pilot should track whether source-backed records, review decisions, and owner actions reduce rework, misrouting, unsupported claims, or stalled work without claiming validated outcome lift.", "baselineMetric": "stalled_deal_diagnosis_completion_rate", "baselineMetricDescription": "Share of stalled opportunities with stall reason, missing evidence, stakeholder gap, next action, owner decision, and follow-up outcome.", "sourceSystem": "CRM opportunity, activity history, call transcripts, stage history, forecast notes, email engagement", "collectionMethod": "Sample stalled deals and compare diagnosis to owner action, stage movement, closed-lost reason, no-decision outcome, or recycled status.", "leadingIndicators": [ "stale deal detection", "blocker hypothesis coverage", "source evidence", "manager acceptance" ], "laggingIndicators": [ "stalled deal cleanup", "stage progression after action", "close/pause reason quality" ], "implementationEffort": "Medium", "dataReadiness": "Mixed", "trigger": "An opportunity is stale, slips close date, misses a next step, loses buyer engagement, or repeatedly receives follow-up without movement.", "requiredEvidence": [ "opportunity stage history", "closed activities and last touch", "call transcripts and meeting notes", "email threads", "internal deal threads", "security, legal, or procurement status", "stakeholder and decision-process notes", "approved escalation assets" ], "aiRole": "AI diagnoses stall patterns from stage age, activity gaps, stakeholder notes, objections, procurement status, and next-step evidence, then proposes manager review questions.", "humanReviewPoint": "Sales manager or deal owner reviews strategy, customer-facing message, forecast implications, discount or procurement issues, and any close-plan change.", "evidenceBoundary": "Source references support workflow mechanics, review controls, and risk boundaries. They are not treated as validated evidence of ADA-specific outcome improvement.", "stopRules": [ "AI recommends aggressive follow-up or forecast change without understanding buyer context.", "The source references are used as implied proof of revenue, conversion, speed, accuracy, or cost improvement." ], "notReadyIf": [ "Stage-age thresholds, activity history, close plan, or stalled-deal owner are missing.", "No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.", "Source records cannot be sampled with timestamp, owner, status, and outcome fields for pilot measurement." ], "pilotDuration": "30 to 60 days", "pilotSampleSize": "All opportunities stalled beyond stage-age threshold in one team for 45 days", "pilotOwner": "Sales manager", "pilotSuccessThreshold": "90% of stalled deals receive a reason code and owner action, with 80% dispositioned or advanced within the next review cycle.", "workflowDistinction": "Stalled deal diagnosis handles diagnosing why specific deals are stalled and assigning a reasoned recovery or disposition path. The audit sample checks audit stalled deal, stage age, activity gap, stakeholder evidence, objection, owner diagnosis, action, and next-cycle outcome. Keep separate from no-response follow-up and pipeline review. Stalled deal diagnosis finds the underlying blocker; follow-up sends messages and pipeline review covers all open deals.", "uniqueDataTest": "Audit stalled deal, stage age, activity gap, stakeholder evidence, objection, owner diagnosis, action, and next-cycle outcome. The test passes only when the sampled records include source link, timestamp, owner, review status, exception outcome, and measurable pilot result.", "duplicateGuard": "Keep separate from no-response follow-up and pipeline review. Stalled deal diagnosis finds the underlying blocker; follow-up sends messages and pipeline review covers all open deals.", "sourceRefs": [ "salesforce-pipeline-inspection", "hubspot-stage-calculated-properties", "gong-call-intelligence" ] } ], "sources": [ { "id": "hbr-online-leads", "title": "Harvard Business Review: The Short Life of Online Sales Leads", "url": "https://hbr.org/2011/03/the-short-life-of-online-sales-leads", "supports": "Online lead response speed is a recognized sales operations problem.", "limitation": "Supports lead response urgency, not ADA-specific workflow outcomes." }, { "id": "hubspot-sales-automation", "title": "HubSpot Sales Automation Guide", "url": "https://www.hubspot.com/products/sales/what-is-sales-automation", "supports": "Sales automation should start with repetitive revenue work, clean CRM data, routing, sequences, baseline metrics, and regular audit.", "limitation": "Vendor guidance and directional benchmarks, not independent proof of ADA outcomes." }, { "id": "hubspot-lead-routing", "title": "HubSpot Lead Routing Guide", "url": "https://blog.hubspot.com/sales/lead-routing", "supports": "Lead routing depends on criteria such as value, geography, use case, score, priority, availability, and customer type.", "limitation": "Supports routing design patterns, not field validation." }, { "id": "salesforce-lead-management", "title": "Salesforce Lead Management Documentation", "url": "https://help.salesforce.com/s/articleView?id=sales.leads_convert_parent.htm&language=en_US&type=5", "supports": "Lead records, statuses, owners, conversion, and source tracking are CRM operating objects that can be measured.", "limitation": "Platform documentation, not a performance benchmark." }, { "id": "google-lead-form-assets", "title": "Google Ads Help: Lead Form Assets", "url": "https://support.google.com/google-ads/answer/9423234", "supports": "Lead forms can push lead data to a CRM via webhook or API, making source and follow-up data measurable.", "limitation": "Applies to Google Ads lead forms, not all lead sources." }, { "id": "twilio-messaging-policy", "title": "Twilio Messaging Policy", "url": "https://www.twilio.com/en-us/legal/messaging-policy", "supports": "SMS workflows need consent, sender identity, opt-out handling, and prohibited-use controls.", "limitation": "Compliance policy, not sales conversion evidence." }, { "id": "nist-ai-rmf", "title": "NIST AI Risk Management Framework", "url": "https://www.nist.gov/itl/ai-risk-management-framework", "supports": "AI workflows should include risk mapping, measurement, governance, and accountable human oversight.", "limitation": "Cross-sector risk framework, not workflow-specific implementation evidence." }, { "id": "intercom-lead-qualification", "title": "Intercom Help: Generating Leads with Intercom", "url": "https://www.intercom.com/help/en/articles/1155346-generating-leads-with-intercom", "supports": "Chat-led qualification depends on custom qualification data, inbox assignment, team routing, and CRM field mapping.", "limitation": "Product documentation, not independent outcome evidence." }, { "id": "calendly-routing", "title": "Calendly Routing", "url": "https://calendly.com/scheduling/routing", "supports": "Demo and consultation routing can qualify, route, schedule, and match known leads to CRM owners.", "limitation": "Vendor product page; useful for workflow mechanics, not ADA performance claims." }, { "id": "hubspot-lead-scoring", "title": "HubSpot Knowledge Base: Understand the Lead Scoring Tool", "url": "https://knowledge.hubspot.com/scoring/understand-the-lead-scoring-tool", "supports": "Lead scoring can use action, demographic, engagement, and fit criteria that feed workflows and reporting.", "limitation": "Platform documentation; does not validate a scoring model for a given company." }, { "id": "salesforce-einstein-lead-scoring", "title": "Salesforce Help: Einstein Lead Scoring", "url": "https://help.salesforce.com/s/articleView?id=ai.einstein_sales_lead_insights.htm&language=en_US&type=5", "supports": "Predictive lead scoring should be compared against conversion patterns and score influence factors.", "limitation": "Salesforce-specific AI scoring documentation, not a general benchmark." }, { "id": "hubspot-sequences", "title": "HubSpot Knowledge Base: Create and Edit Sequences", "url": "https://knowledge.hubspot.com/sequences/create-and-edit-sequences", "supports": "Follow-up sequences need explicit unenrollment triggers such as reply or meeting booking.", "limitation": "Platform mechanics only; does not prove follow-up conversion." }, { "id": "zoom-webinar-reports", "title": "Zoom Support: Generating Webinar Reports", "url": "https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0066245", "supports": "Webinar reports can include registration, attendance, Q&A, polls, surveys, and engagement data after the webinar.", "limitation": "Applies to Zoom webinar data, not all webinar platforms." }, { "id": "gong-call-intelligence", "title": "Gong Help: Call Intelligence", "url": "https://help.gong.io/docs/the-call-intelligence-seat", "supports": "Sales call intelligence can produce call insights, action items, CRM sync, and call analytics from recorded conversations.", "limitation": "Vendor product documentation; useful for workflow mechanics, not independent performance proof." }, { "id": "salesforce-deal-desk", "title": "Salesforce Blog: What Is a Deal Desk?", "url": "https://www.salesforce.com/blog/deal-desk/", "supports": "Deal desk processes coordinate complex pricing, approvals, CRM/CPQ requests, and cross-functional review.", "limitation": "Salesforce educational content; not a benchmark for ADA outcomes." }, { "id": "pandadoc-rfp", "title": "PandaDoc RFP Software", "url": "https://www.pandadoc.com/rfp-software/", "supports": "RFP response workflows can use reusable content, templates, approval workflows, comments, tracking, and document analytics.", "limitation": "Vendor product page; use for process mechanics, not outcome claims." }, { "id": "pandadoc-approvals", "title": "PandaDoc Help: Approval Workflow", "url": "https://support.pandadoc.com/en/articles/9714799", "supports": "Document approval workflows can route drafts to designated approvers before recipient delivery.", "limitation": "Platform mechanics only." }, { "id": "pandadoc-conditional-approvals", "title": "PandaDoc Help: Conditional Approvals with Quote Builder", "url": "https://support.pandadoc.com/en/articles/9714721-conditional-approvals-with-quote-builder", "supports": "Quote approval workflows can be triggered by discount, section total, grand total, document value, and quote variables.", "limitation": "Platform-specific approval mechanics." }, { "id": "docusign-clm", "title": "Docusign CLM", "url": "https://www.docusign.com/products/clm", "supports": "Contract and SOW workflows can use templates, approved clauses, conditional review, version control, comments, and approval routing.", "limitation": "Vendor product page; not evidence of ADA workflow outcomes." }, { "id": "hubspot-data-quality", "title": "HubSpot Knowledge Base: Data Quality Tools", "url": "https://knowledge.hubspot.com/data-management/use-data-quality-tools", "supports": "CRM data quality work includes property review, duplicate/no-data/unused-property visibility, and data quality management.", "limitation": "HubSpot-specific mechanics." }, { "id": "salesforce-duplicate-management", "title": "Salesforce Help: Manage Duplicate Records", "url": "https://help.salesforce.com/articleView?id=managing_duplicates_overview.htm", "supports": "Duplicate management uses matching rules, duplicate rules, duplicate jobs, duplicate sets, and merge workflows.", "limitation": "Salesforce-specific mechanics; not a complete data governance framework." }, { "id": "hubspot-stage-calculated-properties", "title": "HubSpot Knowledge Base: Stage Calculated Properties", "url": "https://knowledge.hubspot.com/properties/stage-calculated-properties", "supports": "Stage entry, exit, current-stage time, and cumulative-stage time can be used to measure pipeline progression.", "limitation": "HubSpot-specific stage instrumentation." }, { "id": "hubspot-forecast-tool", "title": "HubSpot Knowledge Base: Set Up the Forecast Tool", "url": "https://knowledge.hubspot.com/forecast/set-up-the-forecast-tool", "supports": "Forecasting depends on forecast categories, deal stages, forecastable amount, close date, and revenue goals.", "limitation": "HubSpot-specific forecasting setup." }, { "id": "salesforce-pipeline-inspection", "title": "Salesforce Help: Managing Pipelines with Pipeline Inspection", "url": "https://help.salesforce.com/s/articleView?id=sales.pipeline_inspection_managing_pipelines_overview.htm&language=en_US&type=5", "supports": "Pipeline inspection can combine opportunity changes, deal health insights, activity counts, scores, and configurable summary metrics.", "limitation": "Salesforce-specific pipeline inspection feature." }, { "id": "salesforce-forecasting", "title": "Salesforce Help: Forecasting Concepts", "url": "https://help.salesforce.com/s/articleView?id=sf.forecasts3_overview.htm&language=en_US&type=5", "supports": "Forecasts use opportunity pipeline categories such as Pipeline, Best Case, Commit, Closed, and Most Likely.", "limitation": "Salesforce-specific forecasting model." }, { "id": "hubspot-customer-onboarding", "title": "HubSpot Customer Onboarding Checklist", "url": "https://blog.hubspot.com/service/customer-onboarding-checklist", "supports": "Customer onboarding should include kickoff, communication channels, milestones, expectations, training, support, and feedback loops.", "limitation": "Educational vendor content; use for onboarding mechanics, not outcome claims." }, { "id": "hubspot-service-hub-onboarding", "title": "HubSpot Service Hub Onboarding Plan", "url": "https://offers.hubspot.com/service-hub-onboarding-plan", "supports": "Service onboarding can include ticket imports, ticket pipelines, knowledge base setup, surveys, and support process configuration.", "limitation": "HubSpot-specific onboarding checklist." }, { "id": "atlassian-priority-levels", "title": "Atlassian Support: Jira Service Management Priority Levels", "url": "https://support.atlassian.com/jira-service-management-cloud/docs/what-are-priority-levels-in-jira-service-management/", "supports": "Request and incident priority can be calculated with impact and urgency matrices.", "limitation": "Atlassian-specific service-management mechanics." }, { "id": "atlassian-change-record", "title": "Atlassian Success Central: Process a Change Record", "url": "https://success.atlassian.com/solution-paths/itsm/manage-changes/process-a-change-record", "supports": "Change requests can be categorized as standard, normal, or emergency and routed through authorization based on risk and guardrails.", "limitation": "Atlassian implementation guidance, not delivery outcome evidence." }, { "id": "atlassian-kb-templates", "title": "Atlassian Confluence Knowledge Base Templates", "url": "https://www.atlassian.com/software/confluence/templates/collections/knowledge-base", "supports": "Knowledge bases use how-to articles, known-error articles, reports, feedback, and review loops to keep content useful.", "limitation": "Atlassian-specific knowledge-base guidance." }, { "id": "atlassian-knowledge-management", "title": "Atlassian Knowledge Management Guide", "url": "https://www.atlassian.com/software/confluence/guides/knowledge-management", "supports": "Knowledge management depends on structure, templates, spaces, ownership, and continuous improvement.", "limitation": "Vendor educational guide; use for process design, not proof of quality." }, { "id": "notion-search", "title": "Notion Help: Search in Your Workspace", "url": "https://www.notion.com/help/search", "supports": "Workspace search can query pages, connected apps, and web context, making source scope and access boundaries important.", "limitation": "Notion-specific search behavior." }, { "id": "sharepoint-metadata", "title": "Microsoft Support: Introduction to Managed Metadata in SharePoint", "url": "https://support.microsoft.com/en-us/office/introduction-to-managed-metadata-in-sharepoint-b324aebd-67ab-45a8-933d-ceedb2d909ea", "supports": "Managed metadata and term sets can classify documents and improve content organization.", "limitation": "SharePoint-specific metadata mechanics." }, { "id": "microsoft-syntex", "title": "Microsoft Learn: SharePoint Syntex Service Description", "url": "https://learn.microsoft.com/en-us/office365/servicedescriptions/sharepoint-syntex-service-description/sharepoint-syntex-service-description", "supports": "Syntex can extract metadata for content processing, automation, security, and compliance.", "limitation": "Microsoft-specific content AI mechanics." }, { "id": "iso-30401", "title": "ISO 30401:2018 Knowledge Management Systems", "url": "https://www.iso.org/standard/68683.html", "supports": "Knowledge management systems should be established, implemented, maintained, reviewed, and improved.", "limitation": "Standard overview; does not validate a specific knowledge-base workflow." }, { "id": "viva-learning-paths", "title": "Microsoft Learn: Learning Paths in Viva Learning", "url": "https://learn.microsoft.com/en-us/viva/learning/creating-learning-paths", "supports": "Learning paths are structured collections of learning activities for onboarding and skills development, with publish, edit, preview, and completion tracking.", "limitation": "Microsoft Viva-specific learning path mechanics." }, { "id": "learnupon-learning-paths", "title": "LearnUpon Support: Learning Paths", "url": "https://support.learnupon.com/hc/en-us/articles/360004041437-Learning-paths-create-a-path-add-courses-set-progression-and-publish", "supports": "Learning paths can group courses, set order, progression rules, completion requirements, and certificates for onboarding.", "limitation": "LearnUpon-specific LMS mechanics." }, { "id": "docebo-learning-plans", "title": "Docebo Help: Creating and Managing Learning Plans", "url": "https://help.docebo.com/hc/en-us/articles/360020083980-Creating-and-managing-learning-plans", "supports": "Learning plans are curated course sequences with enrollment rules, certificates, and learner journey structure.", "limitation": "Docebo-specific LMS mechanics." }, { "id": "viva-learning-progress", "title": "Microsoft Support: Track Progress in Viva Learning", "url": "https://support.microsoft.com/en-US/viva/learning/track-progress-in-viva-learning", "supports": "Learning progress and completion can be tracked automatically from source systems or manually updated where source progress is unavailable.", "limitation": "Microsoft Viva-specific completion mechanics." }, { "id": "docebo-ai-features", "title": "Docebo Help: FAQs on AI Features", "url": "https://help.docebo.com/hc/en-us/articles/360020125779-FAQs-on-Docebo-artificial-intelligence-features", "supports": "AI learning features can generate lessons, revise and translate text, create assessments, and assign skills to content.", "limitation": "Docebo-specific AI learning features; not evidence of training effectiveness." }, { "id": "zendesk-qa-scorecards", "title": "Zendesk Help: Viewing and Managing Scorecards", "url": "https://support.zendesk.com/hc/en-us/articles/8875998154906-Viewing-and-managing-scorecards", "supports": "Support QA scorecards can evaluate agent performance with categories and objective review criteria.", "limitation": "Zendesk-specific QA mechanics." }, { "id": "zendesk-qa-admin", "title": "Zendesk Help: Getting Started with Zendesk QA", "url": "https://support.zendesk.com/hc/en-us/articles/10093676975898-Getting-started-with-Zendesk-QA-Admin-guide", "supports": "Support QA can review conversations, identify coaching opportunities, and use customized scorecards.", "limitation": "Zendesk-specific support QA product documentation." }, { "id": "ga4-custom-reports", "title": "Google Analytics Help: Customize Detail Reports", "url": "https://support.google.com/analytics/answer/10445879", "supports": "GA4 reports can be customized with dimensions and metrics, making report definitions and permissions important.", "limitation": "GA4-specific reporting mechanics." }, { "id": "google-ads-attribution", "title": "Google Ads Help: Attribution Reports", "url": "https://support.google.com/google-ads/answer/1722023", "supports": "Attribution reports depend on conversion tracking and report only Google Ads paths with sufficient data.", "limitation": "Google Ads-specific attribution mechanics and scope limitations." }, { "id": "hubspot-marketing-reports", "title": "HubSpot Knowledge Base: Marketing Analytics Reports", "url": "https://knowledge.hubspot.com/reports/use-marketing-reports-in-the-marketing-analytics-suite", "supports": "Marketing reports can analyze engagement, website performance, contact insights, campaign filters, and SMS performance.", "limitation": "HubSpot-specific marketing reporting." }, { "id": "looker-data-freshness", "title": "Looker Studio: Manage Data Freshness", "url": "https://cloud.google.com/looker/docs/studio/manage-data-freshness", "supports": "Dashboards need explicit data freshness settings and refresh awareness for reliable reporting.", "limitation": "Looker Studio-specific dashboard freshness mechanics." }, { "id": "hubspot-health-score", "title": "HubSpot Knowledge Base: Create a Health Score", "url": "https://knowledge.hubspot.com/help-desk/customize-a-health-score-in-the-customer-success-workspace", "supports": "Customer health scores can use attributes and behavioral data to identify risk, opportunities, and trends.", "limitation": "HubSpot-specific customer success workspace mechanics." }, { "id": "gainsight-renewal-center", "title": "Gainsight Support: Renewal Center User Guide", "url": "https://support.gainsight.com/Gainsight_NXT/Renewal_Center/03User_Guides/Renewal_Center_User_Guide", "supports": "Renewal workflows can combine health scores, likelihood-to-renew, open renewal opportunities, and renewal forecasting.", "limitation": "Gainsight-specific renewal management mechanics." }, { "id": "gainsight-health-score", "title": "Gainsight Blog: Customer Health Scores", "url": "https://www.gainsight.com/blog/customer-health-scores/", "supports": "Customer health scores can help prioritize retention risk and growth opportunities when thoughtfully designed.", "limitation": "Vendor educational content; health scores still require company-specific validation." }, { "id": "partnerstack-leads-deals", "title": "PartnerStack Docs: Introduction to Leads and Deals", "url": "https://docs.partnerstack.com/docs/introduction", "supports": "Partner referral programs can use lead and deal objects to communicate prospect information between partners and sales teams.", "limitation": "PartnerStack-specific partner program mechanics." }, { "id": "partnerstack-implementation", "title": "PartnerStack Docs: Planning Your Implementation", "url": "https://docs.partnerstack.com/docs/plan-your-implementation", "supports": "Referral and deal registration workflows can use partner links, lead submission forms, attribution, and conflict-avoidance rules.", "limitation": "PartnerStack-specific implementation guidance; not a benchmark for referral revenue." }, { "id": "influitive-advocate-identification", "title": "Influitive Support: Identifying Advocates with AdvocateAnywhere", "url": "https://support.influitive.com/article/49410-identifying-advocates-with-advocateanywhere", "supports": "Advocate identification depends on recognizing known users and passing advocate information into the advocacy platform.", "limitation": "Influitive-specific customer advocacy mechanics." }, { "id": "trustpilot-review-invitations", "title": "Trustpilot Help: Get Reviews", "url": "https://trustpilot.zendesk.com/hc/en-us/sections/200383077-Get-reviews", "supports": "Review collection can use invitation methods and review request workflows that need customer eligibility and timing controls.", "limitation": "Trustpilot-specific review invitation mechanics; not endorsement of review platform reliability." }, { "id": "hubspot-sales-cs-handoff", "title": "HubSpot Academy: Managing Your Sales to Customer Success Handoff", "url": "https://academy.hubspot.com/lessons/sales-customer-success-handoff?library=true", "supports": "Sales and customer success teams should document handoff processes, customer context, and collaboration responsibilities.", "limitation": "HubSpot educational content; not proof of onboarding or retention outcomes." }, { "id": "zendesk-intelligent-triage", "title": "Zendesk Help: Using Intelligent Triage to Identify and Act on Ticket Escalations", "url": "https://support.zendesk.com/hc/en-us/articles/6353620565530-Using-intelligent-triage-to-identify-and-act-on-ticket-escalations", "supports": "Escalation workflows can identify tickets needing manager or specialist review using tags, fields, and known escalation indicators.", "limitation": "Zendesk-specific support triage mechanics." }, { "id": "zendesk-ticket-summaries", "title": "Zendesk Help: Turning On and Configuring AI-Generated Ticket Summaries", "url": "https://support.zendesk.com/hc/en-us/articles/8037565521946-Turning-on-and-configuring-AI-generated-ticket-summaries", "supports": "Ticket summaries can capture public comments, internal notes, main problem, expectations, actions taken, outcomes, current status, and limitations.", "limitation": "Zendesk-specific AI summary mechanics; summary accuracy still needs review." }, { "id": "productboard-overview", "title": "Productboard Support: What Is Productboard?", "url": "https://support.productboard.com/hc/en-us/articles/360058147693-What-is-Productboard", "supports": "Product teams can centralize feedback, link insights to feature ideas, prioritize work, and share roadmap context.", "limitation": "Productboard-specific product-management mechanics." }, { "id": "productboard-feature-ideas", "title": "Productboard Support: Organizing Your Feature Ideas", "url": "https://support.productboard.com/hc/en-us/articles/360056350954-Organizing-your-feature-ideas", "supports": "Feature ideas can be linked to customer insights and organized for prioritization.", "limitation": "Productboard-specific feature organization guidance." }, { "id": "pendo-customer-success", "title": "Pendo Help: Pendo for Customer Success", "url": "https://support.pendo.io/hc/en-us/articles/360031871032-Pendo-for-customer-success", "supports": "Customer success teams can use product usage and feedback to support customer follow-up and success motions.", "limitation": "Pendo-specific customer success mechanics." }, { "id": "gainsight-qbr-template", "title": "Gainsight: Crushing Your QBR Agenda and Template", "url": "https://www.gainsight.com/wpcms/wp-content/uploads/2015/07/6-Crushing-Your-QBR-Agenda-and-Template.pdf", "supports": "QBR preparation can include customer goals, value, outcomes, risks, next steps, and executive-ready structure.", "limitation": "Vendor template; not evidence that QBRs improve retention." }, { "id": "hubspot-value-proposition", "title": "HubSpot Blog: How to Write a Great Value Proposition", "url": "https://blog.hubspot.com/marketing/saas-value-propositions", "supports": "Value propositions should be clear, specific, differentiated, deliverable, and grounded in customer needs.", "limitation": "Marketing educational content; not proof of conversion lift." }, { "id": "hubspot-stp", "title": "HubSpot Blog: Segmentation, Targeting, and Positioning", "url": "https://blog.hubspot.com/marketing/segmentation-targeting-positioning", "supports": "Positioning depends on defined segments, target audience, and market position rather than a generic everyone audience.", "limitation": "Marketing educational content; not a substitute for buyer research." }, { "id": "nng-pricing-visibility", "title": "Nielsen Norman Group: Designing for Young Adults, Pricing Guidance", "url": "https://media.nngroup.com/media/reports/free/Designing_for_Young_Adults_3rd_Edition.pdf", "supports": "Pricing information should be visible at useful decision points because hidden pricing can make companies seem evasive or untrustworthy.", "limitation": "Research is not specific to B2B SaaS pricing pages; apply as a pricing clarity principle." }, { "id": "asana-action-log", "title": "Asana Template: Action Log", "url": "https://asana.com/templates/action-log", "supports": "Action logs can track decisions, owners, due dates, context, and follow-up in one place.", "limitation": "Asana-specific work-management template; not proof that action logs improve execution." }, { "id": "asana-meeting-minutes", "title": "Asana Template: Meeting Minutes", "url": "https://asana.com/templates/meeting-minutes", "supports": "Meeting minutes should capture decisions, action items with owners and due dates, discussion points, and logistics.", "limitation": "Asana-specific template guidance." }, { "id": "atlassian-quarterly-planning", "title": "Atlassian: Agile Quarterly Planning", "url": "https://www.atlassian.com/agile/agile-at-scale/long-term-agile-planning", "supports": "Quarterly planning should connect strategy, estimates, roadmap, teams, feedback, and adaptation.", "limitation": "Atlassian educational content; not a general planning-performance benchmark." }, { "id": "atlassian-okrs", "title": "Atlassian Team Playbook: Objectives and Key Results", "url": "https://www.atlassian.com/team-playbook/plays/okrs", "supports": "OKRs should define objectives, key results, measurable milestones, risks, gaps, and periodic progress review.", "limitation": "Atlassian framework guidance; not evidence of business outcome improvement." }, { "id": "microsoft-responsible-ai-tools", "title": "Microsoft Responsible AI Tools and Practices", "url": "https://www.microsoft.com/ai/responsible-ai-resources", "supports": "AI risk work should map, measure, and manage risks with impact assessment, human review, safety, oversight, and governance tools.", "limitation": "Responsible AI resource hub; does not validate a specific ADA workflow." } ] }