Where your infrastructure actually lives

• How many datacenters, colocation sites, and cloud regions make up your production footprint today? Options: 1, 2, 3, 4+, Unsure
• List the primary compute, storage, and network platforms you operate, grouped by on-prem and cloud
• Which core business applications or services would cause measurable customer impact if they lost visibility for more than one hour?
• Who on your team is the primary decision maker for infrastructure availability, and who is the day-to-day contact for operations?
• Walk me through a typical maintenance cycle for a critical system, from scheduling to validation
• What is your target uptime for these services expressed as an SLA percentage, and which services have tiered targets? Options: 99.9%, 99.95%, 99.99%, Varies by service, No formal SLA

The outage trail, who notices and how fast

• If you lost overnight monitoring, how long would it take before customers noticed and executives demanded action? Options: <30 minutes, 30–120 minutes, 2–6 hours, 6+ hours, Already noticed by customers
• When was the last production outage that was not detected until morning, what systems were affected, and what was the customer impact in hours or dollars?
• How many high-severity incidents has your environment experienced in the last 12 months, and what was the median time to detection? Options: 0–2, 3–6, 7–12, 13+
• Who currently receives the first alert for infrastructure incidents, and how are escalation paths structured after that?
• What downstream processes break when monitoring gaps occur, for example support ticket volume, order processing, or compliance reporting?
• What single detection failure in your stack would force an immediate change in vendor or approach?

Where visibility is weakest and why that matters to the business

• Where do you have near-zero visibility today, and what would a silent failure there cost you this quarter?
• Which legacy systems or custom appliances resist agent installation or API integration? Options: Legacy OS without agent support, Proprietary appliances, Unsupported database versions, Custom hardware, None of the above
• Describe the telemetry you currently collect for network, compute, and storage, and which of those are incomplete or inconsistent
• How often do configuration changes occur outside scheduled change windows, and how do those changes affect monitoring accuracy? Options: Daily, Weekly, Monthly, Rarely, Unsure
• Are synthetic checks or transaction traces in place for your most customer-visible flows, and if so, where are they missing? Options: Yes, broad coverage, Partial coverage, Planned but not deployed, No synthetic checks
• Given visibility into a core datastore disappeared for 48 hours, what contractual or regulatory consequences would your organization face?

Automation, runbooks, and who actually responds

• When an automated playbook runs, what proportion of actions resolve the issue without human intervention, and where do automations fail most often? Options: >80%, 50–80%, 25–50%, <25%, Not measured
• Tell me the named roles responsible for on-call rotations, and describe the documented handover practice
• Count the distinct escalation tiers between first alert and executive notification, and specify each tier's maximum allowed response time
• Do you have runbooks tied to each alert, and when were they last validated under production load? Options: Yes, tested in last 30 days, Yes, tested in last 6 months, Partial runbooks, No runbooks
• Identify logs, metrics, or traces that are not centrally retained for at least 30 days, and who controls access to them
• Assuming a vendor proves detection within 30 minutes for all tier-1 services, what internal barrier would still prevent you from switching?

Constraints and transition risks that could stop the project

• Name the single prerequisite that, if absent, would force you to cancel a 30-day monitoring pilot
• List the critical integration endpoints that must be opened for monitoring and automation, and who owns each endpoint inside your organization
• Describe whether legacy systems expose stable APIs or require agent-based collection, and name the teams that control credentials and access
• Specify the number of full time equivalents on your side who can be allocated to a proof of concept and the subsequent transition activities Options: 0, 1–2, 3–5, 6–10, 10+
• Are there regulatory, contractual, or board-level approvals that could gate timeline before monitoring data can leave your site? Options: Yes, prevents off-site transfer, Yes, requires specific approvals, No known restrictions, Unsure
• Would denying access to the on-prem hypervisor management interface prevent the pilot from validating alert quality for your tier-1 services? Options: Yes, blocks pilot, No, alternative data available, Depends on the service, Unsure

The other options on your table

