Quick context, so we start on the same page

• To begin, what event or pressure prompted you to explore managed application support now? Options: Attrition of a senior platform consultant, Upcoming major version upgrade, Budget-driven headcount reductions, Recent outage or near-miss, Proactive efficiency initiative, Other
• How many business-critical applications does your team expect the managed service to cover first? Options: 1, 2-3, 4-6, 7+
• Which systems, by category, are highest priority for maintaining uptime and business continuity? Options: ERP, CRM, HCM, Custom/legacy application, Integration middleware, Other
• Please summarize the immediate cost or risk you are trying to avoid by engaging a managed provider, in one or two sentences.
• If we cannot improve your current support experience within the next quarter, what is the single operational outcome that would be most damaging to your organization?

Where outages and slow responses actually hurt you

• When a severity-one incident happens today, which part of your response process breaks down most often? Options: Initial triage ownership, Access to system logs or environments, Availability of subject matter expertise, Vendor escalation handoffs, Change rollback capability, Other
• Walk me through the last severity-one incident that required escalation outside your team, what unfolded and where delays occurred.
• How long did it take from ticket creation to a meaningful remediation step during that incident? Options: Under 1 hour, 1-2 hours, 2-4 hours, 4-8 hours, 8+ hours
• Which concrete artifacts or records are missing when outside help gets involved, and how often are they missing? Options: Runbooks and playbooks, Recent config change logs, Access credentials, Integration diagrams, None of the above, Other
• What single unresolved dependency or knowledge gap would make you stop a pilot immediately?

Who feels the pressure and who can say yes

• Which roles feel most exposed when application support degrades, and why do they feel that way?
• Provide the roles and escalation contacts who must be involved in SLA governance, for example the person who approves credits and the one who signs change orders.
• Who within your organization will own the pilot from day-to-day, and who is the executive sponsor that signs final approval? Options: VP of IT, CIO/CTO, Director of Applications, IT Operations Manager, Program Management Office, Other
• How quickly can those decision makers convene and sign if the pilot proves the metrics you need? Options: Within 1 week, 1-2 weeks, 2-4 weeks, Longer than 4 weeks
• If the pilot achieves targets but a key stakeholder is unconvinced, who has the final authority to move forward anyway?

Alternatives you are seriously weighing

• Which alternatives are currently under active consideration besides engaging an external managed service? Options: Keep existing internal team, Hire one or two senior consultants, Extend vendor support contract, Build an internal center of excellence, Partner with a systems integrator, Other
• Which incumbent or internal approach would need to change materially for you to abandon external options and stay where you are? Options: Increase headcount, Document configuration fully, Improve on-call rotations, Set stricter SLAs internally, Secure additional budget, Other
• Has anyone proposed solving this without a vendor, and if so what is the proposed timeline and budget for that plan? Options: Yes, hiring plan under 3 months, Yes, hiring plan 3-6 months, Yes, internal reorganization only, No internal proposal, Other
• What single decision criterion—cost, speed of response, configuration knowledge retention, or governance clarity—will drive the choice this quarter? Options: Cost, Response speed, Configuration knowledge retention, Governance and SLAs, Other
• If you were to stay with your current vendor or internal team, what proof would you need in 30 days to reconsider that choice?

If we run a pilot, these are the milestones that matter

• What measurable outcomes from a time-boxed pilot would make you ready to sign a contract that week? Options: Severity-one response consistently under target, Verified root-cause analysis for 90% of tickets, Successful knowledge-transfer checkpoints, No regressions during parallel ops, Clear runbook ownership, Other
• List your target metrics for severity-one response time, mean time to resolution, and ticket reopening rate for the pilot. Options: Severity-one < 2 hours, MTTR < 8 hours, Reopen < 5%, Severity-one < 4 hours, MTTR < 12 hours, Reopen < 10%, Custom targets (will specify), No formal targets yet
• Which acceptance artifacts must be produced to approve the pilot, for example validated runbooks, knowledge-transfer signoffs, or a performance report? Options: Validated runbooks, SME shadowing logs, RCA reports for pilot incidents, Access and environment verification, SLA performance dashboard, Other
• If the pilot meets SLA numbers but fails to show retention of your configuration knowledge, would you proceed to contract? Options: Yes, No, Maybe with conditions
• What is the minimum pilot duration you would accept to feel the results are representative? Options: 2 weeks, 4 weeks, 8 weeks, One quarter

