What it is (plain English)
The system your IT team uses when something breaks: a user reports it (or a monitoring tool detects it), the right team gets it, works it, and restores service as fast as possible. An "incident" is simply an unplanned interruption or degradation of a service — from "my laptop won't start" to "email is down for everyone."
Problems it solves
- Issues reported by email, chat, and hallway conversations get lost or forgotten.
- No visibility into what's broken, who's working on it, or how long fixes take.
- The same information is asked for over and over because nothing is recorded once.
- No numbers to show the business how IT support is actually performing.
What must exist first
Platform Core Setup is required — incidents route to groups of people, so users and support groups must exist. A CMDB is strongly recommended (it powers "what is affected?" and smarter assignment) but a lean incident process can go live before the CMDB matures.
What the customer needs to provide
- Your support team structure: which teams exist (service desk, network, apps…) and who is in them.
- How urgent is urgent: agreement on what counts as high/medium/low impact for your business.
- Your current intake channels (phone, email, walk-up, another tool) and which ones should feed ServiceNow.
- Response and resolution time targets, if you have them (formal or informal).
- A short list of your most common issue types — this seeds categories that make reporting useful.
Where it can go next
Major Incident Management adds a coordinated response process for the big outages; On-Call Scheduling gets the right person paged after hours; Problem Management stops repeat incidents at the root. Monitoring integration via Integration Foundation can create incidents automatically before users even call.