• Name the decisive advantage your incumbent claims that might make you stick with them instead of switching
• Tell me about any internal proposals to solve monitoring without a vendor, and who is sponsoring those proposals
• Select the types of external solutions you are evaluating Options: Incumbent managed service, New managed service vendor, Monitoring-only SaaS with in-house ops, Cloud-provider managed ops, Short-term consultant engagement, Other
• What conditions would need to be true about your current approach for you to stay with it for the next 12 months?
• Assuming the pilot demonstrates 45-minute earlier detection and a 70 percent reduction in manual intervention errors, what internal approvals would be required to sign within 30 days?

Can we run the pilot and scale it

• Point to the single operational gap in your environment that would block a successful pilot this month
• Identify the authentication and credential stores that must be integrated, and indicate whether they support scoped service accounts Options: Active Directory or LDAP, Cloud IAM, Vault or secrets manager, Custom credential store, Other
• Provide your maintenance window schedule and how far in advance those windows are published
• Provide the names and roles of approvers for cross-team access to sensitive logs and the person who signs data-sharing authorization
• Are there regulatory or contractual obligations that prevent off-site log storage or cross-border transfer of monitoring data? Options: Prevents off-site storage, Allows with approval, No restriction, Unsure
• Given central collection of metrics is prohibited for certain systems, can you identify an alternative measurable way to validate alert quality?

How we will know the pilot succeeded and next steps

• What single SLA metric and threshold would make the pilot a clear win for procurement and the CIO, triggering contract review?
• Select the acceptance tests that must pass by day 30 Options: False positive rate < 15% for tier-1 alerts, Median detection to acknowledge < 20 minutes, Automation resolves >= 60% of agreed playbooks, Dashboards reflect 100% of agreed assets, Data retention >= 30 days, Other
• Walk me through the sign-off process and typical decision timeline for each stakeholder who must approve moving to phased deployment
• Given the pilot shows agreed detection and automation improvements, what internal procurement steps remain and how long do they typically take? Options: Purchase order only, 1–2 weeks, Legal and SOW, 3–6 weeks, Board-level approval required, 6+ weeks, Unsure
• Point to the person or committee that can approve an immediate phased purchase if the pilot meets criteria, and confirm whether they can commit within seven days

• Solution Experience Session

• You confirm the demonstrated detection and automation would have detected and remediated the recent undetected outage scenario before user impact.
• Confirm the current state and its cost
• Deliver a tailored automation playbook sample for one nominated critical system within five business days.
• Map critical assets and a recent outage scenario
• You confirm the proposed runbook split and responsibilities remove the single-threaded risk during handover.
• Provide a proposed 30-day POC scope with explicit acceptance criteria and timeline.
• Provide the list of critical assets, recent incident logs for the last three outages, and an operations lead contact.
• You agree on POC success criteria, required assets, and timeline so the 30-day evaluation can begin.
• Prove detection and alerting on your scenario
• Confirm available maintenance windows and access details for the nominated assets.
• Prove automation playbook behavior and fail-safes
• Validate hybrid runbook coverage and responsibilities
• Show dashboard transparency and SLA evidence
• Agree POC scope, success criteria, and timeline
• Forced validation, confirm this meets your needs

• Solution Experience Session
• Solution Experience Deck
• Solution Brief

• meeting
• slides
• document

• 24/7 NOC Monitoring and Alerting
• Incident Triage and Response
• Automated Remediation Playbook Execution
• Custom Automation Playbook Development
• Patch Management and OS Updates
• Server and VM Hardening Operations
• Storage Monitoring and Capacity Management
• Network Monitoring and Configuration Management
• Public Cloud Infrastructure Operations
• Hybrid Monitoring Integration (On‑prem + Cloud)
• Infrastructure Security Monitoring and Remediation
• SLA Dashboards and Operational Reporting
• Parallel Operations and Managed Handover Support

24/7 NOC Monitoring and Alerting

