Starting Point — Tell Us About Today

• To get us going, what's your role and which team will lead the evaluation? Options: VP, Network Operations, Director, Network Engineering, Network Architect, SRE / Network Reliability, NOC Manager, Platform/Automation Lead, Other
• What's the single most important problem you want this automation to solve right now?
• Which situation prompted this evaluation? Options: Severity‑one outage, Audit/non‑compliance finding, Operational cost pressure, Scaling / network modernization, Executive mandate, Other
• Approximately how many devices would be in scope for the initial lab/pilot? Options: <100, 100–500, 500–2,000, 2,000–10,000, >10,000, Unsure
• How would you describe your current automation maturity? Options: No automation (CLI‑heavy), Ad‑hoc scripts/Ansible, Vendor‑specific automation, Partial intent‑based workflows, Mature, broad automation, Other
• Who is the executive sponsor and what outcome would make them call this engagement a success?

Are You Comfortable Letting Automation Touch Production?

• If a single automated change could prevent the next 4‑hour outage, would you accept a small chance of needing an automated rollback? Options: Yes, if rollback is reliable, Maybe, with strict pre‑checks, No, unacceptable risk, Depends on device/vendor, Unsure
• Who at your organization must explicitly sign off before an automated change is allowed on production? Options: VP/Director, Network Architect, NOC Lead, Change Advisory Board (CAB), Security/Compliance, Platform/Automation Team, Other
• Tell us about a recent change (automated or manual) that eroded trust — what happened and how did your team react?
• Which SLA or operational constraints must automation respect (e.g., maintenance windows, blackouts, peak hours)? Options: No changes during peak hours, Maintenance windows only, Night/weekend scheduling allowed, Anytime with pre‑checks, Other
• How quickly do you expect an automated remediation or rollback to act to avoid customer impact? Options: <30 seconds, 30–120 seconds, 2–15 minutes, Depends on scenario, Unsure
• Which types of config changes would you consider safe for automated rollout without a human in the loop? Options: ACL tweaks, Interface descriptions/comments, BGP neighbor additions, QoS parameter changes, OS/firmware upgrades, Provisioning VLANs, Don't know yet

Where Do Outages and Compliance Bite the Most?

• What recurring failure in your incident queue do you most dread seeing in the morning?
• How often do configuration‑related incidents (human error, drift, bad pushes) trigger major outages? Options: Monthly, Quarterly, Annually, Rarely, Unknown
• For your worst recent outage, what was the root cause, how long to detect it, and how long to fully recover?
• Which manual processes most commonly introduce risk in your environment? Options: CLI one‑offs, Copy‑paste templates, Manual peer review, Ad‑hoc rollback scripts, Email/Slack change requests, Other
• How many devices are currently out of compliance with the approved baseline and how is that tracked?
• What business impact do these incidents cause (revenue, churn, regulatory exposure) and how do you quantify it?
• Which vendor families or specific platforms show the highest frequency of drift or outages? Options: Cisco IOS/IOS‑XE, Cisco NX‑OS, Juniper Junos, Arista EOS, Nokia SR‑OS, Other

What Would 'No Drama' Day Look Like?

• If your network never had a configuration‑caused customer outage again, what would change for your engineers and for your execs?
• Which measurable signals would tell you the automation pilot is delivering real value? Options: Reduced manual outages, Compliance percentage targets, Time saved per change, Mean time to remediate (MTTR), Faster deployments, Fewer escalations to execs
• What target reduction in manual outages would make you consider expanding automation beyond the pilot? Options: >90%, 70–90%, 50–70%, <50%, Unsure
• How would you prefer pilot acceptance criteria to be framed — strict thresholds, trend improvements, or operator qualitative sign‑offs? Options: Strict numerical thresholds, Improved trends over time, Operator qualitative approval, Combination of the above, Other
• Who are the internal beneficiaries if automation succeeds, and who do you expect to push back?
• What timeline feels realistic for you to see meaningful pilot results? Options: 2–4 weeks, 1–3 months, 3–6 months, 6+ months, Unsure

What's Behind the Curtains — Inventory & Vendor Landscape

