Kickoff: Tell Us About Today

• In a few sentences, describe your current infrastructure footprint and how day-to-day operations are handled today.
• Which of these environments do you actively run in production right now? Options: On‑premises data center, Co‑location / colo, AWS, Azure, Google Cloud, SaaS-only (no infra ops), Edge / remote sites, Other
• Which monitoring, logging, or observability tools are currently in use (pick all that apply)? Options: Prometheus/Grafana, Datadog, New Relic, Splunk, Nagios/Zabbix, Cloud native (CloudWatch/Monitor/Operations), Homegrown/custom scripts, None / basic SNMP
• How is your operations coverage staffed today (who watches alerts and when)? Options: In‑house 24/7 ops team, In‑house business hours only, Follow‑the‑sun via teams, Third‑party on call, No formal coverage / ad hoc
• What recent event or business trigger prompted you to explore managed operations right now? Options: Undetected outage discovered in the morning, Cloud migration complexity, Board‑mandated cost reduction, Loss of key staff / skills, Compliance or audit pressure, Other

When the Night Goes Dark: The Cost of Being Unseen

• Imagine an outage that you only notice the next morning—what are the real business impacts you worry about in that scenario?
• How often in the past 12 months have incidents gone undetected during off-hours until the next business day? Options: Never, Once, 2–5 times, Monthly or more, Unsure
• When gaps have occurred, which outcomes happened most often (select all that apply)? Options: Revenue impact / lost orders, Customer complaints / churn, Extended recovery time, Regulatory impact, Internal reputational damage, No measurable impact
• Tell us about one recent incident that still bothers you—what went wrong and why do you think it wasn’t caught earlier?
• How does it feel internally when a morning discovery happens—annoyance, panic, reputational fear, or something else? Options: Panic / emergency response, Frustration / blame cycles, Calm and contained, Embarrassment with stakeholders, Other / mixed

Who Gets the 2AM Call? Mapping Responsibility and Influence

• Who in your organization currently bears the brunt of after‑hours incidents—and who would be most affected if that responsibility shifted to an external partner?
• Which stakeholder groups should be involved in a managed ops decision (pick all that must sign off)? Options: CIO/CTO, VP/Director of Infrastructure, Platform/Cloud Engineering, Application owners, Security/Compliance, Finance/Procurement, Facilities / Data Center Ops, Legal / Contracts
• Who is the final decision‑maker for outsourcing operations and who is responsible for day‑to‑day runbook ownership? Options: Same person / team for both, Different — decision maker and runbook owner, Undecided / shared responsibility
• How clear are existing escalation pathways today (on a scale and with examples)? Options: Crystal clear — documented and practiced, Mostly clear but informal, Unclear / ad hoc, Nonexistent
• Have there been internal blockers—political, technical, or cultural—when past transitions or tooling changes were attempted? Please give a concrete example.

What's Lurking in Your Legacy Stack?

• Which legacy system or constraint would cause the most trouble during a managed ops transition if it were not fully understood?
• What legacy platforms or appliances do you still rely on (select all that apply)? Options: Older SAN / storage arrays, Unsupported OS versions, Custom on‑prem network gear, Legacy load balancers, Proprietary appliances with vendor lock, Mainframe / specialized hardware, Other
• Are there contractual or vendor support limitations tied to legacy hardware or software that constrain our ability to automate or change processes? Options: Yes — vendor contracts limit changes, Yes — support windows limit updates, No limiting contracts, Unsure
• How long does it typically take your team to restore a failed legacy component (estimate RTO) and who holds tribal knowledge for that recovery? Options: <1 hour, 1–4 hours, 4–24 hours, 24+ hours, Unsure
• If we needed to run parallel operations for a month, which legacy pieces would require special handling or a bespoke playbook?

How Confident Are You in What You See?

