Customer Support

How to build a customer knowledge base as Small IT and ITOps Teams

Customer SupportFor Small IT and ITOps Teams2 apps12 steps~24 min to set up

Your Notion runbook hasn't been touched since Q3. The answer to 'how do I request a new SaaS license' lives in a Slack thread from eight months ago, a Google Doc nobody can find, and your own memory. When a new hire joins, you spend 45 minutes walking them through things that should be written down. When someone leaves, you spend another hour figuring out what access they had because there's no single source. You have Jira for tickets, Notion for docs, and Slack for everything else — none of it connected. The knowledge base isn't missing because you don't care. It's missing because building and maintaining one takes time a two-person IT team doesn't have.

Build this on Starch → See the apps used

Customer SupportFor Small IT and ITOps Teams2 apps12 steps~24 min to set up

Outcome

What you'll set up

A searchable internal knowledge base that pulls from your existing Notion pages, Jira tickets, and documentation — so your team stops being the first line of every answer

An AI layer that detects stale docs, surfaces the right article when a new Jira ticket comes in, and suggests updates when procedures change

An onboarding path generator that turns your existing runbook content into structured checklists for new hires, tied to the actual systems they'll use

The Starch recipe

Apps, data, and prompts

The combination of Starch apps, the data sources they pull from, and the prompts you use to drive them.

Apps used

Knowledge Management Customer Support Agent

Data sources & config

Notion is connected as a scheduled-sync provider — Starch syncs your Notion pages and databases on a schedule so KB content is always current. Jira is connected from Starch's integration catalog; the agent queries it live when a ticket comes in to match it against existing articles. Slack is also reachable from the integration catalog for surfacing KB answers directly in channels. Any internal portal or vendor documentation site that doesn't have an API can be automated through your browser — no API needed.

Prompts to copy

Connect my Notion workspace and pull all pages tagged 'IT', 'onboarding', or 'runbook' into a searchable knowledge base. Flag any page that hasn't been edited in 90 days as potentially stale.

When a new Jira Service Management ticket comes in that matches a known issue in the knowledge base, surface the relevant article to the requester automatically and log whether they resolved it without escalating.

Build me an onboarding checklist app that takes a new hire's role and start date, pulls the relevant KB articles, and generates a day-by-day task list covering SSO setup, software provisioning, and security policy acknowledgment.

Run these in Starch → or paste them into your favorite agent

Walkthrough

Step-by-step

1 Connect your Notion workspace to Starch. Starch syncs your Notion pages on a schedule, so your existing runbooks, SOPs, and IT policies become the seed content for the knowledge base without any manual migration.

2 Connect Jira from Starch's integration catalog so the agent can query open tickets, ticket categories, and resolution history live when building or updating KB articles.

3 Tell Starch: 'Build me a knowledge base from my Notion IT pages. Group articles by category: onboarding, offboarding, access requests, hardware, and security. Flag anything last edited before 90 days ago.' Starch assembles the surface.

4 Review the auto-generated article list. For gaps — procedures that exist only in someone's head or old Slack threads — use the prompt: 'Create a draft article for our VPN setup process based on the steps in this Jira ticket thread [link].'

5 Set up the staleness detector: 'Every Monday, check which KB articles reference tools or policies that have changed in Jira or Notion in the past 30 days, and surface them for review.' This runs as a scheduled automation.

6 Wire the ticket-deflection layer: 'When a new Jira ticket is created with labels like password-reset, software-request, or VPN-issue, check the knowledge base for a matching article and post the link as a comment before the ticket is assigned.'

7 Build the onboarding path generator: 'Create an app where I enter a new hire's name, role, and start date. The app pulls the relevant onboarding KB articles, generates a checklist, and creates a Jira epic with subtasks for each step.' This replaces the ad-hoc Google Doc you currently send.

8 Set up the offboarding mirror: 'Build a checklist app for offboarding that pulls our standard access-revocation checklist from the KB, creates Jira tasks for each system, and marks each complete when the Jira task closes.'

9 Add a Slack integration: connect Slack from Starch's integration catalog and set up an automation — 'When someone asks a question in #it-help that matches a KB article title or keyword, reply with the article link automatically.'

10 For any vendor portals or carrier documentation sites without APIs — say, pulling updated MDM policy docs from Jamf's web portal — Starch automates that through your browser so the KB stays current without manual downloads.

11 Schedule a monthly audit automation: 'On the first Monday of each month, list all KB articles not accessed in 60 days and all articles flagged stale but not updated. Post the list to #it-team in Slack.' Keeps the KB from rotting.

12 When the Customer Support Agent launches (currently in development — request beta access), you'll be able to route employee IT questions directly to an AI agent that answers from your KB before a human ever sees the ticket.

See this running on Starch

Connect your tools, describe what you want, and the agent builds it. Closed beta is free.

Try it on Starch →

Worked example

New hire onboarding — March 2026, 14 employees joining same week

Sample numbers from a real run

Onboarding tickets created in Jira (manual, pre-Starch)	168
Tickets auto-resolved via KB article deflection	94
Minutes saved per deflected ticket (avg)	22
Stale KB articles flagged and updated before onboarding week	11
IT team hours spent on onboarding questions (down from 19)	5

