Quick Check — Who Are We Solving This For?

• Who is our primary contact for this evaluation (name, title, team)?
• Which groups should we keep informed during the PoV (select all that apply)? Options: SRE / On-call, Platform / Infra, Frontend Services, Backend Services, Security / Compliance, Finance / Billing, Product Management, Customer Support
• Who is the executive sponsor or evaluation sponsor we should align to? Options: VP Engineering, Head of SRE, CTO, Director of Platform, Other (please specify)
• What is your target decision date for adopting or rejecting a new observability platform? Options: Within 30 days, 30–60 days, 60–90 days, 3–6 months, No fixed date / exploratory
• In one sentence, what would 'success' from this evaluation look like for your team?
• What past PoV or vendor evaluation experience should we avoid repeating (brief example)?

If an Outage Could Speak, What Would It Say?

• Do you believe the last major outage was avoidable — and what part of that feels hardest to admit internally?
• Describe the most recent production incident that took the longest to resolve (what happened, services affected, and root cause if known).
• How long did it take on average to detect, to get to root cause, and to resolve that incident? Options: Detect: <5m / 5–15m / 15–60m / >60m, RC: <5m / 5–15m / 15–60m / >60m, Resolve: <30m / 30–120m / 2–4h / >4h
• Which tools did your on‑call team consult during that incident (select all that apply)? Options: Prometheus/Grafana, Datadog, Splunk/ELK, Jaeger/Zipkin, Homegrown dashboards, Cloud provider consoles, Other
• When you think about that incident, what feeling best describes the team's reaction (pick one and explain briefly)? Options: Frustrated, Overwhelmed, Relieved but exhausted, Confident we learned something, Angry at tooling/alerts
• How often do incidents that require cross‑tool correlation occur (e.g., metrics → traces → logs)? Options: Daily, Weekly, Monthly, Quarterly, Rarely

What Are You Secretly Worried Our Pricing Will Do?

• What would happen to your roadmap if observability cost increased faster than infrastructure growth?
• What is your current average monthly telemetry ingestion (GB/day or GB/month)? Options: <10 GB/month, 10–100 GB/month, 100–500 GB/month, 500–2000 GB/month, >2000 GB/month, Unknown / need to find out
• What's your projected telemetry growth over the next 12 months? Options: Flat, 10–25%, 25–50%, 50–100%, >100%
• What retention window do you need for logs, traces, and metrics to meet debugging and compliance needs? Options: Metrics: 7/30/90/365 days, Traces: 7/30/90/365 days, Logs: 7/30/90/365 days
• Which cost‑control guardrails would make you comfortable during evaluation (select all that apply)? Options: Hard ingestion cap, Ingestion alerts when trending high, Sampling rules provided, Columnar compression estimates, Pre‑signed cost model for 12 months, Other
• What's the maximum monthly observability spend that would still be considered acceptable for this initiative? Options: <$1k, $1k–$10k, $10k–$50k, $50k–$200k, >$200k, Not decided

What Would Five‑Minute Answers Actually Change for You?

• If engineers could trace a latency spike to the offending log in under five minutes, what immediate business outcomes would change?
• What is your current Mean Time to Root Cause (MTTR) for production incidents? Options: <15 minutes, 15–60 minutes, 1–4 hours, 4–12 hours, >12 hours, Don't track / estimate
• What MTTR target do you want the PoV to demonstrate (pick one and explain why)? Options: <5 minutes, <15 minutes, <60 minutes, 50% improvement vs current, Other (please specify)
• How do you currently measure alert noise (alerts per on‑call per week, false positive rate, etc.) and what reduction would you accept as success? Options: Alerts/on‑call/week, False positive %, Pager fatigue score (qualitative), Other
• What percentage reduction in noisy alerts would you consider a PoV success? Options: 10–20%, 20–40%, 40–70%, 70–90%, Near‑zero
• Which incident scenarios should we use to validate trace→log correlation and alert fidelity (select all that apply)? Options: High‑latency user requests, Downstream service failure, Traffic spike/Circuit breaker, Database latency/timeout, Memory/leak OOMs, Authentication/permission errors