• How comfortable are you with a vendor‑neutral intent model making consistent changes across Cisco, Juniper and Arista at once? Options: Very comfortable, Cautiously optimistic, Uncomfortable without testing, Not comfortable, Unsure
• Please list the device types, OS versions, and approximate counts you expect in scope for the pilot.
• Which vendors or specific models currently lack automation support and will require custom integrations?
• How often does configuration drift occur across different vendor families and how do you detect it today?
• How representative is your lab/testbed compared to production in topology, scale and vendor mix? Options: Mirrors production closely, Similar but smaller, Basic functional lab only, No lab exists today, Other
• Which integrations must be supported for the pilot (ticketing, NMS, BGP monitoring, CMDB, authentication, etc.)? Options: ServiceNow, SolarWinds/Orion, Splunk, Prometheus, BGP monitoring tools, CMDB, TACACS/RADIUS, Other
• Do you have any custom device models, non‑standard configs, or in‑house tools that will require adapter work?

What's Preventing Confidence in Automated Changes?

• What's the single thing that would make you refuse to run automation without a human in the loop?
• Which pre‑check capabilities are non‑negotiable for you before executing a change? Options: BGP neighbor reachability, Interface state and admin up checks, ACL impact simulation, Configuration syntax and semantic validation, Route convergence simulation, Resource/utilization checks (CPU/TCAM)
• How do you currently validate that a change succeeded in the forwarding plane (not just that a config was pushed)? Options: Manual traffic tests, Synthetic traffic/validation probes, Monitoring alerts and dashboards, Post‑change manual verification, We lack reliable forwarding‑plane validation, Other
• What rollback behavior do you expect for automated changes (immediate auto rollback, staged rollback with gates, manual approval required)? Options: Automatic immediate rollback, Staged rollback with gating checks, Rollback requires human approval, Different semantics per change type, Unsure
• What training, runbooks, or documentation will your engineers need to feel confident operating the automation?
• Which governance processes will need to evolve (CAB, runbooks, oncall shifts) to adopt continuous automation?
• How would you prefer risks and exceptions to surface during a pilot? Options: Real‑time dashboard, Email alerts, Pager/oncall notifications, Daily syncs with engineers, Weekly executive summaries, Other

Pilot to Production — What Must Be True?

• If the pilot fails to validate rollback behavior, would you pause the rollout, continue with restrictions, or stop the project? Options: Pause and remediate, Continue with limited scope, Stop the project, Depends on failure severity, Unsure
• Define the acceptance criteria that would allow you to move from lab to production (please include specific metrics, thresholds, and any qualitative gates).
• Who will own ongoing production automation once the pilot ends—current network team, a new automation team, or shared ownership? Options: Network team, Dedicated automation team, Shared responsibility, Third‑party managed, Unsure
• What commercial, procurement or budget constraints should we factor into pilot planning?
• What escalation and governance structure must be in place before production rollouts begin?
• How would you like handover and runbook ownership structured after successful pilot completion? Options: Network ops owns runbooks, Platform team owns runbooks, Shared ownership, Third‑party support retains ownership, Other
• Which executive KPIs will be used to evaluate success after the pilot? Options: Outage reduction, Compliance %, MTTR, Time saved per change, Operational cost savings, Customer impact metrics

Next Steps & Commitments — How We Move Together

• What's the smallest, fastest pilot that would prove value and build confidence quickly?
• What access and artifacts must we have before starting (device access, configuration baselines, topology diagrams, test accounts)? Options: Read‑only device access, Write access in lab only, Configuration baselines, Topology diagrams, Traffic generator/test accounts, CMDB access, Other
• Who will be the day‑to‑day point of contact and who are the primary decision makers we should keep aligned?
• What timeline and milestones do you commit to for the lab evaluation (start date window, validation duration, review cadence)? Options: Start within 2 weeks, Start within 1 month, Start in 1–3 months, Need longer planning, Unsure
• What concerns would make you pause before granting lab or production access (security, compliance, staffing)?
• How would you like enablement delivered during the pilot (hands‑on workshops, recorded sessions, co‑authored runbooks, shadowing)? Options: Hands‑on workshops, Recorded videos, Co‑author runbooks, Shadowing sessions, Office hours/weekly support, Other
• If we produced a one‑page pilot plan that lists risks, mitigations, owners and acceptance gates, would that help you mobilize stakeholders? Options: Yes, Maybe, No

Start with the Story: Your Most Recent Network Crisis