Fourteen new hires starting in the same week used to mean 14 onboarding Slack threads, 14 variations of the same VPN setup question, and two IT people spending most of Monday and Tuesday fielding requests. This time, the Starch knowledge base had been running for six weeks. Starch had synced all 43 IT-tagged Notion pages, flagged 11 as stale (two referenced a deprecated MDM profile), and the team updated them before the cohort arrived. When onboarding started, the Jira ticket deflection automation intercepted 94 of 168 tickets — password reset flows, Google Workspace provisioning questions, Zoom license requests — and posted the relevant KB article before any human saw the ticket. 67 of those resolved without escalation. The IT team spent 5 hours on onboarding support that week instead of 19. The onboarding checklist app generated a personalized Jira epic for each new hire, broken down by role, so the team wasn't recreating checklists from memory for the engineering cohort versus the ops cohort.

Measurement

How you'll know it's working

Ticket deflection rate: percentage of Jira Service Management tickets resolved via KB article without human response

KB staleness rate: percentage of articles flagged as >90 days without edit, reviewed monthly

Mean time to onboard: hours from start date to full system access, tracked per cohort

Repeat ticket rate: how often the same question generates a new ticket in a 30-day window (measures KB coverage gaps)

Article-to-ticket coverage: number of distinct ticket categories with at least one current KB article

Comparison

What this replaces

The other ways teams handle this today, and how the Starch version compares.

Notion alone

Great for writing docs, but no ticket integration, no staleness detection, no auto-surfacing — you still have to tell people it exists and hope they search before Slacking you.

Confluence + Jira (Atlassian native)

Native Jira integration is real, but Confluence is slow to maintain, has no AI staleness detection, and the search is notoriously bad — you'll still get the same 'I couldn't find it' tickets.

Guru or Tettra

Purpose-built knowledge base tools with verification workflows, but they don't connect to your Jira ticket stream or Notion content without manual migration, and they add another SaaS seat to manage.

SharePoint / Microsoft 365 wiki

Already in your stack if you're on Microsoft, but building the Jira connection, ticket deflection logic, and staleness automation on top requires dev work Starch handles with a natural-language prompt.

On Starch RECOMMENDED

One platform — knowledge management, customer support agent all running on connected data. Setup in plain English; numbers stay current via scheduled syncs and live agent queries.

Try it on Starch →

FAQ

Frequently asked questions

We already have Notion. Why not just use that as the knowledge base?

Notion is where the content lives. Starch is what connects it to where work actually happens — your Jira ticket queue, your Slack channels, your onboarding workflows. Without the connection layer, your Notion docs are only useful to people who already know they exist and know how to search them. Starch syncs your Notion content on a schedule and surfaces it automatically at the moment someone needs it.

Does Starch replace our Jira Service Management setup?

No. Jira stays your ticketing system. Starch connects to it from the integration catalog and adds the KB deflection layer on top — when a ticket comes in, Starch checks the knowledge base and posts a relevant article as a comment. Your existing Jira workflows, SLAs, and queues are untouched.

What happens to KB articles that reference tools we've deprecated?

The staleness automation flags articles based on edit date and cross-references them against changes in your connected systems. You define the rules — 'flag anything older than 90 days' or 'flag any article that mentions a tool whose Jira project has been archived.' Starch doesn't delete or update articles automatically; it surfaces them for human review.

We use Jamf and Okta. Can Starch pull data from those for the KB?

Jamf and Okta are reachable from Starch's integration catalog — the agent queries them live when your app needs that data. You can build KB articles that reference live device inventory from Jamf or active application assignments from Okta, so your access-request docs always reflect what's actually provisioned. For Jamf or Okta admin portals with web-based configuration that doesn't have a clean API endpoint, Starch can automate those through your browser.

Is Starch SOC 2 certified? Our IT policy requires it for tools that touch employee data.

Starch is not SOC 2 Type II certified today. That's a real constraint worth naming if your org has a hard requirement on that. It's on the roadmap. For an internal IT knowledge base that syncs Notion docs and queries Jira tickets, your risk exposure is lower than a tool handling customer PII — but check with your security lead before connecting anything sensitive.

What about the Customer Support Agent I saw mentioned — can that handle employee IT questions?

Customer Support Agent is currently in development. When it launches, it will be able to handle common employee IT questions — password resets, access requests, software install steps — using your KB as the source of truth, 24/7, before a ticket ever gets routed to your team. You can request beta access now to get notified when it's available. In the meantime, the Jira ticket deflection automation covers a lot of the same ground.

We don't have time to build and maintain a knowledge base. Isn't this just creating more work?

The honest answer: the first week has some setup work — connecting Notion, reviewing the auto-generated article list, updating the 11 stale docs it flags. After that, the maintenance is mostly automated. Staleness detection, ticket deflection, and the Slack integration run on schedules you set. The knowledge base gets better passively as tickets come in and get resolved. The alternative is continuing to answer the same questions manually, which has a cost too — it just feels less visible than a setup task.