Back to blog
FILE 0xF5·THE THING BLOCKING AI ADOPTION IN MSPS: NOBODY WANTS TO WRIT

The thing blocking AI adoption in MSPs: nobody wants to write the configuration

June 12, 2026 · nightdesk, msp, saas, python, claude, ai

Every time I demo NightDesk to an MSP owner, the conversation goes the same way.

"This is exactly what I need for after-hours calls."

"How long does setup take?"

"You configure one runbook per customer — it's a YAML file with their systems, escalation rules, and any context the AI needs to know."

"Oh. So I have to write... one of those for each of my 50 clients?"

That's when the energy drops. Not because they don't want the product. Because the activation cost just got large.


The runbook problem

NightDesk's runbook format is genuinely simple. Each one is about 30-40 lines of YAML covering:

Writing one takes 15-20 minutes if you know the customer well. Writing 50 takes a week of time you don't have.


The new endpoint

The /admin/generate-runbook endpoint takes a JSON payload with company context and returns a ready-to-review runbook YAML.

Input:

{
  "company_name": "Acme Manufacturing",
  "industry": "manufacturing",
  "known_systems": ["Sage 100 ERP", "SonicWall TZ-470", "Windows AD"],
  "escalation_name": "tim@msp.example",
  "escalation_method": "sms",
  "business_hours": "Mon-Fri 7a-5p CT",
  "notes": "Two buildings, 200 employees. Owner is on-site daily."
}

Output (abbreviated):

customer_name: Acme Manufacturing
business_hours: Mon-Fri 7a-5p CT
known_systems:
  - Windows AD (DC: ACME-DC01)
  - Sage 100 ERP (on ACME-APP01)
  - SonicWall TZ-470 (edge firewall)
  - Brother MFC-L2710DW printer (common call)
escalation_rules:
  - trigger: "ERP down or login fails across multiple users"
    page: tim@msp.example
    method: sms
  - trigger: "site-wide network outage or internet down"
    page: tim@msp.example
    method: sms
  - trigger: "security incident or ransomware indicators"
    page: tim@msp.example
    method: sms
out_of_scope_phrases:
  - billing
  - renewal
  - equipment purchase
extra_context: |
  Manufacturing floor has equipment tied to the Sage ERP server.
  If Sage goes down during production hours, it directly stops
  the line — treat these as P1. Owner is typically on-site and
  reachable for major incidents.

The engineer reviews, adds anything Haiku missed, uploads to S3, and moves to the next customer. A 20-minute manual task becomes a 3-minute review.


How the prompt engineering works

The system prompt is specific about what makes a good runbook versus what makes noise:

The output is deterministic enough to be useful but flexible enough to be customized.


What this changes for pilot onboarding

The NightDesk pilot path used to look like this:

  1. MSP owner agrees to pilot
  2. Chester (or eventual Chester equivalent) manually writes runbooks for 3-5 test customers
  3. Owner reviews, changes escalation contacts, goes live

Step 2 was the bottleneck. It required knowing the customer well enough to write a sensible runbook — which Chester doesn't, but the MSP does.

Now it's:

  1. MSP owner agrees to pilot
  2. Owner fills out a quick form (company name, industry, main systems, escalation contact)
  3. Generator produces a draft in under 2 seconds
  4. Owner reviews the YAML for 3 minutes, fixes anything wrong, uploads
  5. Goes live

The activation cost drops from "2-hour side project" to "20-minute onboarding session." That's the difference between a pilot that gets done and a pilot that stays on the backlog.


NightDesk is AI-powered after-hours call triage for MSPs. Learn more at nightdesk.io — currently accepting pilot partners.