• Briefly tell us the story of the last major outage or audit finding that made you think ‘we need to change’—what happened and who noticed it first?
• How many subscribers, services, or customers were impacted and for how long? Options: <1000, 1k–10k, 10k–50k, 50k–200k, >200k
• Which systems or device classes failed during that event? Options: Core routers, Edge routers, Distribution switches, Access switches, Firewalls, Load balancers, Wireless controllers, Optical/Transport, Other
• When you replay that incident in your head, what felt worst — the technical failure, the customer fallout, or the internal confusion/coordination? Options: Technical failure, Customer impact, Internal coordination, Executive pressure, All of the above
• Who led the response and how long did it take to restore normal service from detection to fix?

If This Keeps Happening — What Are We Accepting?

• How comfortable are you with the idea that manual configuration errors will continue to cause high-impact outages unless processes change? Options: Uncomfortable — urgent change needed, Concerned but constrained, Acceptable risk for now, Unsure
• How often do incidents tied to human configuration error occur today (production environments)? Options: Weekly, Monthly, Quarterly, Annually, Rarely
• What is the typical internal consequence after an outage (e.g., blameless postmortem, disciplinary action, new runbook) and does that response actually reduce repeat mistakes? Options: Blameless postmortem + change, Runbook updates only, Ad-hoc fixes, no systemic change, Disciplinary action, Other
• How does the executive team measure the cost of these outages (monetary, SLA penalties, reputational, churn)? Options: Monetary loss, SLA penalties, Customer churn, Reputational impact, Not measured consistently
• If nothing changes in the next 12 months, what number or event would force an urgent change in approach?

Inventory Truth: What’s Actually on Your Network?

• Do you have full confidence the official inventory reflects every device, OS version, and installed module across your footprint? Options: Yes — high confidence, Partial — some gaps, No — many unknowns, We don’t maintain a single source of truth
• Which discovery or inventory tools do you rely on today to build that source of truth? Options: CMDB, Network discovery (NMS), Telemetry/streaming, Manual spreadsheets, Vendor tools, Other
• Give us a rough vendor mix for the devices you operate (select all that apply). Options: Cisco, Juniper, Arista, Nokia/Alcatel, Huawei, Ciena, Other
• What percentage of devices do you estimate are actively managed by automated tooling versus manual CLI/config edits? Options: 0–10%, 11–30%, 31–60%, 61–90%, 91–100%
• Where do you see the biggest blind spots in your inventory (e.g., unmanaged PoPs, vendor black-box gear, edge CPE)?

Where Configurations Go Off the Rails

• How often do you discover configuration drift from the approved baseline, and are you surprised by how often it happens? Options: Daily, Weekly, Monthly, Quarterly, Only during audits
• When drift is detected, how is it usually introduced—manual ad-hoc edits, one-off vendor changes, template mismatches, or scripted pushes? Options: Manual CLI edits, Ad-hoc operator scripts, Vendor/third-party changes, Template diverged during deployment, Automated tooling with bugs, Other
• How do you currently detect drift (continuous validation, periodic audits, alarms, customer reports)? Options: Continuous validation, Daily/weekly audits, Event-driven alerts, Customer-reported, Not consistently detected
• Tell us about a configuration drift incident that created customer impact—what slipped past controls and why?
• How long on average does it take from detecting a drift to restoring the approved configuration? Options: <1 hour, 1–4 hours, 4–24 hours, 1–3 days, >3 days

The Human Workflow Behind Every Change

• Why are manual changes still the default for certain tasks — is it speed, trust, lack of tooling, or organizational habit? Options: Speed/urgency, Lack of automated tooling, Engineers don’t trust automation, Complexity of unique cases, Policy or compliance constraints, Other
• Walk us through your change process from request to verification—who approves, who executes, and who confirms success?
• What percentage of changes include a formal pre-check or lab validation before hitting production? Options: None, Some (10–30%), Many (31–70%), Most (71–99%), All
• When a change causes an unexpected problem, how do you roll back—manual CLI rollback, automated rollback, or patch/fix forward? Options: Manual CLI rollback, Automated rollback, Fix forward (patch), Rollback rarely attempted
• Do engineers feel psychological safety to pause and escalate a risky change, or is speed/ownership prioritized over stopping? Options: Safe to pause and escalate, Sometimes unsafe, Often pressured to proceed, Varies by team
• How do shift handovers and on-call rotations influence the likelihood of risky manual edits?