Make the PoV a Test, Not a Demo — What's Your Bar?

• What would convince you this PoV is a rigorous test and not just a polished demo?
• What PoV duration do you prefer to validate real behavior? Options: 30 days, 45 days, 60 days, Flexible depending on coverage
• Which services or service classes must be included in the PoV (e.g., payments, auth, API gateway)? Please list and prioritize.
• Will the PoV run against production traffic, mirrored traffic, or staging traffic? Options: Production (live), Traffic mirror, Staging environment, Combination
• What are the hard acceptance criteria for the PoV (pick up to three and quantify if possible)? Options: MTTR target achieved, Alert noise reduction %, Trace→log under 5 minutes, Validated 12‑month cost model, No security/regulatory violations
• Who will be responsible day‑to‑day for instrumentation, data access, and acceptance checks during the PoV?

Who's Going to Sign the Check (and the Debrief)?

• If the PoV hits all technical metrics but you still don't proceed, who would say 'not yet' and why might they resist?
• Which stakeholders will make the final purchase decision (select all that apply)? Options: VP Engineering, Head of SRE, Procurement, Finance, Security/Compliance, CTO
• What procurement or legal requirements must we meet before a commercial agreement (e.g., SOC2, DPA, specific contract terms)? Options: SOC2 Type II, DPA / Data residency, Standard MSAs, SLAs for support, Custom security review, Other
• What is the budget approval threshold that determines whether this is a tactical vs strategic spend? Options: <$25k, $25k–$100k, $100k–$500k, >$500k, Not defined
• What timeline do you expect between a successful PoV and contract signature? Options: Immediately / within 2 weeks, 2–6 weeks, 6–12 weeks, Depends on procurement

If the PoV Stumbles, What Will the Fallback Look Like?

• What's the single reason you'd stop the PoV early — technical, political, or budgetary — and which feels most likely? Options: Technical (data quality/ingestion), Political (teams resistant), Budgetary (unexpected costs), Security/compliance concern, Other
• What known technical risks might trip the PoV (e.g., missing instrumentation, inconsistent tags, cloud permission limits)?
• What remediation steps would make you willing to continue if the PoV runs into trouble? Options: Add more instrumentation help, Temporarily cap ingestion, Narrow scope to fewer services, Provide deeper engineering support, Extend PoV duration
• Are there security, privacy, or compliance constraints we must honor during the PoV (data masking, residency, PII exclusions)? Options: PII masking required, No production data allowed, Encryption at rest and transit, In‑house review only, Other
• If the PoV succeeds, what practical next steps will you expect from us during handover (e.g., runbook migration, training, cost model handoff)? Options: Handover runbooks, Team training sessions, 12‑month cost model and projection, Support for migration plan, Implementation backlog

• Solution Experience Data & Pre‑Work Alignment
• Customer Incident Walkthrough (Customer‑Led)
• Live Solution Experience — Root‑Cause Replay
• Solution Experience Results & PoV Acceptance Planning