• If someone else were to operate your estate tomorrow, how much of production would they be able to monitor and act on with confidence? Options: Nearly all (90%+), Most (60–90%), Some (30–60%), Very little (<30%), Unsure
• Which KPIs or signals do you consider non‑negotiable for visibility (select up to 5)? Options: Service uptime / availability, Mean time to detect (MTTD), Mean time to resolve (MTTR), Error rates / application errors, Capacity thresholds, Security alerts / anomalies, Cost anomalies, Other
• How would you rate the current alert quality—too noisy, adequately actionable, or missing important events? Options: Too noisy — lots of false positives, Generally actionable, Missing key events / blind spots, Mixed — noisy in places, blind in others
• Describe a visibility blind spot that surprised you after a recent incident.
• Which dashboards or reports does your board or exec team ask for regularly? Options: Uptime reports, Incident postmortems, Capacity and cost trends, Security posture, SLA compliance, They don't ask for dashboards

What Would 'Safe Handover' Actually Look Like?

• What single, specific signal would convince you it's safe to move from parallel ops to full managed handoff?
• Which SLA targets must be met before you consider full handoff (choose all that are mandatory)? Options: 99.9% uptime, 99.95% uptime, MTTD < 15 minutes, MTTR < 60 minutes, Alert false positive rate < X%, Security incident detection SLA
• How long would you want parallel operations to run to feel comfortable (typical phased durations)? Options: 2–4 weeks, 1–2 months, 2–3 months, 3+ months, Depends on complexity — need to discuss
• What percentage of runbooks, automation playbooks, and runbook tests must be in place before signoff (estimate)? Options: <50%, 50–74%, 75–89%, 90–100%
• What rollback or escalation obligations would make you feel protected if the transition began to cause instability?

What Are You Willing to Change (and What Will You Keep)?

• What operational boundaries are you willing to hand to a managed provider, and what must remain in‑house? Options: Monitoring & alerting, Incident response & remediation, Patching & updates, Capacity planning & cost optimization, Security monitoring, Nothing — we want advisory only
• Which modules would you expect to be included in managed scope as a minimum? Options: Server/VM operations, Storage and backup, Network & load balancers, Cloud infrastructure (IaaS), Patch management, Security ops
• What maintenance windows or blackout periods are non‑negotiable for your business? Options: Weekdays business hours only, Night windows acceptable, Weekend windows acceptable, No maintenance during month‑end or quarter close, Other
• Are there internal processes or approvals that would slow any changes (e.g., CAB meetings, change freezes)? Describe them and typical lead times.
• What budget, timing, or procurement constraints should we factor into planning the transition? Options: Quarterly budget cycle, Annual budget only, Available immediately / vended contract, Requires RFP / procurement timeline, Other

Next Steps: Signals, Timelines, and Success

• If we completed a 30‑day monitoring proof and you were delighted, what three measurable outcomes would you point to?
• Which success signals would justify moving to the Solution Scope and Mutual Commit stages (select all that apply)? Options: Improved MTTD by X%, Reduced alert noise by X%, Clear runbook coverage for top 10 incidents, Validated automation that avoids service impact, Executive buy‑in for phased handoff
• What governance cadence would make you comfortable during the first 90 days (how often and which participants)? Options: Weekly operations review with execs, Biweekly technical sync, Monthly SLA/governance review, Ad hoc on‑demand
• Which communication channels do you prefer for incident updates and project governance (select all that apply)? Options: Dedicated Slack/Teams channel, Jira/issue tracker, Email incident summaries, Scheduled status calls, Portal with dashboards and runbooks
• Realistically, when could we begin a discovery and 30‑day monitoring proof with your team? Options: Immediately / within 2 weeks, Within 1 month, 1–3 months, Longer than 3 months, Need to resolve procurement first
• Any final concerns or red lines we should know that would make you pause before committing to a proof?

• 30-Day Proof Kickoff & Current-State Confirmation
• Instrumentation & Baseline Deployment
• Alert Tuning & Automation Playbook Workshop
• Mid-Proof Simulation & Response Validation
• Final Proof Review & Acceptance