What Would Make Automation Feel Safe?

• If automation is going to run on your core network, what single failure mode would make you refuse deployment today?
• Which of these safety features matter most when you evaluate automation platforms? Options: Pre-change semantic checks, Staged rollouts, Immediate automated rollback, Forwarding-plane validation, Operator approval gates, Audit trails/forensics
• What quantitative pre-check thresholds would you require for a pilot (e.g., 100% policy pass, simulated routing convergence in lab)? Options: Strict (100% pass), High (95–99%), Moderate (80–95%), Flexible depending on case
• How much control do engineers need during automation—full visibility with manual gate, or fully autonomous with alerts only? Options: Manual gate for each change, Manual gate for high-risk changes, Mostly autonomous with supervisor review, Fully autonomous
• What cultural or training steps would help engineers accept automation as a trusted tool?

Show Me the Metrics: What Success Actually Looks Like

• If we could guarantee one measurable improvement from a pilot, which would move the needle for your leadership? Options: Fewer outages, Reduced mean time to repair, Lower compliance drift %, Faster provisioning time, Reduced operational headcount/time
• What are your current baseline metrics for the above (e.g., outage count/year, MTTR, percent non‑compliant)?
• Which acceptance criteria would you require to move from lab validation to production? Options: Zero critical failures in pilot, X% reduction in manual outages, Pre-check pass rate threshold, Successful staged rollout at scale, Executive sign-off
• Over what timeline would you expect pilot results to be meaningful (days, weeks, months)? Options: Days (1–7), Weeks (2–8), Months (2–6), Longer than 6 months
• Who in your organization will sign off that the pilot met acceptance criteria (roles/names)?

Practical Constraints: What Would Block a Safe Pilot?

• What's the single operational constraint that would stop a lab‑to‑production pilot (access, vendor support, testbed fidelity, regulatory, or budget)? Options: Access to devices, Vendor API/integration gaps, Testbed fidelity, Regulatory/compliance, Budget/Procurement, Operational bandwidth
• Do you have a testbed that accurately represents your production stack—same OS versions, topologies, and vendor mix? Options: Yes — mirrors production, Partially — some differences, No — significant gaps, We don’t have a testbed
• What level of access can you grant for a pilot (read-only telemetry, configuration push, full admin)? Options: Read-only telemetry, Change-only in testbed, Change in segregated production slice, Full admin in selected devices
• Are there regulatory or procurement steps we must complete before any automation software touches devices? Options: Yes — regulatory approvals, Yes — procurement contract, Both, None
• What internal teams must be involved for a pilot to run (NOC, Engineering, Security, Compliance, Vendor support)? Options: NOC, Network Engineering, Security, Compliance, Procurement, Vendor/Field engineers

Next Moves: Who, What, and How Fast?

• Based on our conversation, which pilot scope feels most realistic for your organization to validate safety and value first? Options: Compliance auditing across footprint, Simple provisioning (edge services), BGP/MPLS core change validation, Closed-loop rollback on failed changes, Multi-vendor templating for a single service
• Who should be the primary sponsor and the day‑to‑day owner from your side for a 6–8 week pilot?
• What timeline would you be willing to commit to for an initial pilot (start date window and duration)? Options: Start within 2 weeks, Start 2–6 weeks, Start in 1–3 months, Longer/uncertain
• What would you need from us before you can commit to the pilot (POC materials, architecture diagrams, vendor integrations, security review)? Options: POC materials, Architecture/Network diagrams, Integration plan with vendors, Security/compliance pack, Commercial/pricing outline
• Any final concerns or deal-breakers we haven't surfaced that would prevent this pilot from being approved?

Quick Intro: Who's Speaking and What's Most Pressing?

• Which role are you answering for today? Options: VP Network Operations, Director of Network Engineering, Network Architect, NOC Manager, Senior Network Engineer, Vendor/Consultant, Other
• Roughly how many production network devices would be in scope for the pilot? Options: <100, 100–499, 500–2,499, 2,500–9,999, 10,000+
• Which vendors are included in your environment (select all that apply)? Options: Cisco (IOS/IOS-XE/IOS-XR), Juniper (Junos), Arista, Nokia/Alcatel, Huawei, Other
• What single problem pushed this project onto your roadmap right now?
• Have you run a lab or pilot for network automation before? Options: Yes — production-like pilot completed, Yes — limited/happy-path pilot, Tried but aborted, No, first pilot planned
• What is your target timeline to start a production-safe pilot? Options: Immediately (within weeks), 1–3 months, 3–6 months, 6+ months, Undecided