• Seller and customer to document the one‑sentence current state, consequence, and future state in the experience brief.
• Customer to identify data owners and provide access contacts and any security constraints.
• Capture complete incident timelines and exact troubleshooting steps used today.
• Quantify the consequence of each incident in operational or monetary terms.
• Identify instrumentation and data gaps that must be addressed prior to replay.
• Validate that the supplied samples are sufficient to run an accurate replay.
• Opening & Context
• Customer to provide any missing runbooks, screenshots, or query strings used during troubleshooting.
• Seller to map current troubleshooting sequence to the replay plan and flag any data shortfalls.
• Customer to confirm the business-impact assumptions used in consequence calculations.
• Recap Preconditions & Success Criteria
• Demonstrate trace→log→metric correlation that maps to the customer's troubleshooting steps.
• Prove time‑to‑root‑cause improvement with measured timestamps and compare to baseline.
• Show concrete alert‑noise reduction mechanisms and expected impact.
• Obtain explicit customer validation that the experience matched their operational reality.
• Seller to deliver a replay report that timestamps each step and quantifies time saved vs baseline.
• Customer to mark each replay as 'accurate', 'partially accurate', or 'not accurate' and provide notes.
• Seller to document any data or instrumentation gaps discovered during replay and propose remediation steps.
• Review Measured Outcomes vs Baseline
• Confirm whether the solution experience met the previously defined future state and record outcomes.
• Agree explicit PoV acceptance criteria and numerical success targets.
• Finalize PoV scope, ingestion/retention settings, and duration with assigned owners.
• Ensure cost expectations are aligned and any pricing guardrails are set for the PoV.
• Seller to produce a PoV plan document that includes scope, acceptance criteria, timeline, cost model, and remediation tasks.
• Customer to assign service owners and confirm resources for instrumentation and validation during the PoV.
• Both parties to schedule the PoV kickoff and governance checkpoints (weekly status + midpoint review).
• Agree and record a one‑sentence current state that the experience must address.
• Document explicit consequences (cost/time/risk) for the selected incidents.
• Finalize 2–4 incident scenarios with required metric/trace/log samples and access method.
• Define the one‑sentence future state (operational success criteria) the experience will prove.
• Establish delivery owners and deadlines for sample data and credentials.
• Customer to deliver sanitized sample metrics/traces/logs for each selected incident by the agreed date.
• Seller to provision a sandbox and confirm ingestion paths for the provided samples.
• Introductions & Objectives
• Environment & Data Check
• Cost Model Preview
• Incident Narrative #1 (Customer‑Led)
• Define One‑Sentence Current State
• Replay Incident #1 — Observability Walkthrough
• Surface Consequence Explicitly
• Address Gaps & Remediation Plan
• Incident Narrative #2 (Customer‑Led)
• Finalize PoV Acceptance Criteria & Success Signals
• Tie Every Step Back to Customer Problem
• Agree One‑Sentence Future State (Success)
• Troubleshooting Steps & Time Allocation
• Consequence Review
• PoV Scope, Duration & Responsibilities
• Prioritize Incident Scenarios & Required Data
• Customer Validation Pause
• Next Steps & Governance
• Access & Sample Delivery Plan
• Replay Incident #2 — Different Failure Mode
• Instrumentation & Data Gaps
• Pre‑work Checklist & Timeline
• Alert Noise & Deduplication Demo
• Confirm Reproduction Fidelity
• Measure & Compare
• Close with Forced Validation

• Deploy telemetry collectors (metrics, logs, traces)
• Instrument selected services with distributed tracing libraries
• Configure columnar indexing and retention policies
• Enable unified search across metrics, logs, and traces
• Activate trace-to-log auto-correlation and one-click drilldown
• Deploy adaptive alerting and noise-reduction engine
• Migrate existing dashboards and alerts into platform
• Configure ingestion quotas, cost alerts, and billing model
• Implement tiered storage and compression for cost control
• Deploy standardized tagging and instrumentation libraries
• Migrate historical telemetry into unified storage
• Conduct operator training on incident workflows and triage

Deploy telemetry collectors (metrics, logs, traces)

• Which environment(s) should collectors be deployed to for the PoV? Options: Production, Staging, QA, Development, Other
• What collector/agent technologies are currently in use or preferred? Options: Prometheus exporters, Fluentd / Fluent Bit, Vector, StatsD, OpenTelemetry Collector, Host agent, None / Not sure, Other
• What is the expected telemetry throughput from targeted hosts/services (GB/day)?
• Which deployment model do you prefer for collectors? Options: DaemonSet (Kubernetes), Sidecar, Host-level agent, Serverless integration (Lambda/Functions), Managed agent service, Other
• Are there security or network constraints for installing agents (e.g., no privileged containers, private subnets)? Options: Yes - private network only, Yes - agents cannot run privileged, Yes - FIPS / special crypto, No constraints, Other
• Do you require sampling, rate-limiting, or pre-ingest filtering at the collector? Options: Full-fidelity (no sampling), Fixed sampling rate (specify), Adaptive sampling, Filter on error/latency only, Other
• Are there compliance or PII requirements that affect which telemetry can be collected?

