Scaling Support Processes ========================= Slide 1: Scaling Support Processes Narration Anna: Remember when founders personally reset Wi-Fi routers? That was charming at 10 people, but now it blocks product roadmaps. Greg: Exactly. We're here to show why scaling support is a strategic investment, not just cleaning up after everyone else. Anna: We'll move from chaos to a predictable service desk that earns trust from executives, auditors and customers alike. Greg: And we’ll do it without copying enterprise bureaucracy—this is about the minimum viable maturity that still scales. On-screen text Scaling Support Processes Evolving from founder-led fixes to a scalable service desk > "We've all been there—the company's 'IT department' is whoever sits closest to the router." Slide 2: When ad-hoc support stops working Narration Anna: First clue you’ve outgrown ad hoc support? Slack DMs turn into a roulette wheel of "Did anyone pick this up?" Greg: My other favorite—new hires shadow for a week because there’s no knowledge base, just tribal lore from the first sysadmin. Anna: Finance notices too. Without ticket data there’s no way to justify headcount or tool spend. Greg: And compliance folks get nervous when you can’t produce incident logs during a customer audit. That’s the burning platform for change. Anna: Meanwhile remote teammates wait overnight for laptop fixes because coverage lives in one time zone. On-screen text When ad-hoc support stops working - Slack pings overwhelm the one IT generalist and create invisible queues - Context lives in heads; onboarding a new hire takes days of oral history - Regulators and auditors ask for incident logs you can't produce - Customer-facing teams feel the pain first—every outage escalates straight to engineering - Remote teammates are stranded without time-zone coverage or device access policies - Picture this: It's 3 PM Friday, the CEO can't access email, and three teammates troubleshoot in parallel because there's no ticketing system Slide 3: Design the first help desk intentionally Narration Anna: The temptation is to just buy a tool, but the first step is designing intake and triage. Greg: Right—choose one doorway for tickets. Portal plus email alias, both feeding the same queue with required fields. Anna: Then define what "good" looks like: simple SLAs and an escalation ladder. Even a Trello board can work if the process is crisp. Greg: Daily standups make invisible work visible, and a weekly retro keeps the backlog honest. Tooling only amplifies that discipline. On-screen text Design the first help desk intentionally - Launch a single intake (portal + email) with auto-triage by request type - Publish lightweight SLAs: critical 2h, high 4h, normal 1 business day - Create macros for the top 20 requests; everything else routes to a backlog - Implement daily standups and a weekly ops review to surface blockers - Document remote/hybrid playbooks: shipping devices, break/fix couriers, regional on-call rotations Slide 4: Knowledge base as force multiplier Narration Anna: Knowledge bases fail when they become graveyards. We want a living system tied to ticket closure. Greg: Exactly—agents draft the article while the fix is fresh, and SMEs review it during their Friday hour of power. Anna: Short videos and annotated screenshots beat long prose for startup teams moving fast. Greg: And don’t forget analytics. Track search terms with zero results, then prioritize new content from that list. Anna: Once that foundation is in place, we can talk tooling choices that reinforce it instead of creating another content graveyard. On-screen text Knowledge base as force multiplier - Pair every resolved ticket with an article draft before closure - Use "seed, grow, prune" cycles: SMEs review monthly, archive stale pages quarterly - Embed short Loom walkthroughs—startups learn visually faster than reading PDFs - Track self-service deflection rate and article helpfulness to justify more authors - Take password resets: one article with screenshots can deflect 80% of those 10-a-day Slack pings Slide 5: Tooling choices: ServiceNow vs Jira Service Management Narration Anna: Let’s tackle the tooling debate. ServiceNow or Jira Service Management—what’s the difference in practice? Greg: ServiceNow shines when you need rigid workflows, integrated CMDB and audit-grade change control. But it demands budget and a specialist admin. Anna: Jira Service Management snaps into existing Atlassian workflows and ships with great automation and developer visibility. Greg: The trade-off? You may need marketplace apps for CMDB depth and more governance features. So we map regulatory needs, current stack, and admin skills before deciding. On-screen text Tooling choices: ServiceNow vs Jira Service Management - ServiceNow: enterprise-grade workflows, deep CMDB, strong audit trails; higher cost and implementation lift - Jira Service Management: native with Atlassian stack, faster to deploy, rich automation rules; needs add-ons for mature CMDB - Decision guardrails framework: - Current team size and 18-month growth trajectory - Existing ecosystem integrations and API/library maturity - Compliance or audit obligations (SOC 2, SOX, HIPAA) and segregation of duties - Available admin expertise and realistic implementation runway - Bridge gaps with integrations (e.g., Slack virtual agent, asset DB sync) before committing to a rip-and-replace Slide 6: Layer automation and integrations early Narration Anna: Tool choice settled, the next lever is automation. Otherwise the team becomes human routers. Greg: Start simple—Slack or Teams forms that capture device, urgency and screenshots, then auto-tag the ticket. Anna: Sync asset data from MDM nightly so agents trust the CMDB when troubleshooting. Greg: And hook the workflow engine to HR events so joiner, mover and leaver tasks fire automatically. That’s hours back every week. Anna: Wrap those flows with security checks—privileged access reviews and phishing simulations—so operations and security grow together. On-screen text Layer automation and integrations early - Connect Slack or Teams to create tickets with structured forms and context capture - Enforce change approvals and incident postmortems via workflow gates - Sync asset inventory (Intune, Kandji, Jamf) to the ITSM CMDB nightly - Automate onboarding/offboarding tasks with workflow engine + IDP events - Include security guardrails: privileged access reviews, phishing simulations, and incident response playbooks Slide 7: Staffing for maturity Narration Anna: Processes mean nothing without the right people at the right time. Greg: Stage one, under 50 staff, you likely have a single operations lead wearing every hat. Give them clear escalation paths into engineering. Anna: Stage two adds dedicated L1 agents and someone curating knowledge. Rotating product squads for L2 keeps context fresh. Greg: By stage three you need specialists—security, infrastructure, SaaS owners—and a service owner measuring CSAT and backlog health. On-screen text Staffing for maturity - Stage 1 (≤50 staff): one ops lead covering L1 + process design; rotate engineers for escalation duty - Stage 2 (50–150): dedicated L1 agents, part-time knowledge manager, on-call matrix with product squads - Stage 3 (150+): L2 specialists for infra/security/apps, service owner, tooling admin, CSAT analyst - Invest in career ladders and certification paths to retain institutional knowledge - "Stage 1 IT person: part technician, part therapist, part mind reader. At least give them proper escalation paths!" Slide 8: Process milestones to hit Narration Anna: Founders love roadmaps, so translate process maturity into month-by-month wins. Greg: Month one, document services and publish runbooks for the top incidents. Month two, launch the knowledge base and start change reviews. Anna: Month three brings problem management huddles and automated joiner/mover/leaver workflows. Greg: After that, quarterly service reviews with finance and product keep the desk aligned to business priorities and budgets. Anna: Call out failure modes at each stage so teams spot drift early—ownerless runbooks, ignored dashboards, automation without monitoring. On-screen text Process milestones to hit - Month 1: catalog services, define categories, publish runbooks for top incidents — failure mode: no owners assigned, so runbooks rot - Month 2: launch knowledge base, implement change calendar, start ticket QA program — failure mode: KB traffic untracked, execs lose faith - Month 3: introduce problem management reviews, automate joiner/mover/leaver flows — failure mode: automation breaks without monitoring - Month 4+: quarterly service reviews with finance/product, refresh tooling roadmap — failure mode: reviews drift into status theatre, not decisions Slide 9: Metrics that prove maturity Narration Anna: Metrics prove the desk is worth the investment. Without them, it’s just more overhead. Greg: Track response and resolution SLAs, but also self-service deflection—can at least a third of tickets resolve without human hands? Anna: CSAT surveys and article helpfulness scores show quality, while cost-per-ticket and engineering hours returned show business impact. Greg: Package those results into a monthly narrative so executives keep funding headcount and tooling improvements. Anna: With the numbers telling the story, our wrap-up can focus on reinforcing the habits that keep the desk evolving. Greg: And bring a simple ROI one-pager to budget reviews so leaders see the cost avoidance alongside the spend. On-screen text Metrics that prove maturity - Ticket intake mix: aim for ≥30% self-service deflection within six months - Responsiveness: 90th percentile response under SLA, backlog <1.5× weekly throughput - Quality: CSAT ≥4.5/5 and knowledge article helpfulness ≥80% - Business impact: downtime minutes prevented, engineering time saved, audit findings closed - Security: mean time to revoke access after offboarding and phishing report-to-response time Slide 10: Budget justification toolkit Narration Anna: Budget justification toolkit focuses attention on a concrete part of the work. Build a one-page ROI summary: tickets deflected, hours saved, compliance risks reduced, Include a lightweight CapEx/OpEx model (licenses, headcount, contractors) with 3-year outlook, and Tie asks to business OKRs and upcoming audits; include "do nothing" risk column. Greg: In practice, ask who owns the work, what evidence proves it happened, and what handoff comes next. Use the supporting details as a checklist: Include a lightweight CapEx/OpEx model (licenses, headcount, contractors) with 3-year outlook; Tie asks to business OKRs and upcoming audits; include "do nothing" risk column; Borrow customer quotes or incident anecdotes to humanize the spend. On-screen text Budget justification toolkit - Build a one-page ROI summary: tickets deflected, hours saved, compliance risks reduced - Include a lightweight CapEx/OpEx model (licenses, headcount, contractors) with 3-year outlook - Tie asks to business OKRs and upcoming audits; include "do nothing" risk column - Borrow customer quotes or incident anecdotes to humanize the spend Slide 11: Common implementation pitfalls (and how to avoid them) Narration Anna: So the playbook is simple: single intake, living knowledge base, right-sized tooling, and people who can grow with the process. Greg: Nail those and you turn IT from a fire brigade into a service your startup brags about in due diligence calls. Anna: Plus the metrics make future investments easier to pitch. Nothing beats saying, "We saved 200 engineering hours last quarter." Greg: Now let’s push the pilot live and iterate weekly. Momentum is your best stakeholder management tool. Anna: Keep an eye out for the classic pitfalls—tooling without process, dusty runbooks, and remote teams left out of the loop—and course-correct fast. On-screen text Common implementation pitfalls (and how to avoid them) - Tooling-first rollouts without process design → run a pilot with clear exit criteria - Ignoring change management → over-communicate via town halls, office hours, and exec sponsors - Skipping data hygiene → schedule quarterly CMDB and knowledge audits with metrics owners - Forgetting remote teammates → create follow-the-sun coverage and hardware depots in key regions Slide 12: Action checklist Narration Anna: Action checklist focuses attention on a concrete part of the work. [ ] Pick pilot team, map top 10 request types and pain points, [ ] Stand up intake, SLAs and runbook templates before announcing new process, and [ ] Select tooling with a weighted scorecard and run a two-week sandbox bake-off. Greg: In practice, ask who owns the work, what evidence proves it happened, and what handoff comes next. Use the supporting details as a checklist: [ ] Stand up intake, SLAs and runbook templates before announcing new process; [ ] Select tooling with a weighted scorecard and run a two-week sandbox bake-off; [ ] Review metrics weekly; adapt staffing and knowledge strategy every quarter. On-screen text Action checklist - [ ] Pick pilot team, map top 10 request types and pain points - [ ] Stand up intake, SLAs and runbook templates before announcing new process - [ ] Select tooling with a weighted scorecard and run a two-week sandbox bake-off - [ ] Review metrics weekly; adapt staffing and knowledge strategy every quarter