• Provide the definitive asset list (hostnames or IP ranges) you want covered by 24/7 monitoring.
• Which monitoring data sources should be collected for each asset (select all that apply)? Options: Agent metrics (CPU/memory/disk), SNMP interface counters, Syslog events, Cloud API metrics, Synthetic/HTTP checks, Other
• How many unique monitoring endpoints (hosts, VMs, network devices, storage arrays) are in scope? Options: Less than 100, 100-500, 501-2,000, More than 2,000
• Which alert severity mappings should we use to route to the NOC (e.g., Critical = page, Major = email)? Options: Standard: Critical/Major/Minor/Info, Custom mapping (provide details in free text)
• Do you require collection of performance counters from hypervisor management endpoints or cluster managers (for example for VM density and host health)? Options: Yes, No
• Which maintenance windows and blackout schedules must the NOC respect for maintenance suppression?
• What acceptance criteria will validate monitoring coverage for the agreed asset list (for example: agent installed on 95% of hosts, SNMP traps received from all network devices)?

Incident Triage and Response

• How should incidents be classified by escalation tier and response SLA (provide minutes for Pager response and initial investigation per tier)?
• Who on your side must be notified for P1 incidents and who is the on-call escalation contact (provide roles and contact methods)?
• Which incident evidence artifacts must be collected and attached to each ticket (for example: console logs, packet captures, recent configuration diff)? Options: Console logs, Syslog snapshot, Recent config diff, Packet capture, Performance graphs, Other
• Do you require runbook-driven incident commander handoffs during multi-shift incidents? Options: Yes, No
• When an incident is resolved, what post-incident deliverables do you require (for example: timeline, root cause analysis, remediation steps)? Options: Timeline and RCA, Remediation checklist, Configuration change record, No post-incident deliverable required
• Specify retention period for incident logs and evidence the NOC will store for compliance or audit purposes (in days). Options: 30, 90, 365, Custom

Automated Remediation Playbook Execution

• Which automated actions are permitted on production hosts without prior human approval (for example: service restart, instance reboot, DNS cache flush)? Options: Service restart, Instance reboot, Configuration rollback, No automated actions without approval, Other
• List the critical services or process names for which automatic remediation is allowed and any services explicitly excluded.
• What safety constraints must be enforced in playbooks (for example: rate limits, max concurrent reboots, maintenance window only)? Options: Rate limits, Max concurrent actions, Maintenance window only, Require change ticket ID, Other
• Which monitoring signals will trigger automated playbooks (for example: sustained CPU > 90% for 10 minutes, disk latency > 50ms)?
• Do you require simulated dry-run testing of playbooks against non-production assets before enabling in production? Options: Yes, No
• Who will own approval of new automated playbooks in your change control process (role or team)?

Custom Automation Playbook Development

• Describe the custom automation tasks you need developed (for example: storage LUN expansion script, database failover steps).
• Which scripting runtimes and access methods can we use for custom playbooks (for example: SSH with key, PowerShell Remoting, API token)? Options: SSH key access, PowerShell Remoting, API token, Agent-executed scripts, Other
• What change-approval artifact must accompany a custom playbook deployment (for example: code review, signed runbook, test report)? Options: Code review, Signed runbook, Test report, Automated unit tests, Other
• How many custom playbooks do you expect to deliver in the initial phase and what are target delivery milestones?
• Do custom playbooks require integration with your ticketing system for action tracking and audit linking? Options: Yes, No
• Which environments must custom playbooks be tested against prior to production (for example: staging cluster, QA VMs)? Options: Staging, QA, Canary subset of production, Direct production test

Patch Management and OS Updates

• Which operating systems and versions are in scope for patch management (list OS family and major versions)?
• What patch maintenance windows are acceptable for each environment (provide day/time ranges per environment)?
• Do you require pre-patch testing on a representative VM image and a rollback plan per host class? Options: Yes, No
• Which approval workflow must be followed before deploying security patches (for example: CAB approval, emergency patch approval process)? Options: Standard CAB, Emergency CAB, Automated approval for security fixes, Other
• Specify patch compliance targets you require (for example: 95% of endpoints patched within 7 days of release). Options: 95% in 7 days, 90% in 14 days, Custom
• Which telemetry must be reported after patch runs (for example: percent success, failed hosts list, reboot counts)? Options: Percent success, Failed hosts list, Reboot counts, Patch duration times, Other