Instrument selected services with distributed tracing libraries

• Which languages and frameworks need tracing libraries (select all that apply)? Options: Java (Spring), Go, Python, Node.js, Ruby, .NET, Other
• Do you currently use OpenTelemetry, Jaeger, Zipkin, or vendor SDKs for tracing? Options: OpenTelemetry, Jaeger client, Zipkin client, Vendor SDK, No existing tracing, Other
• How many services or microservices do you plan to instrument for the PoV? Options: 1-5, 6-20, 21-50, 50+
• Which services are highest priority (list top 3 with brief rationale)?
• Do your services already propagate trace-context (trace-id / span-id / traceparent)? Options: Yes, across services, Partial coverage, No
• Who will own instrumentation changes on the codebase (team / role)? Options: Platform/infra team, Service/team owners, Shared responsibility, External contractor, Not decided
• Are there runtime constraints (cold starts, serverless) that affect how tracing should be implemented?

Configure columnar indexing and retention policies

• What retention windows do you require for each telemetry type? Options: Metrics: 7/30/90/Custom, Traces: 7/30/90/Custom, Logs: 7/30/90/Custom
• Do you require different index granularity for hot vs. cold data (e.g., per-minute hot, hourly rollups)? Options: Yes - need hot/cold granularity, No - uniform indexing, Undecided
• What is your acceptable query performance target for recent (hot) data (e.g., sub-second dashboards, <5s trace drilldown)?
• Estimate monthly ingested volume per data type (GB/month) for initial scope.
• Are there regulatory or audit requirements that dictate minimum retention (e.g., HIPAA, PCI, GDPR)? Options: HIPAA, PCI, GDPR, SOC2, None, Other
• Do you require automated rollups, downsampling, or pre-aggregation to reduce index size? Options: Yes - rollups, Yes - downsampling, No, Unsure
• Do you need custom retention per service/team (e.g., critical services retained longer)? Options: Yes, No, Maybe/Discuss

Enable unified search across metrics, logs, and traces

• Which search use cases are highest priority? Options: Trace ID lookup, Request ID lookup, User ID lookup, Full-text log search, Metric-to-log correlation, Other
• Do you need role-based access controls on search results (per-team visibility)? Options: Yes - RBAC required, No - open within org, Partial
• What are the typical search filters you need (service, host, region, tag keys)?
• Are there existing identifiers (request-id, trace-id, session-id) embedded in logs/metrics that the platform can use? Options: Yes - request-id and trace-id, Partial - some logs, No
• Do you require saved searches/dashboards and shared bookmarks for runbooks? Options: Yes, No
• Is full-text log search required across historical cold data or limited to hot data? Options: Across hot + cold, Hot only, Limited slices
• Are there language or character-set requirements for log search (e.g., multi-byte, non-English)?

Activate trace-to-log auto-correlation and one-click drilldown

• Is your team’s evaluation requirement for trace→log correlation under a specific SLA (e.g., under 5 minutes)? Options: Under 1 minute, Under 5 minutes, Under 10 minutes, No SLA
• Do your logs already include trace identifiers (trace-id, span-id, request-id)? Options: Yes - consistently, Partially, No
• Do you want correlation to be automatic (zero config) or require mapping rules (custom keys)? Options: Automatic best-effort, Require custom mapping rules, Prefer both options
• Which drilldown workflows are important (trace → log line, trace → metric timeseries, span → logs)? Options: Trace → Log line, Trace → Metrics, Span → Logs, Log → Trace, All of the above
• Are there specific latency-sensitive scenarios to validate (user-facing latency spikes, backend timeout cascades)?
• Do you require audit/traceability for correlation actions (who drilled down and when)? Options: Yes, No
• Are there environments (e.g., PCI, sensitive) where automatic correlation must be disabled? Options: Yes - list environments, No

Deploy adaptive alerting and noise-reduction engine