Practical readiness: the gates we cannot skip

• Which integration points or environment access needs are absolute prerequisites before a pilot can start? Options: Test environment access, Production read-only logs, API keys and integration endpoints, Backup and rollback access, Vendor support contacts, Other
• Who owns the systems and APIs we must integrate with, and who will provide the access and coordination?
• How would you grade your data and configuration hygiene for the target application right now? Options: Well documented and current, Partially documented, Poorly documented, Not documented at all
• Do you have regulatory, compliance, or procurement constraints that could delay knowledge transfer or production access? Options: Yes, regulatory approvals required, Yes, procurement review required, No significant constraints, Unsure
• Is there any approval, budget hold, or contract clause that must be cleared before a pilot can start?
• What single integration or compliance gap would force us to pause the project until it is resolved?

Timeline, cost signals, and the path to a decision

• If the pilot proves the three core metrics, what internal steps remain before you can sign and how long do they typically take? Options: Legal review only (1-2 weeks), Procurement plus legal (2-4 weeks), Executive approval required (2-6 weeks), Budget reallocation needed (4+ weeks)
• Which procurement model do you prefer for a phased engagement, fixed-price pilot then SLA contract, or consumption-based billing? Options: Fixed-price pilot then SLA contract, Consumption-based billing, Subscription with usage bands, Undecided
• What is your target window to start knowledge transfer and parallel operations if the pilot is successful? Options: Immediately after pilot, Within 30 days, Within 60 days, Within 90 days, Longer than 90 days
• Who must be present for an initial kickoff meeting to commit to a pilot and who can approve schedule changes after kickoff?
• What single scheduling, legal, or procurement risk could push your start date beyond 90 days?
• Realistically, what would make you sign within 30 days of a successful pilot? Options: Clear SLA performance report, Knowledge-transfer signoffs, Executive alignment and budget approval, Minimal contract negotiation, Other

• Solution Walkthrough — Managed Application Support

• Confirm the current state and its cost
• You confirm that the incident response runbook meets your containment and escalation expectations for severity-one incidents.
• Deliver a tailored pilot acceptance criteria document and draft incident response runbook within five business days.
• Provide the list of recent severity-one incidents for the past 12 months and the custom configuration inventory for the pilot application.
• Map your priorities to an incident response runbook
• You confirm that the knowledge-capture approach prevents repeated rework on custom configuration issues.
• Show how configuration knowledge is captured and applied
• You agree on measurable pilot acceptance criteria and the remaining evidence needed to decide.
• Run a simulated severity-one incident using the provided scenario and deliver a time-stamped incident timeline before the pilot kickoff.
• Validate that the proposed outcomes match your needs
• Define measurable acceptance criteria for the pilot
• Confirm next steps, responsibilities, and timelines

• Solution Walkthrough — Managed Application Support
• Solution Experience Deck
• Solution Brief

• meeting
• slides
• document

• 24/7 Incident Triage and Resolution
• Severity-One Incident Rapid Response (≤2 hours)
• Change Request Fulfillment and Configuration
• Application Release, Patch and Deployment
• Root-Cause Analysis and Permanent Remediation
• Performance Monitoring and Proactive Tuning
• User Support and Ticket Fulfillment (L1–L3)
• Enhancement Delivery and Customization
• Vendor Coordination and Escalation Management
• Knowledge Transfer and Runbook Delivery
• Parallel Operations and Co-Run Support
• Process Optimization Implementation (continuous improvements)

24/7 Incident Triage and Resolution

• Which environments (production, disaster recovery, staging, UAT) must be covered by 24/7 triage for your target application? Options: Production, Disaster recovery, Staging/UAT, Development, All listed
• How many concurrent incidents for this application do you typically see during the peak month (estimate using ticket counts)? Options: 0-5, 6-20, 21-50, 50+
• Who will be the named escalation contact in your organization (role, phone, email) that we should list on incident pages and runbooks?
• When is your standard maintenance window for production deployments (day, start time, timezone) that triage must avoid unless pre-approved? Options: Weekday business hours, Weekend window, Nightly window (specify), No preferred window
• Describe the minimum ticket content you require for triage in your incident system (for example error code, stack trace, affected users, incident ID)