• A prioritized list of adjustments to alerts, dashboards, and playbooks for the remainder of the proof.
• Document and share dashboard access links and owner lists.
• Review Observed Alert Samples and Noise Analysis
• Reduce expected alert noise to meet target signal-to-noise ratio during the proof.
• Confirm automation playbooks are safe and mapped to customer runbooks with required approval gates.
• Assign clear owners and escalation paths for each alert severity.
• Schedule controlled tests to validate automation without risking production stability.
• Provider to implement tuned alert thresholds and owner routing in the platform.
• Customer to review and approve any automation playbooks that act on legacy systems.
• Both parties to schedule incident simulation windows and define rollback criteria.
• Simulation Plan & Objectives
• Validated detection and response times measured against targets (MTTD/MTTR).
• Confirmation that automation behaves safely and reduces manual steps where intended.
• Introductions & Objectives
• Provider to implement high-priority remediations (alert tuning/playbook fixes) within agreed SLA.
• Customer to validate any changes that affect legacy system behavior in a test window.
• Both parties to update the evidence pack (logs, timelines, dashboards) for the final proof review.
• Executive Summary vs Acceptance Criteria
• Customer provides explicit validation of the 30-day proof outcome (pass/partial/fail).
• Shared understanding of residual risks and agreed remediation plan or extension scope.
• Agreement on next steps and schedule for moving into Solution Scope and Mutual Commit.
• Provider to deliver final proof report including timelines, metrics, incident playbacks, and recommended transition plan.
• Customer to sign acceptance (or approve extension scope) and confirm stakeholders for Solution Scope phase.
• Both parties to schedule the Solution Scope meeting and handoff dates based on the decision.
• A single, validated current-state sentence agreed by customer and provider.
• Quantified consequences (cost/uptime/risk) and urgency documented.
• Clear, measurable acceptance criteria and future-state sentence for the proof.
• Access and pre-work owners committed with dates to enable instrumentation.
• Customer to provide access, runbooks, sample incidents, and baseline metrics within 3 business days.
• Provider to supply deployment plan, collector/agent list, and data mapping template within 48 hours.
• Schedule weekly checkpoint meetings and mid-proof review; invite stakeholders and incident owners.
• Deployment Plan Recap & Roles
• Instrumentation deployed across the scoped environment and telemetry validated.
• Initial set of alerts mapped to SLOs and owners defined.
• Dashboards created that reflect operational and executive views for the proof.
• Legacy telemetry mappings documented and any gaps logged for remediation.
• Provider to complete remaining agent installs and confirm telemetry for all scoped hosts/services.
• Customer to grant any outstanding credentials for legacy systems and validate non-production deployment.
• Define Severity Taxonomy & Escalation Paths
• Execute Simulated Incidents (Replay/Inject)
• Demonstration: Dashboards & Incident Playbacks
• Agent/Collector Installation & Validation
• One-sentence Current State
• Map Automation Playbooks to Runbooks
• Consequence Quantification
• Residual Risks & Recommended Mitigations
• Legacy Integration & Custom Metrics Mapping
• Measure Detection & Response Metrics
• Decision & Acceptance Discussion
• Safe Testing Plan & Human-in-the-Loop Controls
• Debrief: Gaps, False Positives/Negatives, and Runbook Breakdowns
• Initial Alert Rule Mapping to SLOs
• Future State & Acceptance Criteria
• Agree Remediation & Short-term Tune Actions
• Next Steps: Transition Path to Solution Scope
• Dashboard Configuration & Access Controls
• Finalize Tuned Alert Set for Remainder of Proof
• Scope, Timeline & Roles
• Data Retention, Sampling, and Performance Considerations
• Access, Data Sources & Pre-work Checklist

• 24/7 NOC Monitoring and Alerting
• Deploy Monitoring Agents and Legacy Integrations
• Automated Incident Triage and Escalation
• Remote Incident Remediation and Runbook Execution
• Automated Patch Deployment for Servers and VMs
• Cloud Infrastructure Operations (AWS, Azure, GCP)
• On‑Premises Server and Storage Management
• Hybrid Network and VPN Management
• Backup Orchestration and Data Recovery Execution
• Capacity-Based Autoscaling and Resource Adjustment
• Configuration Drift Detection and Automated Remediation
• Security Incident Containment and Remediation