• What is your current alerting model? Options: Threshold-based, Anomaly-detection, Hybrid, Static only, Not sure
• Approximately how many active alerts are generated monthly today? Options: <100, 100-1,000, 1,000-10,000, 10,000+
• Which teams receive alerts (select all that apply)? Options: SRE/On-call, Platform/Infra, Service Owners, Dev Teams, Security, Other
• Do you want automatic alert deduplication, suppression windows, or noise reduction suggestions? Options: Deduplication, Suppression windows, Auto-tuning suggestions, Manual only, All of the above
• Do you require integration with incident management (PagerDuty, OpsGenie, ServiceNow)? Options: PagerDuty, OpsGenie, ServiceNow, Slack, Other, No
• Are there SLOs or MTTR targets that alerts must map to for escalation? Options: Yes - list SLOs/targets, No, Not defined yet
• Do you need multi-tenant alerting boundaries or per-team alert budgets? Options: Per-team budgets, Shared, Multi-tenant strict separation, No preference

Migrate existing dashboards and alerts into platform

• How many dashboards and visualizations need migration for the PoV? Options: 1-5, 6-20, 21-50, 50+
• Are dashboards tied to external runbooks or playbooks that must be preserved? Options: Yes - runbooks linked, No, Some
• What alert rules must be preserved or transformed (list key alert names and severity)?
• Do you require automated conversion tools or manual rebuild of dashboards? Options: Automated conversion preferred, Manual rebuild preferred, Hybrid
• Which visualization types are essential (heatmaps, flame graphs, timeseries, logs panels)? Options: Timeseries, Heatmaps, Flame graphs, Tables, Log panels, Other
• Do dashboards need role-based or team-specific views? Options: Yes - RBAC, No - shared, Some dashboards only
• Are there legacy dashboards that rely on vendor-specific query languages that will need translation? Options: Yes - specify vendors, No, Unsure

Configure ingestion quotas, cost alerts, and billing model

• What billing model do you prefer to evaluate during the PoV? Options: Per-GB ingested + storage, Consumption + committed tier, Subscription (flat), Other
• What is the target monthly ingestion quota for the PoV (GB/month)?
• Do you need per-team or per-service quotas and spend tracking? Options: Yes - per-team, Yes - per-service, No - org-level only
• What thresholds should trigger cost alerts (e.g., 75%, 90%, 100%)? Options: 50%, 75%, 90%, 100%, Custom
• Who is the billing and cost-ownership contact/team?
• Do you require exportable billing reports or integration with FinOps tooling? Options: CSV/CSV export, API export, FinOps tool integration, No
• Are there contractual guardrails required (hard caps, throttles) if ingestion exceeds quota? Options: Hard cap (stop ingest), Soft cap (alerts & throttles), No guardrails required, Other

Implement tiered storage and compression for cost control

• Which telemetry types should use tiered storage (select all that apply)? Options: Metrics, Traces, Logs
• What retention window should be stored in hot vs. cold tiers (e.g., hot:30d, cold:365d)?
• What recovery/RTO expectations do you have when restoring cold data to hot (minutes/hours)? Options: Sub-5 minutes, 5-30 minutes, 30-120 minutes, Hours
• Is compression mandatory for cold storage and do you have target compression ratios? Options: Yes - mandatory, Optional, No

• Install and Configure Data Collection Agents
• Auto-Instrument Application Tracing Libraries
• Centralize Log Ingestion and Parsing
• Ingest and Index High-Cardinality Metrics
• Provision Columnar Storage and Indexing
• Enable One-Click Trace-to-Log Correlation
• Build Correlated Incident Dashboards
• Configure Noise-Reducing Alerting Engine
• Apply Consumption-Based Ingestion Controls
• Set Retention, Compression, and Downsampling
• Migrate Dashboards and Runbooks
• Enable Billing Metering and Usage Reporting
• Enforce Telemetry Tagging Conventions

Install and Configure Data Collection Agents