Server and VM Hardening Operations

• Which hardening standard or checklist must be applied to servers and VMs (for example: CIS benchmark, internal baseline document)? Options: CIS benchmark, Internal baseline document, Custom checklist provided by you
• How many golden images or VM templates require hardening and ongoing drift detection? Options: None, 1-5, 6-20, 21+
• Do you require enforcement mechanisms (configuration management tools, periodic scans) to detect and remediate drift from the hardened baseline? Options: Yes, No
• Which privileged access controls and sudo/root access restrictions must we enforce and monitor?
• What reporting cadence do you want for hardening status and noncompliant hosts (for example: weekly digest, monthly executive report)? Options: Weekly, Bi-weekly, Monthly, On-demand
• Specify any OS-level modules or kernel parameters you require set as part of hardening (provide config file or parameter names).

Storage Monitoring and Capacity Management

• List the storage systems and their management endpoints to be monitored (for example: SAN array management IPs, NAS export names, cloud storage buckets).
• Which capacity thresholds should trigger alerts for volumes or LUNs (for example: 80% used, 90% used)? Options: 70%, 80%, 90%, Custom
• Do you require automated capacity forecasting (for example: 30-, 60-, 90-day growth projections) and at what cadence? Options: Yes - weekly, Yes - monthly, No
• Which snapshot, replication, or backup job failures must generate immediate P1 alerts?
• What acceptance threshold will validate storage monitoring accuracy (for example: all LUNs reporting usable capacity and recent I/O metrics)?
• Who should be notified for capacity planning recommendations and what format do you prefer for capacity reports (CSV, PDF, dashboard link)? Options: CSV, PDF, Dashboard link, Email summary

Network Monitoring and Configuration Management

• Provide the list of network devices and management IPs to be monitored and backed up for config management.
• Which telemetry should be collected per device (for example: interface errors, BGP session state, CPU/temperature)? Options: Interface counters, BGP/OSPF session state, CPU/temperature, Config change events, Other
• Which SNMP version and community or credentials will be used for device polling (for example: SNMPv2c community string or SNMPv3 credentials)? Options: SNMPv2c, SNMPv3, API only, Syslog-only
• What frequency of configuration backups do you require for network devices (for example: daily, on-change)? Options: Daily, On-change, Weekly, Other
• Do you require automated detection and alerting for configuration drift versus the last known good backup? Options: Yes, No
• Which interfaces or VLANs are business-critical and must have sub-minute monitoring for packet loss or latency?

Public Cloud Infrastructure Operations

• Provide the cloud account IDs, project IDs, or subscription identifiers that must be operated and monitored.
• Which cloud-level constructs require monitoring and control (for example: VPC/subnet CIDRs, autoscaling groups, managed databases)? Options: VPC/subnet, Autoscaling groups, Managed databases, Load balancers, Other
• Do you require tagging and cost center attribution enforcement for cloud resources as part of operations? Options: Yes, No
• Which IAM roles or service account access methods will we use for read and remediation actions in your cloud accounts? Options: Role-based IAM, Service account keys, Temporary tokens via STS, Other
• How should cloud autoscaling events be treated for alerting to avoid noise (for example: suppress alerts during scale events)? Options: Suppress during scale events, Alert on scale events, Custom handling
• Specify required cloud operation SLAs for resource creation, incident response, and remediation (for example: create VPC within 4 hours, P1 respond within 15 minutes).

Hybrid Monitoring Integration (On‑prem + Cloud)

• Which connectivity methods exist between on-prem and cloud (for example: VPN, direct link, private interconnect) and what endpoints/IP ranges should be monitored for the link?
• Which metrics or logs must be correlated across on-prem and cloud assets (for example: end-to-end transaction latency, cross-site replication status)?
• Do you require a single pane-of-glass for alerting and dashboards across both environments or separate views? Options: Single pane-of-glass, Separate views for on-prem and cloud, Both
• Which asset reconciliation source of truth should we use to map on-prem hosts to cloud instances (for example: CMDB, inventory CSV, cloud tag schema)? Options: CMDB, Inventory CSV, Cloud tag schema, Other
• What latency or metric alignment constraints must be met when correlating events across sites (for example: timestamps normalized to UTC, max 60s ingestion lag)?