24/7 NOC Monitoring and Alerting

• Do you require 24/7 NOC coverage or business-hours only? Options: 24/7 coverage, Business hours only, Hybrid - extended hours
• Which environments should be included in NOC monitoring? Options: On‑Premises, AWS, Azure, GCP, Other
• What alert channels do you want the NOC to use for initial notifications? Options: Email, SMS, Phone call, Slack/Microsoft Teams, PagerDuty/OpsGenie, Other
• What are your SLA targets for incident detection and initial response? Options: Detect <15 minutes / Respond <15 minutes, Detect <30 minutes / Respond <30 minutes, Detect <1 hour / Respond <1 hour, Custom
• Are there scheduled blackout or maintenance windows that NOC should suppress alerts for? Options: Yes, No
• Please list primary contacts, escalation owners, and after-hours on-call contacts for NOC escalation.

Deploy Monitoring Agents and Legacy Integrations

• Do you prefer agent-based instrumentation, agentless collection, or a mix? Options: Agent, Agentless, Mixed - agent where possible
• Which legacy systems or protocols must be integrated (e.g., SNMP, WMI, custom APIs, mainframes)? Options: SNMP, WMI, Custom API, Proprietary storage/API, Mainframe/host, Other
• How many hosts, devices, or endpoints require monitoring on initial rollout? Options: <50, 50-250, 250-1,000, 1,000+
• Are there change-control, maintenance-window, or approval processes required before installing agents? Options: Yes, No
• Describe network access constraints for agent deployment (e.g., no outbound internet, jumpbox required, isolated VLAN).
• Do you require special data handling or compliance (e.g., PCI, HIPAA) for telemetry collected by agents? Options: Yes, No

Automated Incident Triage and Escalation

• Do you want automated triage rules to classify incidents before human review? Options: Yes - full triage, Yes - preliminary only, No - manual triage
• Which escalation model should we use for incidents? Options: On-call rotation, Role-based escalation, Team-based escalation, Time-based escalation
• Which external systems should triage/escalation create or update tickets in? Options: ServiceNow, Jira, Zendesk, PagerDuty, Other
• What time thresholds should trigger escalations (detection → triage → engineer notification)? Options: <5 minutes, <15 minutes, <30 minutes, 1 hour, Custom
• Do you have existing classification or severity rules we should import? Options: Yes, No
• What acceptance criteria define correct automated triage (e.g., false positive rate, classification accuracy)?

Remote Incident Remediation and Runbook Execution

• Do you permit remote remediation actions by the provider (write operations) versus read-only diagnostics? Options: Allow full remediation (write), Allow limited automated remediation, Read-only diagnostics only
• How many standardized runbooks exist or should be created initially? Options: None - create from scratch, 1-5, 6-15, 16+
• Should runbook execution be fully automated, manual with automated suggestions, or operator-led? Options: Fully automated, Manual with playbook suggestions, Operator-led
• What rollback behavior is required if a remediation playbook fails? Options: Automatic rollback, Pause and require manual approval, Notify and continue manual remediation
• Are there systems that require special authorization, audit trails, or escrowed credentials for remediation? Options: Yes, No
• List any environment-specific conditions or customizations the runbooks must account for (custom configs, legacy quirks).

Automated Patch Deployment for Servers and VMs

• Do you want automated patch deployment for OS, applications, firmware, or a combination? Options: OS only, Applications only, Firmware/hypervisor, Combination / All
• What patch approval workflow do you require (auto-approve, staged approval, manual windows)? Options: Auto-approve, Staged approval (canary then broad), Manual approval required
• When are allowed maintenance windows for patch installation and reboots? Options: Weeknight windows, Weekend windows, Anytime with approval, No reboots allowed
• Are automated reboots allowed after patching or do they require approval? Options: Allowed automatically, Require approval, Not allowed
• Do you require patch rollback or snapshotting prior to patch execution? Options: Yes - rollback required, No - rollback not required, Prefer snapshots where supported
• Are there regulatory or change-control constraints (change board, maintenance tickets) governing patch deployment? Options: Yes, No