• Which environments do you need agents installed in? Options: Kubernetes (cluster), Virtual machines/servers, Serverless (FaaS), Containers (non-K8s), Edge devices
• Approximately how many hosts/pods/functions will send telemetry during the PoV? Options: <50, 50-200, 201-1000, 1,001-5,000, 5,000+
• Do you have existing host/agent constraints (e.g., restricted egress, proxy requirements, FIPs, offline hosts)? Options: Yes, No
• Which data types should agents collect from hosts (select all that apply)? Options: System metrics (CPU/memory), Application metrics, Host logs, Container runtime metrics, Process-level traces
• Are installation windows or maintenance blackout periods that restrict agent rollout? Options: Yes, No
• Who will own agent installation and configuration (team or role)?

Auto-Instrument Application Tracing Libraries

• Which programming languages and frameworks are in-scope for auto-instrumentation? Options: Java, Go, Python, Node.js, .NET, Ruby, Other
• Do you currently use any APM/tracing libraries or custom instrumentation? Options: OpenTelemetry, Jaeger/Zipkin SDKs, Vendor APM, Custom tracing, None
• Which services (by name or tag) should be auto-instrumented during the PoV?
• Are there security or data-sensitivity restrictions on traces or span attributes (PII, tokens)? Options: Yes, No
• What is the expected transactions-per-second or request volume for instrumented services? Options: <100 TPS, 100-1k TPS, 1k-10k TPS, 10k+ TPS, Unknown
• Do you require code changes to add instrumentation, or should auto-instrumentation be zero-code? Options: Zero-code auto-instrumentation, Minor code changes allowed, Significant code changes acceptable

Centralize Log Ingestion and Parsing

• Which log sources need centralization (select all that apply)? Options: Application logs, System logs (syslog), Container stdout/stderr, Audit logs, Security/IDS logs, Third-party services
• What log formats are predominant (JSON, key=value, free text, multiline stack traces)? Options: JSON, Key=Value, Free-text / unstructured, Multiline (exceptions/stacktraces), Other
• Do you need custom parsing rules or grok-like patterns created? Options: Yes, many, Yes, a few, No
• What average log ingestion rate do you expect for the PoV (GB/day)? Options: <1 GB/day, 1-10 GB/day, 10-100 GB/day, 100 GB+/day, Unknown
• Are there retention or compliance policies for logs (e.g., 90 days, 1 year, GDPR)? Options: Yes, No
• Who owns log sources and parsing validation in your organization?

Ingest and Index High-Cardinality Metrics

• Do you have high-cardinality dimensions (e.g., user_id, request_id, tenant_id) that must be preserved? Options: Yes, many, Yes, some, No
• Which metric types are critical for the PoV (counters, gauges, histograms, summaries)? Options: Counters, Gauges, Histograms, Summaries, Custom metrics
• What is the expected metric cardinality and scrape/emit frequency (examples: 100k series @15s)?
• Are there existing metric exporters (Prometheus, StatsD, OTLP) you plan to keep? Options: Prometheus scrape, StatsD, OTLP/gRPC, Push API, None
• Do you need downsampling or rollup rules applied to high-cardinality metrics? Options: Yes, No, Unsure
• Who will verify metric correctness and labeling after ingestion?

Provision Columnar Storage and Indexing

• What retention windows are required for raw telemetry versus aggregated views? Options: 7 days, 30 days, 90 days, Custom
• Do you have compliance requirements for immutable storage or audit trails? Options: Yes, No
• Are you expecting bursty ingestion patterns (e.g., incident spikes) that require autoscaling? Options: Yes, No, Occasionally
• Which query SLAs do you require for ad-hoc analysis (e.g., sub-second, seconds)? Options: Sub-second, 1-3 seconds, 3-10 seconds, 10+ seconds
• Do you need region-specific storage (data residency) or multi-region replication? Options: Yes, No
• Who is responsible for approving storage sizing and cost trade-offs?

Enable One-Click Trace-to-Log Correlation