• decision_readiness
• current_state
• gaps
• stakeholders
• desired_state
• success_criteria
• desired_state
• success_criteria
• gaps
• decision_readiness
• stakeholders
• current_state
• stakeholders
• decision_readiness
• current_state
• success_criteria
• gaps
• decision_readiness
• success_criteria
• decision_readiness
• decision_readiness
• decision_readiness

• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Service Level Agreement (SLA)
• Order Form / Subscription Agreement
• Data Processing & Access Authorization
• Transition Governance & Handover Plan
• Proof-of-Concept Acceptance Certificate
• Change Order Agreement
• Regulatory Compliance Addendum (conditional)
• Termination & Exit Assistance Agreement

• Go-live Health Check (weeks 1-4)
• First Measurement Review (weeks 4-10)
• Acceptance Gate Decision (around day 90)
• Quarterly Operational Review (recurring)

• Publish an updated operational risk register with owners and target resolution dates for high-priority items.
• Restate acceptance criteria and numeric targets
• Each acceptance criterion from Monitoring Proof of Concept is recorded as pass or fail and the formal acceptance decision is captured.
• All failed or conditional criteria have documented remediation plans with deadlines and verification steps.
• Legacy incumbent wind-down status is confirmed, including archive or migration of data and closure of fallback operational habits.
• Capture the formal acceptance decision in the project record with the buyer's named signatory or documented buyer approval.
• Publish a remediation plan for any failed criteria including tasks, deadlines, and verification steps.
• Deliver a legacy system decommissioning or retained-read-only plan with archive schedule and contract/renewal notes.
• Quarterly SLA and incident metrics review
• Confirm the quarter's SLA attainment percentage meets contracted targets or establish corrective actions and timelines.
• Identify any persistent operational risks or recurring incidents and document remediation work for the next quarter.
• Agree a short list of tuning and capacity tasks to reduce false positive alert rate or improve mean time to resolve.
• Deliver the quarterly incident and SLA report with raw data export for audit and internal review.
• Schedule a tuning and validation window for automation playbooks and alert thresholds.
• Re-confirm success criteria and owners
• Validate the deployment is functionally complete or document critical open items with owners and due dates.
• Confirm named owner for 24/7 escalation and confirm access paths for on-call responders.
• Identify any early telemetry gaps or misconfigurations that would invalidate the upcoming measurement window.
• Publish updated deployment acceptance checklist with status and named owners.
• Create remediation tasks for any critical open issues with target completion dates.
• Deliver an initial alert-volume and dashboard-health snapshot for baseline reference.
• Present first-data against acceptance targets
• Determine whether mean time to detect and mean time to resolve are on a trajectory to meet the acceptance targets recorded in Monitoring Proof of Concept.
• Agree a prioritized set of corrective actions with completion dates to address any shortfalls.
• Confirm the monitoring coverage percent of critical assets and plan for any coverage gaps that affect measurements.
• Deliver incident-level timelines and alert correlation exports covering the measurement window for audit.
• Implement agreed tuning adjustments to alert thresholds and automation playbooks and report verification results.
• Update the monitoring coverage map to show remaining unmonitored critical assets and schedule coverage work.
• Deployment and configuration validation
• Alerts and automation performance review
• Diagnose root causes for any gaps
• Present outcome data against each criterion
• Agree corrective actions and timelines
• Document pass/fail per criterion and capture acceptance decision
• Persistent issues and operational risk register
• Early adoption signals and usage patterns
• Confirm timeline to acceptance gate
• Blockers and open issues log
• Incumbent system wind-down confirmation
• Action item burn-down and next quarter commitments
• Agree remediation items and resolution timeline
• Agree immediate remediation actions