Severity-One Incident Rapid Response (≤2 hours)

• Provide the exact definition of a severity-one incident for this application (include specific error codes, service unavailability thresholds, or user-impact counts)
• Specify any emergency access privileges we are permitted to use during a P1 event (break-glass accounts, root DB access, escalation on-call credentials) Options: Break-glass permitted with audit, Limited privileged actions only, No emergency access allowed, Other
• Indicate which monitoring alerts or metric thresholds must auto-escalate to severity-one (include alert names or metric IDs, e.g., p95 latency > X ms)
• Name the incident playbook file or runbook we should execute first for a P1 (for example prod_p1_playbook.md or on-call-runbook entry)
• Confirm the evidence you will accept to validate a severity-one response within 2 hours (for example time-stamped ticket activity, recorded incident call, response-time dashboard snapshot) Options: Time-stamped ticket log, Incident call recording, Monitoring dashboard snapshot, All of the above

Change Request Fulfillment and Configuration

• Select which types of configuration changes are in scope for standard change fulfillment for this application (for example parameter edits, integration credential rotation, DB tuning) Options: Configuration parameter edits, Credential rotation, Database parameter tuning, Schema migration, Other
• Explain the approval workflow for changes to this application (include change advisory board cadence, required approvers and required artifacts like test results or impact matrix)
• Outline the standard lead time and blackout dates for non-emergency changes to production (number of days required for scheduling and any holiday windows)
• Choose the regression test artifacts you require for a configuration change to be accepted (for example automated test suite ID, UAT sign-off document, smoke test checklist) Options: Automated test suite results, UAT sign-off, Smoke test checklist, No regression required
• Identify who will act as the authorized change approver and provide their role and contact for emergency waiver approvals

Application Release, Patch and Deployment

• Estimate your current release cadence for this application (pick the closest frequency) Options: Weekly, Biweekly, Monthly, Quarterly, Ad hoc
• List the artifacts each release package must include (for example migration scripts, rollback script, release notes, build checksum) Options: Migration scripts, Rollback script, Release notes, Build checksum, Database migration plan
• Detail whether zero-downtime deployment is required and specify which components must stay available during deployment (web tier, batch jobs, API endpoints) Options: Zero-downtime required, Short maintenance window acceptable, Downtime allowed
• Share the deployment pipeline trigger method and the artifact naming convention we should expect (CI pipeline name, artifact ID pattern)
• Enter the rollback criteria that should trigger an immediate revert during a deployment (for example error rate > X%, health check failures)

Root-Cause Analysis and Permanent Remediation

• Report the expected timeframe for delivery of a root-cause analysis (RCA) after a major incident (for example 24 hours, 72 hours, 2 weeks) Options: 24 hours, 48-72 hours, 1 week, 2 weeks
• Supply the RCA template fields you require (for example incident timeline with timestamps, log excerpts, trace IDs, and permanent remediation plan)
• Note which logs and traces must be attached to an RCA (application logs with timestamps, database slow query log, distributed trace spans with trace IDs) Options: Application logs, DB slow query log, Distributed tracing spans, Monitoring graphs
• Record who must formally approve proposed permanent remediation work and the expected approval SLA window
• Assign whether permanent remediation requires a separate change request and regression window or may be included in an operational patch Options: Separate change request required, May be included in operational patch, Case-by-case

Performance Monitoring and Proactive Tuning

• Map the key performance indicators (KPIs) you require for this application (for example p95 API latency, throughput TPS, DB connection pool utilization) Options: p95 API latency, Throughput (TPS), DB connection pool utilization, Error rate
• Enumerate the data sources you can provide for monitoring and tuning (application logs, metrics from your APM or metrics exporter, DB performance views, synthetic transactions) Options: Application logs, APM/metrics exporter, DB perf views, Synthetic transactions
• Declare the alert thresholds you currently use for p95 response time and database slow queries and provide numeric values where possible
• Submit how often you want proactive tuning reports and recommendations delivered (choose a cadence) Options: Weekly, Monthly, Quarterly, Ad hoc
• Highlight any scheduled batch jobs or nightly processes (job name and typical runtime window) that must be considered when tuning performance

User Support and Ticket Fulfillment (L1–L3)