What If Automation Had a Blind Spot?

• How would your team react if an automated change unknowingly caused a five-hour outage tomorrow? Options: Emergency stand-down & rollback, Blame automation & disable, Root-cause, refine checks, re-enable, Escalate to executive review, Other
• Tell the story of the last severity‑one outage tied to a config change—what exactly happened and who was affected?
• Which emotions or cultural reactions followed that outage (select all that apply)? Options: Distrust of automation, Pressure for manual gatekeeping, Demand for more testing, Blame toward individuals, Desire for faster root-cause tools
• Who ultimately owned the decision to return systems to service and how was that resolved? Options: NOC lead, Network engineering director, On-call engineer, Vendor support, Cross-team task force, Other
• How long did it take to identify root cause and restore normal forwarding behavior? Options: <30 minutes, 30–120 minutes, 2–4 hours, 4–8 hours, 8+ hours

Where Your Risk Lives Today

• If you had to bet tomorrow on what will break the network next, where would you place your chips? Options: Manual CLI changes, Configuration drift, Vendor interoperability edge case, Uncovered dependency during change, Process/communication failure, Other
• How often do engineers perform ad‑hoc CLI changes outside of scheduled change windows? Options: Multiple times daily, A few times a week, Weekly, Monthly, Rarely/never
• Do you run automated compliance audits today? Options: Yes — continuous monitoring, Yes — periodic scans, Partial coverage, No
• Estimate the percentage of devices that show configuration drift from approved baselines: Options: <5%, 5–15%, 16–30%, 31–60%, 61–100%
• Describe a specific manual process that repeatedly introduces risk (who does it, why it exists, and what breaks):
• Which teams are most frequently making risky manual changes (select all that apply)? Options: NOC/operations, Core network engineering, Field engineering, Third‑party contractors, Automation team, Other

Who Holds the Gate?

• If we needed to initiate an emergency rollback at 02:00, who has the authority to approve and execute it? Options: On‑call engineer, NOC lead, Director of Engineering, Runbook‑designated owner, Cross‑functional incident commander, Vendor support
• How are change approvals currently documented and enforced (ticketing system, email, chat, portal)? Options: ITSM/ticketing, Email threads, Chat ops (Slack/MS Teams), Change portal, Informal verbal approvals
• What is the typical lead time between an approved change and its execution? Options: Immediate (same day), 24–72 hours, 3–7 days, >7 days
• Are there formal SLAs or executive checkpoints that must be satisfied before automation can change production? Options: Yes — documented SLA/checkpoints, Informal executive review, No formal checkpoints, Undecided
• Who needs to be in the pilot governance committee (names/roles) and who is the ultimate sign‑off owner?

If Production Could Break on a Tuesday, How Fast Can You Recover?

• In a worst‑case change failure, what is your realistic mean time to recovery (MTTR) today? Options: <15 minutes, 15–60 minutes, 1–4 hours, 4–8 hours, 8+ hours
• Do you have automated rollback tooling and has it been used in production? Options: Yes — automated rollback used, Yes — available but unused, Partial tooling (manual steps remain), No
• Are runbooks for change failure and rollback documented, accessible, and tested regularly? Options: Documented & tested, Documented, rarely tested, Documented but incomplete, Not documented
• Who owns maintaining the runbooks and who signs off on changes to them? Options: NOC, Network engineering, SRE/automation team, Vendor, Shared responsibility
• Describe the last time you executed a simulated rollback or chaos test—what worked and what surprised you?

How Real Is Your Lab?

• Does your lab faithfully reproduce the production vendor mix, topologies, and traffic patterns, or is it a ‘happy‑path’ playground? Options: Full production replica, Partial replica (vendors/topology), Topology only, limited traffic, Configuration templates only, No lab
• Which platforms and OS versions are represented in your lab (list vendors/models/versions)?
• Does the lab simulate BGP/IGP convergence, stateful sessions, and vendor interoperability edge cases? Options: Yes — high fidelity, Some scenarios only, No — missing dynamic behaviors
• Can we get remote access for engineers and automation runners during the pilot? If not, what approvals are needed? Options: Immediate access available, Access with approvals, On‑prem only — no remote, Not available
• What differences between lab and production worry you most for validating automation?