• Which trace/span identifiers or context fields do your services emit that should link to logs? Options: trace_id/span_id, request_id, correlation_id, custom headers, Unsure
• Do your logs already include trace or request IDs, or do they need enrichment? Options: Logs include IDs, Logs need enrichment, Partial coverage, Unsure
• What is the required max time-to-correlate during incidents (PoV acceptance)? Options: <1 minute, <5 minutes, <15 minutes, No requirement
• Are there frameworks or gateways where injection of trace IDs must be implemented (API gateway, sidecar)? Options: Yes, No
• Do you require automated enrichment of logs with trace context at ingest time? Options: Yes, No, Maybe
• Which teams will validate trace→log correlation during the PoV?

Build Correlated Incident Dashboards

• What incident scenarios should dashboards cover (latency spike, error surge, resource exhaustion)? Options: Latency spike, Error rate spike, Outage / service down, Cost/ingestion spike, Other
• Who are the primary dashboard consumers (SRE, on-call, product engineers, execs)? Options: SRE/on-call, Platform/infra team, App engineers, Product managers, Executives
• Do you have existing dashboards or runbooks to migrate/replicate? Options: Yes, many, Yes, a few, No
• Which KPIs should be visible on incident dashboards (MTTR, error rate, p95 latency, cost impact)?
• Do dashboards require role-based views or restricted access controls? Options: Yes, No
• What timeline do you expect for dashboard delivery during the PoV? Options: <1 week, 1-2 weeks, 2-4 weeks, Longer

Configure Noise-Reducing Alerting Engine

• What current alert problems do you need addressed (flapping, duplicates, false positives)? Options: Flapping, Duplicates, False positives, Missing signals, Other
• Which alerting strategies do you prefer (anomaly detection, dynamic baselines, composite alerts)? Options: Anomaly detection, Dynamic baselines, Thresholds, Composite/grouped alerts, Other
• Do you need integration with incident management tools (PagerDuty, Opsgenie, ServiceNow)? Options: PagerDuty, Opsgenie, ServiceNow, Slack, Other
• What on-call escalation policies should be supported during the PoV? Options: Simple (1 person), Tiered escalation, Team-based rotations, Custom rules
• What target alert-noise reduction do you expect for the PoV (e.g., 50% fewer noisy alerts)? Options: 25% reduction, 50% reduction, 75% reduction, No specific target
• Who will own alert tuning and validation during the PoV?

Apply Consumption-Based Ingestion Controls

• Do you need hard or soft ingestion limits configured for the PoV? Options: Hard limits (block), Soft limits (throttle/notify), Both, No limits
• Which data classes should be prioritized when throttling (e.g., metrics over logs)? Options: Metrics, Traces, Logs, Security logs, Custom
• What budget or GB/day ingestion guardrails should be applied during evaluation?
• Do you require automated alerts when ingestion approaches thresholds? Options: Yes, No
• Will you permit sampling or scrubbing of telemetry to control costs? Options: Yes, sampling, Yes, scrubbing PII, No
• Who will be notified and who approves changes when ingestion controls trigger?

Set Retention, Compression, and Downsampling

• What retention periods are required for raw telemetry, aggregated metrics, and logs? Options: 7 days, 30 days, 90 days, 1 year, Custom
• Are compression or columnar encoding preferences mandated for cost/perf trade-offs? Options: Yes, No, Unsure
• Do you need different retention policies per service or data class? Options: Yes, No
• Are there legal/compliance hold requirements that prevent downsampling of certain data? Options: Yes, No
• What downsampling strategy is acceptable for long-term storage (e.g., rollups, histograms)? Options: Rollups, Aggregated histograms, Fixed-interval downsampling, None/keep raw
• Who approves retention and downsampling decisions from a compliance/cost perspective?

• Statement of Work (SOW)
• Master Services Agreement (MSA)
• Proof-of-Value Agreement
• Consumption Pricing Agreement
• Order Form / Pricing & Billing Schedule
• Support & Migration Addendum
• Service Level Agreement (SLA)
• Data Processing Agreement (DPA)
• Security & Compliance Addendum
• Acceptance Criteria & Validation Checklist
• Change Order Process
• Termination & Exit Plan
• Renewal & Pricing Protection Agreement

