Core ITSM Modules
Incident, Service Request, Problem, Change, Release, and CMDB. Aligned to ITIL 4 vocabulary without the heavy ceremony some competitors impose. The modules share a common ticket data model, so a Service Request can convert to an Incident, an Incident can spawn a Problem, a Problem can drive a Change, and a Change can roll up into a Release — without re-keying data. The conversions preserve audit trails so a compliance auditor can trace incident-to-fix without spelunking. Modules are turned on per workspace; you don’t pay for what you don’t enable.
Incident Management
Tickets land via email, end-user portal, the Freshservice mobile app, the agent UI, the API, and integrations (Slack, Teams, monitoring tools like Datadog and PagerDuty). Assignment runs via the Workflow Automator on creation: route by category, by reporter group, or by skill. SLAs apply per priority with business-hours respect. Merge related tickets when a single underlying issue produces multiple reports — the merged-into ticket inherits all the requesters so notifications go to the right people.
// Create an incident from a monitoring webhook
fetch(`https://${domain}.freshservice.com/api/v2/tickets`, {
method: 'POST',
headers: { Authorization: auth, 'Content-Type': 'application/json' },
body: JSON.stringify({
email: '[email protected]',
subject: 'High CPU on db-prod-01',
description: 'CPU > 90% for 10 minutes',
priority: 3,
status: 2,
category: 'Infrastructure'
})
});Change Management
Risk-classified changes (Low / Medium / High) drive the approval path. Low risk auto-approves and goes straight to scheduling. Medium hits the change manager. High hits the Change Advisory Board. The classification is computed by a risk questionnaire (number of CIs touched, time of day, rollback plan completeness) — don’t let requesters self-classify, automate it. Integrate with monitoring so a failed change can trigger an automated rollback workflow that pages the original implementer.
Service Catalog
Request items model hardware, software access, role changes, onboarding bundles. Each item has a form (the requester fills out fields) and a fulfillment workflow (approval chain plus tasks for the fulfilling team). Hardware request fulfilment can be wired to a vendor punchout or to an internal stockroom workflow. The Workflow Automator handles the routing — no scripting required for 80% of patterns.
Freddy AI
Auto-categorization of incoming tickets, suggested resolutions surfaced from the KB and historical similar tickets, and similar-incident detection that proactively flags duplicates. The detection feature is the most underrated — a P1 ticket that’s actually the 14th report of an active outage gets clustered into a parent ticket so the on-call sees one signal, not 14. Reduces ramp time for new agents because the same suggestion that helps the bot also helps a junior agent.
Common Failure Modes
The three patterns that break ITSM rollouts. First, importing all six modules at once — adoption fails because no one team owns all six. Roll out Incident first, then Service Catalog, then Change, then Problem, then CMDB, then Release. Second, building the CMDB manually rather than from probes — manual data drifts and the CMDB becomes a fossil that change management cannot trust. Third, copying the previous tool’s category tree wholesale — most legacy ITSM trees have 200+ categories and three-quarters are dead branches; start with 20 and grow as needed.
Implementation Sequence
Month 1: Incident plus basic Service Catalog (top 10 items). Month 2: SLA Policies, Workflow Automator, and Freddy categorization. Month 3: Problem Management with one trial team. Month 4: Change Management with a small CAB. Month 5: CMDB Probe deployment in one region. Month 6: Release Management for a single product team. Sequential adoption is slow but sticks; parallel adoption is fast and falls over.
What to do this week
Audit the categories on your last 500 incidents. If 80% of tickets fall into 10 categories, kill the rest. The cleanup is the cheapest accuracy improvement available.