Show Me the Pre-Checks You Rely On

• Which pre‑checks would have to be bulletproof before you'd let automated changes touch production?
• Which of these pre‑check categories do you currently implement? Options: Config syntax/templating validation, Dependency graph checks, Resource availability (CPU/memory/ports), Routing convergence & BGP check, Compliance/policy checks, Custom vendor health checks
• Who writes and owns pre‑check logic today (roles or teams)? Options: Automation team, Network engineers, Vendor partners, Shared
• What percentage of attempted changes currently fail pre‑checks and what are the common failure reasons? Options: <5%, 5–15%, 16–30%, 31–50%, 50%+
• Which kinds of false positives/negatives in pre‑checks would make you most nervous (examples please)?

Who Will Own This in Day‑to‑Day Ops?

• If automation becomes reliable, who should make production change decisions next year — humans, automation with human oversight, or fully automated systems? Options: Humans (manual approval), Automation with human gates, Fully automated for specific workflows, Hybrid by workflow
• Which team will be the operational owner of the automation platform after pilot (select one)? Options: Network Engineering, NOC/Operations, SRE, Dedicated Automation Team, Shared ownership
• What training, runbooks, and certification would make your engineers trust and adopt automation?
• How should change approvals and alerts be surfaced during the pilot (choose all that apply)? Options: ITSM/ticket integration, Chat notifications (Slack/Teams), Email digests, Dashboard portal, Pager/on‑call integration
• If a rollback fails, what escalation path and SLA do you require?

Let’s Define Success — What Would Make You Trust Automation?

• Would you consider the pilot successful if it prevented one major outage, or do you require hard metrics—and which matters more? Options: Prevent major outage, Achieve predefined metrics, Both equally, Other
• Select up to three primary success metrics you want to measure during the pilot: Options: % reduction in manual outage incidents, Time to validate a change (pre-check to verified), Rollback time (median), % devices compliant post‑pilot, Reduction in manual configuration tasks, Mean time to detect/remediate
• What are acceptable thresholds for rollback time and maximum allowed failed changes during pilot?
• What specific acceptance criteria will your execs require to greenlight production rollout (list deliverables/metrics)?
• Who will be the signatories for pilot acceptance and final go/no‑go to production? Options: VP Network Ops, Director Network Engineering, CISO/Compliance, SRE Head, Other

If We Could Remove One Fear, What Would It Be?

• What single fear—if eliminated—would make your team enthusiastic about adopting automation?
• How much operational visibility and manual control must engineers retain during staged rollouts? Options: Full manual oversight, Human gates at critical stages, Dashboards + automated actions, Fully automated after pilot
• Would staged rollouts with human gating and canary devices make you more comfortable? If so, what gate cadence? Options: Yes — per device group, Yes — per region, Yes — time‑boxed (e.g., daily batches), No — prefer other approach
• What governance cadence would you want during the pilot (how often should stakeholders meet to review telemetry and incidents)? Options: Daily, Twice weekly, Weekly, Biweekly, Monthly
• Are there regulatory, audit, or legal constraints (e.g., change logging, retained approvals, data residency) we must bake into the pilot? Options: Audit/change logging required, Data residency constraints, Regulatory reporting required, None known, Unsure — need to check

Practical Next Steps: Access, Artifacts, and Quick Wins

• Can you provide these artifacts for pilot planning: network inventory, baselines, existing runbooks, and access matrix? Options: All available now, Most available with effort, Partial — will need work, Not available
• Which systems must the platform integrate with during the pilot (select all that apply)? Options: ITSM/Ticketing (ServiceNow/Jira), Monitoring (Nagios/Prometheus), NMS/EMS, AAA/LDAP, CI/CD/Automation pipelines, Vendor APIs
• Who will be our primary point(s) of contact for technical access, approvals, and governance during the pilot (names/roles)?
• What would you consider a meaningful quick win in the first 30 days of the pilot? Options: Automated compliance sweep, Safe provisioning of a standard service, Validated rollback on a canary device, End‑to‑end lab validation of a critical workflow, Other
• Are there any non‑negotiable constraints (maintenance windows, blackout windows, IP restrictions) we must plan around?