Cloud Infrastructure Operations (AWS, Azure, GCP)

• Which cloud providers and accounts/subscriptions are in scope? Options: AWS, Azure, GCP, Other
• What is your cloud account structure (single account, multiple accounts, organizational units)? Options: Single account/subscription, Multiple accounts/subscriptions, Organization/tenant with OU structure
• Which managed cloud services must be operated (e.g., VMs, RDS/Cloud SQL, Kubernetes, serverless)? Options: VMs/Instances, Managed Databases, Kubernetes/EKS/AKS/GKE, Serverless (Lambda/Functions), Storage (S3/Blob/GCS)
• Do you permit cross-account or cross-subscription roles/service accounts for operations, or are there strict IAM constraints? Options: Cross-account roles allowed, Strict IAM - limited access, Other (describe)
• Do you expect the provider to include cloud cost optimization/rightsizing as part of operations? Options: Yes - include cost ops, No - not included
• What recovery, backup, and DR expectations exist for cloud resources (RPO/RTO targets)?

On‑Premises Server and Storage Management

• How many physical servers, hypervisors, and storage arrays are in scope initially? Options: <10, 10-50, 50-200, 200+
• Which vendors and models are in use for servers/storage (e.g., Dell, HPE, NetApp)? Options: Dell, HPE, Cisco, NetApp, Other
• Do you allow remote administration of on-prem systems or require an onsite presence for certain tasks? Options: Remote administration allowed, Onsite required for certain tasks, Onsite only
• Are there firmware, BIOS, or storage microcode update policies that must be followed? Options: Yes, No
• How should hardware incidents be handled (vendor escalation, on-site vendor tech, customer site team)? Options: Provider coordinates vendor, Customer handles vendor, Hybrid - provider initiates but customer approves
• Are there physical or network isolation constraints (air-gapped environments, limited outbound connectivity)?

Hybrid Network and VPN Management

• Do you require management of WAN, VPN, SD-WAN, or firewall configurations as part of the service? Options: WAN/VPN, SD-WAN, Firewall, All of the above, No, monitoring only
• Which network device vendors and platforms are in scope? Options: Cisco, Juniper, Fortinet, Arista, Other
• Are cloud-to-on-prem VPNs and routing (BGP/MPLS) included and which providers host them? Options: Yes - AWS, Yes - Azure, Yes - GCP, Yes - Other, No
• What is the acceptable maintenance impact for network configuration changes (downtime tolerance)? Options: Low (no downtime allowed), Medium (short maintenance windows), High (flexible)
• Do network changes require CAB approval and scheduled change windows? Options: Yes, No
• Describe any QoS, latency, or throughput SLAs that the provider must maintain or monitor.

Backup Orchestration and Data Recovery Execution

• Which backup/orchestration platforms are currently in use or preferred? Options: Veeam, Commvault, Cloud-native (AWS/Azure/GCP), Custom scripts, Other
• What are your RPO and RTO targets for critical, important, and non-critical systems? Options: RPO/RTO <1h, RPO/RTO <4h, Daily RPO/RTO, Custom
• Do you require automated failover or manual recovery processes for DR? Options: Automated failover, Manual recovery, Hybrid
• How often should backup restores/drills be executed and validated? Options: Monthly, Quarterly, Annually, No scheduled tests
• Are backups stored offsite or in-cloud and are there encryption/compliance requirements? Options: Offsite/colocation, Cloud storage, Onsite only, Encrypted at rest required
• Please describe any sensitive data classes or legal/regulatory constraints that affect backup and recovery.

Capacity-Based Autoscaling and Resource Adjustment

• Do you want autoscaling for compute and/or storage resources? Options: Compute autoscaling, Storage autoscaling, Both, No autoscaling
• Which metrics should trigger scaling actions (CPU, memory, custom app metrics, queue depth)? Options: CPU, Memory, Custom metrics, Queue depth, Time-based schedules
• Which platforms will autoscaling target (VMs, Kubernetes, cloud autoscaling groups)? Options: VM scale sets / autoscaling groups, Kubernetes (HPA/Cluster autoscaler), Serverless, Other
• What are your minimum and maximum capacity constraints or budget limits?
• What cooldown, stabilization, and safety limits should be applied to scaling events?
• How will we measure acceptance for autoscaling behavior (success criteria, metrics to validate)?

• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Service Level Agreement (SLA)
• Commercial Terms & Pricing Schedule
• Billing & Payment Authorization
• Transition Handoff Milestones
• Governance & Meeting Cadence
• Rollback & Escalation Obligations
• Data Access, Privacy & Security Addendum (DPA)
• Change Control & Scope Management
• Acceptance Criteria & Sign-off Checklist
• Termination & Exit Plan

• Monthly Operational Success Review
• Runbook & Automation Iteration Workshop
• Incident Retrospective & Root Cause Review
• Shared Channel Governance & Escalation Alignment
• Quarterly Business & Operational Strategy Review

• Define the enhancement intake workflow so requests are triaged quickly and transparently.
• Incident Timeline & Facts
• Establish a clear, documented root cause and a prioritized set of preventive actions.
• Translate findings into specific monitoring and automation changes with owners.
• Capture lessons learned for ops playbooks and team training.
• Create and share a formal RCA document with assigned remediation owners.
• Update monitoring rules and alert thresholds per agreed changes.
• Schedule required training sessions or tabletop exercises for affected teams.
• Channel Purpose & Access Model
• Agree on a single source-of-truth channel policy that preserves customer visibility.
• Finalize an escalation matrix with clear response SLAs for each severity level.
• Introductions & Objectives
• Set up channel guidelines and pin access/ownership details in the shared channel.
• Publish and distribute the escalation matrix and on-call schedule.
• Implement an enhancement intake form or ticket template and link it from the channel.
• Executive Summary of Operational Outcomes
• Align operational performance with business priorities and quantify value delivered.
• Approve a prioritized roadmap and any required budget to implement high-impact enhancements.
• Confirm any SLA or contract adjustments needed based on operational realities.
• Prepare a one-page executive summary of outcomes and ROI to circulate to stakeholders.
• Decision on prioritized enhancements and allocation of budget or approval path.
• If applicable, draft SLA amendment language reflecting agreed changes for legal review.
• Confirm SLA and success-signal compliance or identify specific shortfalls.
• Prioritize and assign corrective actions for incidents, runbooks, and automation tuning.
• Ensure visibility and alignment between customer and provider on operational health.
• Owner to update SLA dashboard with any interim adjustments and circulate before next meeting.
• Provider to open prioritized tickets for automation tuning and assign owners.
• Customer and provider to agree on acceptance criteria for any runbook changes.
• Pre-work Recap & Scope
• Produce versioned runbook/playbook updates with explicit acceptance and rollback criteria.
• Agree on a safe test plan and schedule for validation in parallel operations or staging.
• Assign clear owners for maintenance and future iterations.
• Provider to commit updated runbook/playbook versions to the shared repository.
• Schedule validation tasks in staging/parallel ops and notify stakeholders.
• Document rollback criteria and ensure runbook includes explicit escalation steps.
• Business Impact & Consequence Discussion
• Escalation Matrix & On-call Responsibilities
• Success Signals & SLA Dashboard Review
• Gap Identification via Incident Mapping
• Root Cause Analysis
• Major Incidents Summary
• Capacity, Risk & Forecast
• Consequence & Impact Mapping
• Enhancement Intake & Prioritization Workflow
• Live Runbook & Playbook Edits
• Automation & Alert Fidelity Review
• Test & Validation Plan
• Enhancement Roadmap & Investment Requests
• Auditing, Retention & Reporting
• Preventive Controls & Monitoring Changes
• Decisions, Contract/SLA Adjustments & Next Quarter Commitments
• Runbook Effectiveness & Change Requests
• Learning & Training Items
• Ownership, Versioning & Release Steps
• Triggers for Immediate Reopen or Rollback
• Decisions, Owners & Next Steps