• Clarify which user roles and tiers require support (for example end users, power users, system admins) and the expected hours of coverage per role
• Point to the authentication method your users use (for example SAML single sign-on, local accounts, or multi-factor) and any onboarding steps required Options: SAML/SSO, Local accounts, MFA enabled, Other
• Suggest target SLA thresholds for each support tier for first response and resolution (for example L1 response < 30 minutes) Options: L1 response < 30 minutes, L2 response < 2 hours, L3 response < 4 hours, Custom
• Tell how many knowledge base articles exist for the target application and how they are organized (for example KB count, folder or tag structure)
• Offer the preferred support channels you require for users (email, chat, phone, in-app ticketing) and whether you require templated intake fields per channel Options: Email, Chat, Phone, In-app ticketing

Enhancement Delivery and Customization

• Propose the average number of enhancement requests you expect per quarter for this application Options: 0-5, 6-10, 11-20, 20+
• Verify whether enhancements will require changes to downstream integrations or reporting artifacts (for example API contract updates or ETL jobs) Options: Yes, No, Case-by-case
• Reveal which integration endpoints or schemas an enhancement would need to modify (include API endpoint paths or payload schema names)
• Affirm whether customizations must be preserved across vendor or platform upgrades and give an example (for example a custom plugin or modified data model) Options: Must be preserved, Rebuild after upgrade, Case-by-case
• Classify enhancements by business impact and priority (for example cosmetic, operational efficiency, revenue-impacting) Options: Cosmetic, Operational, Business-critical, Compliance

Vendor Coordination and Escalation Management

• Categorize the third-party vendors and hosted modules integrated with your application (for example identity provider, middleware, payment gateway) and provide available support contacts
• Quantify the number of vendor-managed components that could require escalation during incidents (for example hosted modules, managed integrations) Options: 0, 1-3, 4-10, 10+
• Measure the maximum vendor SLA response time acceptable to meet your uptime objectives and state that threshold (for example initial vendor response within X hours)
• Compare the support tiers you currently hold with key vendors and indicate if contract upgrades to higher tier support are feasible during the engagement Options: Upgrades feasible, No upgrades possible, Unknown
• Rank the escalation path you prefer for vendor issues and list the sequence of contacts and channels (for example app owner -> vendor support -> vendor engineering)

Knowledge Transfer and Runbook Delivery

• Allocate the expected number and duration of knowledge-transfer sessions for the pilot and initial onboarding (for example 8 sessions over 6 weeks) Options: Fewer than 4 sessions, 4-8 sessions, 9-12 sessions, More than 12
• Capture the names and roles of subject matter experts who must participate in runbook handover and include their availability windows
• Provide the acceptance criteria and evidence that will confirm runbook completeness and knowledge-transfer readiness for pilot handoff (for example complete playbook, recorded sessions, shadowing sign-offs) Options: Complete playbook documented, Recorded knowledge-transfer sessions, Shadowing sign-offs by SMEs, All of the above
• State the runbook formats and living-document locations you prefer (for example wiki page, markdown in repo, SOP stored in ticketing system) Options: Wiki page, Markdown repo, Ticketing system SOP, Other
• Outline any hands-on shadowing requirements during transfer (number of co-run shifts, privileged access sessions, or simulated incident drills)

Parallel Operations and Co-Run Support

• Confirm whether the agreed parallel operations period will be one quarter or a different length (select or specify) Options: One quarter (3 months), Two quarters (6 months), Custom (specify)
• Verify which tickets will be routed to co-run versus retained by your internal team and provide an example ticket ID pattern or tagging rule
• Reveal the KPIs and numeric thresholds you will monitor during parallel ops to evaluate coverage (for example median time to acknowledge, percent of P1 responses within 2 hours, RCA quality score)
• Record the process to annotate ownership changes in tickets during parallel ops (for example ticket field updates, owner tags, required approver notes)
• Confirm the acceptance criteria you will use to authorize full SLA-based handoff at the end of parallel ops (for example ticket metric thresholds met, runbook sign-offs, zero P1 breaches within 30 days) Options: Ticket metrics thresholds met, Runbook and shadowing sign-offs, No P1 breaches in 30 days, All listed conditions

Process Optimization Implementation (continuous improvements)