Start With Where You Stand

• What's your primary role and where do you sit in the org? Options: VP Network Operations, Director Network Engineering, Manager / Team Lead, Senior Network Engineer, NOC Lead, Platform/Automation Engineer, Other
• Roughly how many network devices are in scope for this evaluation? Options: <100, 100–499, 500–2,499, 2,500–9,999, 10,000+
• Which vendors and device families are in your core/mid/edge estate today? Options: Cisco IOS/IOS-XE, Cisco NX-OS, Juniper Junos, Arista EOS, Nokia SR/PN, Other
• What triggered this conversation now—an outage, an audit, cost pressure, or something else? Options: Severity-1 outage, Compliance audit, Operational cost/efficiency, Cloud/architecture change, Strategic automation initiative, Other
• Briefly describe the specific outage or audit finding that pushed this to the top of your list.

If One Manual Error Can Take Down 50K Users, Why Are We Still Doing It Manually?

• How often do engineers make manual changes that touch core routing or subscriber-facing infrastructure? Options: Daily, Several times/week, Weekly, Monthly, Rarely
• How frequently do those manual changes result in incidents, outages, or configuration rollbacks? Options: Multiple times/month, Monthly, Quarterly, Semi-annually, Rarely/Never
• Tell the story of the last manual-change incident that caused significant impact—what exactly happened, who made the change, and how long until service recovered?
• How confident are you that your current rollback processes would reliably revert an unsafe change without manual intervention? Options: Very confident, Somewhat confident, Marginally confident, Not confident at all
• How did that incident change team behavior, priorities, or how leadership views automation?

What's the Real Cost — Beyond the Ticket

• Estimate the annual engineering hours spent on repetitive CLI changes and manual validation. Options: <500 hours, 500–1,999 hours, 2,000–4,999 hours, 5,000–9,999 hours, 10,000+ hours
• What is the typical subscriber or revenue impact of a significant outage like the one that prompted this evaluation? Options: Minimal, Moderate, High, Very high/critical
• Which KPIs or SLAs are used to judge your team's performance (e.g., MTTR, availability, compliance %)? Please list and include targets if possible.
• Who inside the business feels the most pressure when outages occur (pick all that apply)? Options: VP Network Ops, CTO, Customer Care/Support, Security/Compliance, Field Operations, Product/Service Owners
• How would reducing manual-change incidents change the narrative for those stakeholders—what wins would they celebrate?

Where Automation Scares You (and Why)

• What keeps you awake at night about handing changes to automation rather than engineers? Options: Unintended outage, Vendor-specific incompatibility, Rollback failure, Insufficient pre-checks, Security exposure, Lack of visibility/traceability, Cultural resistance from engineers
• Which device types or network zones do you consider highest-risk for automation? Options: Core routers, Edge routers/PE, Aggregation switches, Data center spine/leaf, Firewalls/security devices, Wireless controllers
• Have you experienced failed automation or integration attempts before? If so, what vendor-model or workflow gaps surfaced?
• What level of service disruption is tolerable during a failed automated change? Options: Auto-rollback within 30s required, Rollback <5 minutes acceptable, Rollback <30 minutes acceptable, Minor outage acceptable with manual recovery, No disruption tolerable
• Who in your decision chain would need to be convinced that automation is safe enough for production?

What Would ‘Trusting Automation’ Actually Look Like Here?

• Which validation signals would make you comfortable letting an automated change proceed in production? Options: Pre-check pass on candidate devices, Control-plane convergence (BGP/OSPF), Forwarding-plane verification, No packet loss/traceroute checks, Staged rollout with smoke tests, Automatic rollback on divergence
• What is the maximum acceptable time between a failed post-change check and full remediation? Options: Automatic within 30s, Automatic within 2 minutes, Automatic within 10 minutes, Manual remediation only
• Describe a pilot change you would be comfortable running in a lab (device types, vendors, and the change type—e.g., BGP policy, VLANs, ACLs).
• Who would own day-to-day execution and who would sign the acceptance at pilot close? Options: Network Engineering, NOC, Automation Team/Platform Owner, Security/Compliance, Third-party Managed Services
• What post-change dashboards, alerts, or reports would give you the confidence to hand this over to ops?