• PoV Outcomes Review (Diagnosis → Proof → Validation)
• Operational Handover & Runbooks
• Shared Backlog Prioritization & Roadmap
• Cost & Commercial Alignment (Consumption Guardrails)
• 30/90‑Day Success Checkpoint Planning

• Publish finalized cost model spreadsheet and ingestion assumptions to shared repo.
• Validate that cost guardrails and retention settings align with the customer's 12‑month cost model constraints.
• Execute and validate a simulated incident to prove runbook usability.
• Deliver finalized runbooks, playbooks, SLO definitions, and the handover checklist to the customer documentation repo.
• Create onboarding tasks for remaining owners (tag libraries, instrumentation fixes) with owners and due dates.
• Enable consumption budget alerts and document procedures to escalate if thresholds are approached.
• Backlog Intake Review
• Produce a prioritized backlog with owners, estimates, and measurable acceptance criteria for each item.
• Timebox initial remediation work into a short roadmap (30/60/90 day milestones).
• Agree on a recurring cadence and owner for backlog grooming and progress updates.
• Create prioritized backlog in the shared tracker with owners, estimates, and DoD for each item.
• Schedule recurring backlog grooming cadence and invite cross-functional participants.
• Flag any high-risk dependencies requiring vendor or platform intervention and assign escalation owners.
• One-sentence Future State (Cost)
• Confirm and document a validated 12‑month cost model with scenarios and sensitivity analysis.
• Agree on concrete consumption guardrails, automated alerts, and actions when thresholds are hit.
• Resolve any outstanding commercial terms needed to move from PoV to production deployment.
• One-sentence Current State Recap
• Implement consumption alerts and configure automated guardrail actions in the customer's account.
• Capture agreed commercial items and owners for procurement/legal follow-up.
• Define Success Metrics & Targets
• Establish a clear 30/90‑day measurement plan with owners, required reports, and acceptance criteria.
• Ensure stakeholders know when and how to escalate regressions and who will own remediation actions.
• Lock in the first checkpoint date and prework so the team can collect necessary data.
• Create checkpoint calendar invites with prework readouts and data extraction tasks assigned.
• Build the set of KPI dashboards and grant access to all checkpoint attendees.
• Document escalation triggers and route them into the incident response process.
• Confirm measured PoV outcomes meet or exceed predefined acceptance criteria (MTTR, alert noise, trace→log time, cost model).
• Demonstrate traceable proof for at least two real incidents linking symptom→root cause→log line within the target time.
• Capture any unresolved gaps that require extension or remediation before handover.
• Obtain explicit customer sign-off on outcome validity or a decision to extend/iterate the PoV.
• Publish PoV outcome report (metrics, incident replays, validated cost model) and circulate to all stakeholders.
• Record customer acceptance decisions and any requested re-tests or scope extensions.
• Tag and list instrumentation or data gaps to feed into the shared backlog for prioritization.
• Future State One-sentence (Ops)
• Ensure SRE/Platform teams can operate the system day‑to‑day using provided runbooks and playbooks.
• Confirm ownership, escalation, and support contacts are documented and accepted by the customer.
• Checkpoint Cadence & Attendees
• Review Validated 12‑Month Cost Model
• Explicit Consequence Summary
• Impact & Effort Mapping
• Ownership & Escalation Map
• Priority & Timebox Decisions
• Runbooks & Playbooks Review
• Data & Reporting Requirements
• Consumption Guardrails & Alerts
• PoV Success Metrics – Dashboard Walkthrough
• Escalation Triggers & Remediation Path
• Live Incident Walkthroughs (Proof)
• Acceptance Criteria & Definition of Done
• Commercial Terms & Support Scope
• Alert Policy & Tuning Handoff
• Assign Owners & Dependencies
• Gap & Limitation Review
• Retention, Ingestion, and Cost Controls
• Decision & Signatures
• Confirm Long-term Ownership & Success Criteria
• Customer Validation & Acceptance
• Finalize Roadmap & Review Cadence
• Schedule First Checkpoint & Prework