• Capture the baseline MTTR (mean time to repair) and monthly incident frequency we should use as the baseline for measuring improvement (provide numeric values if available)
• Measure the target number of process optimizations you expect per year for this application (for example 12 targeted improvements per year) Options: 4-6, 7-12, 13-24, 24+
• Compare the process areas you want prioritized for optimization (incident runbooks, deployment automation, change gating, monitoring coverage) and rank them by business impact
• Prioritize the stakeholders who must approve optimization changes and indicate the review cycle you expect (monthly, quarterly, ad hoc) Options: Monthly, Quarterly, Ad hoc
• Allocate a governance owner for continuous improvement and provide the owner role, contact, and preferred meeting cadence for reviews

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

• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Service Level Agreement (SLA)
• Knowledge Transfer & Handover Addendum
• Order Form and Pricing Schedule
• Change Order Agreement
• Operational Acceptance Certificate
• Governance & Escalation Charter
• Data Processing Agreement (DPA)

• Go-live Health Check (weeks 1-4)
• First Measurement Review (weeks 4-10)
• 90-Day SLA Attainment Review and Incumbent Wind-down Check
• Quarterly Operational Review
• Annual Performance and Continuous Improvement Review

• Update the enhancement backlog with prioritized items, acceptance criteria, and tentative scheduling.
• Assign and schedule remediation tasks for any SLA shortfalls with target close dates and evidence of closure.
• Publish a compact risk register entry for each unresolved operational risk with agreed mitigation steps.
• Trend review of SLA-attainment and MTTR
• Quarterly SLA and MTTR trends are reviewed and any regressions have assigned remediation plans.
• Backlog priorities for the next quarter are agreed and recorded with acceptance criteria and scheduling intent.
• At least one measurable continuous-improvement action is committed for delivery in the next quarter.
• Re-confirm success criteria and owners
• Execute the next CI action and capture before/after metrics for the following quarterly review.
• Refresh runbooks or knowledge artifacts for any incident types contributing to repeated SLA misses.
• Annual SLA and performance summary
• A documented view of annual SLA attainment and CI outcomes exists and is accepted as the basis for next-year planning.
• Priority improvement initiatives for the next 12 months are agreed with outcome measures and expected completion windows.
• Knowledge retention gaps and bench coverage risks are identified with mitigation actions assigned.
• Publish the annual performance report and the agreed 12-month improvement roadmap to the shared workspace.
• Create mitigation tasks for any identified SME single-point-of-failure risks and schedule knowledge-transfer sessions.
• Define measurable acceptance criteria for each improvement initiative for tracking in the next quarterly reviews.
• Deployment checklist items required for stable operations are confirmed complete or have named owners and dates.
• All high-impact blockers are logged with owners and target resolution dates.
• Communication plan defined for any user-impacting issues discovered in hypercare.
• Publish the post-go-live checklist status and outstanding blocker list to the shared workspace within 24 hours.
• Execute agreed remediation tasks and report progress in the shared channel twice weekly until closed.
• Confirm monitoring alerts thresholds and update runbooks for any newly discovered failure modes.
• Create and assign remediation tasks in the tracker with clear acceptance criteria and target dates.
• Present first measurement data
• A clear list of root causes for each metric gap is agreed and documented.
• Corrective actions with owners and completion dates are assigned and scheduled into the shared tracker.
• Timeline to the next acceptance milestone is confirmed in writing and linked to the Operational Proof of Concept targets.
• Upload the detailed ticket-level analysis that supports the RCA findings to the shared workspace within 48 hours.
• Schedule a focused working session for any high-complexity remediation requiring configuration or third-party coordination.
• Present 90-day SLA performance
• SLA performance is documented and any shortfalls have remediation plans with owners and dates.
• Incumbent system decommissioning status and data archive completion are confirmed and recorded.
• A short list of residual operational risks is agreed with mitigation owners and re-review dates.
• Document incumbent decommissioning proof points and archive receipts in the shared workspace.
• Deployment and environment validation
• Persistent issues and root-cause status
• Continuous-improvement program outcomes
• Review root-cause quality and RCA examples
• Diagnose root causes for gaps
• Knowledge retention and SME coverage
• Agree corrective actions and owners
• Incumbent retirement and data handling
• Early adoption and usage signals
• Enhancement requests and backlog grooming
• Blockers and open issues with owners
• Outstanding remediation and acceptable risk
• Continuous improvement items implemented
• Annual improvement roadmap and next steps
• Confirm timeline to operational acceptance gate
• Agree immediate remediation actions