What’s Blocking a Smooth Pilot?

• What practical barriers stand between you and a lab-to-prod pilot right now? Options: No dedicated testbed, Limited device access/privileges, Missing approved baselines, Insufficient vendor integrations, Governance/change windows, Staffing/skills gaps
• How realistic is it to build a testbed that mirrors production fidelity (config, topology, traffic)? Options: Easy, Possible with effort, Very difficult, Impossible
• If testbed fidelity is limited, how would you accept validation results—through synthetic tests, mirrored traffic, or staged production with heavy safeguards? Options: Synthetic/lab-only tests, Mirrored/replicated traffic validation, Limited live traffic within maintenance window, Full live traffic only
• Do you already use any automation frameworks or scripts we should integrate with (vendor-native, in-house, or IT automation)? Options: Vendor-specific automation, In-house scripts, Generic IT automation (Ansible/Terraform), Commercial automation platform, None
• What approvals and timeline are required internally to greenlight a pilot (who signs, how long does it take)?

Imagine The Pilot Succeeds — What Changes?

• If the pilot cut manual-change outages by 80%, what would your team do first with the reclaimed time? Options: Architectural improvements, Capacity planning, Security/compliance hardening, Automation of more change types, Engineer training
• Which operational KPIs would you publish to demonstrate pilot success internally? Options: MTTR, Outages/month, Compliance %, Mean time between incidents, Percent changes automated
• How would ownership and runbooks shift after handover—who trains whom and how is accountability enforced?
• Are there regulatory or internal audit gates that must remain visible post-deployment? Options: Yes - regulatory, Yes - internal audit, No formal gates, Unsure
• Describe what a successful operational handover looks like at 30, 60 and 90 days.

What Would Make You Say Yes Today?

• Which commercial or contractual assurances matter most to you for a pilot and production rollout? Options: Defined pilot scope, SLA for remediation, Liability/indemnity terms, Rollback guarantees, Dedicated support/CSM, Training included
• What pilot length would give you enough data to make a confident production decision? Options: 2 weeks, 4 weeks, 8 weeks, 12 weeks+
• Who should sit on the mutual-governance committee that decides go/no-go to production? Options: VP Network Ops, Director Network Engineering, Security Lead, Project Manager, Vendor CSM/Delivery Lead
• What are your non-negotiables for moving from lab validation to production (e.g., specific tests, runbooks, personnel)?
• What pricing or commercial model would you prefer for the pilot phase? Options: Proof-of-value (fixed/short term), Consumption-based, Subscription with pilot discount, Pilot included with longer contract, Other

Validation Needs — Let’s Get Specific

• Which validation checks must absolutely pass before a change is accepted? Options: Forwarding-plane convergence, Control-plane stability (BGP/OSPF), Routing table consistency, No packet loss beyond threshold, Compliance baseline matched, Successful rollback test
• What remediation timing is required if a post-change check fails? Options: Auto-remediate <30s, Auto-remediate <2 minutes, Auto-remediate <10 minutes, Manual remediation only
• List concrete test cases or audit examples you want exercised in validation (e.g., BGP neighbor flap, ACL change causing traffic drop).
• What level of live-traffic testing is acceptable during validation? Options: No live traffic—lab-only, Mirrored/replicated traffic, Limited live traffic with rollback window, Full live traffic allowed
• Who will sign the validation checklist and what documentary evidence do they require?

Next Steps — How Do We Keep Momentum?

• If we could guarantee a safe, auditable rollout path, what is the fastest realistic timeline you could commit to for starting a pilot? Options: Immediately, Within 2 weeks, 2–6 weeks, 6–12 weeks, Longer than 12 weeks
• What specific resources or access do you need from us to start (testbed build, device credentials, runbooks, training)? Options: Testbed build, Device access/privileges, Runbooks and playbooks, Engineer training/workshops, Vendor integrations
• How should we structure governance and reporting during the pilot—meeting cadence, artifacts, and escalation paths?
• What communication cadence would you prefer while the pilot runs? Options: Daily standup, 2–3x week sync, Weekly review, Biweekly checkpoint
• Are there any unresolved concerns or questions we haven't addressed that would prevent you from agreeing to a pilot right now?