IT support and help desk operations

In short

IT support and help desk operations is the discipline of receiving, recording, diagnosing and resolving user-reported IT issues within agreed time limits, and of preventing their recurrence. It is organised around the ITIL service-management framework: incidents, service requests, problems, changes, assets and a knowledge base, all tracked in a ticketing (ITSM) tool. This matters commercially because Indian IT services firms (TCS, Infosys, Wipro, HCLTech, Tech Mahindra, Cognizant, Accenture, Capgemini, IBM, Concentrix) employ the largest share of fresh B.E./B.Tech graduates in exactly these roles, and selection is through aptitude plus a technical round on networking basics, Windows/AD, SLA arithmetic and scenario handling. Universities examine it under IT Infrastructure Management / IT Service Management papers; GATE does not test it directly, but ITIL 4 Foundation, CompTIA A+ and Microsoft/Red Hat certifications do.

Explained

Service desk structure and support tiers

• Help desk vs service desk: a help desk is reactive and fix-focused (break-fix); a service desk is the single point of contact (SPOC) for the whole service lifecycle - incidents, requests, information, access and change co-ordination.
• L0 - self-service: knowledge base articles, FAQ portal, password self-service reset, chatbot. Cheapest channel; target is to deflect 20-40% of contacts.
• L1 - first line: logs every contact, verifies identity, follows scripted checks, resolves known issues (password reset, mailbox full, printer queue, VPN re-connect, software re-install). Measured on First Contact Resolution (FCR) and call handling time.
• L2 - second line: technical specialists by tower - Windows/AD, network, database, messaging, endpoint. Does hands-on diagnosis and configuration.
• L3 - third line / SME: engineering, product or vendor-facing; code fixes, firmware, architecture changes. L4 is commonly used for OEM/vendor support (Microsoft, Cisco, Dell, Oracle).
• Dispatch vs touch model: "dispatch" desks only route tickets; "touch" desks attempt resolution. Touch models cost more per agent but cut MTTR.
• Support shapes: *onsite/desk-side* (hands and feet), *remote*, *follow-the-sun* (24×7 handoff across geographies - Indian delivery centres typically cover the EMEA and US night shifts), *shared service centre* (captive, e.g. a bank's own GCC) vs *outsourced*.

The ITIL practices examined

• ITIL 4 (current version, replaced ITIL v3's 26 processes with 34 practices and a Service Value System; the old v3 lifecycle stages - Strategy, Design, Transition, Operation, CSI - are still asked in many Indian university papers).
• Incident management: restore normal service as fast as possible. An incident is an unplanned interruption or quality reduction. Priority is fixed from impact × urgency, not from who shouted loudest.
• Service request management: a pre-approved, routine, low-risk ask (new laptop, software licence, access rights). Flows through a request catalogue with standard approvals - it is *not* an incident.
• Problem management: finds the root cause of one or more incidents. A known error is a documented root cause with a workaround; it lives in the Known Error Database (KEDB).
• Change enablement: standard change (pre-authorised, e.g. patching), normal change (goes to CAB - Change Advisory Board), emergency change (ECAB). Every change needs a rollback plan and a change window.
• Service level management: SLA (provider ↔ customer), OLA (internal team ↔ internal team), UC/underpinning contract (provider ↔ vendor). An SLA can never be met if the underlying OLAs and UCs are weaker.
• Asset and configuration management: CMDB holds configuration items (CIs) and their relationships; ITAM tracks ownership, warranty, AMC and licence compliance; SAM prevents under-licensing.
• Continual improvement: trend the top ticket drivers monthly and remove them (shift-left: L2 work pushed to L1, L1 work pushed to L0).

Ticket lifecycle, priority and escalation

1. Detection and logging: channel = phone, email, self-service portal, walk-in, chat, or automated monitoring alert. Every contact gets a ticket ID - "no ticket, no work".
2. Categorisation: service/CI + symptom code. Wrong categorisation is the single biggest cause of bad reporting and misrouting.
3. Prioritisation: priority = f(impact, urgency) from the priority matrix; this drives the response and resolution clocks.
4. Initial diagnosis: identity verification, KB search, scripted checks, remote session (RDP, SCCM/Intune remote, AnyDesk, TeamViewer).
5. Functional escalation (sideways, to a more skilled team) vs hierarchical escalation (upwards, to a manager, for authority, money or exception approval). Students regularly confuse the two.
6. Resolution and recovery: apply fix or workaround; confirm with the user that service is actually restored.
7. Closure: user confirmation, resolution code, KB article updated if new, CSAT survey triggered. Auto-closure after a stated pending-with-user period (commonly 3 working days) must be disclosed in the SLA.
8. Reopen rules: a ticket reopened within the reopen window usually reverts to the original SLA clock - a common contractual trap.
9. States: New → Assigned → In Progress → Pending (user/vendor/parts) → Resolved → Closed; Cancelled. Pending/clock-stop rules decide whether waiting time counts against the SLA.
10. Major incident: a severity-1 event with wide business impact; triggers a bridge call, an incident commander, periodic business communication and a post-incident review (PIR) with an RCA report, typically in 24-48 hours.

SLA metrics and measurement

• Response time: first meaningful human response. Resolution time: service restored. Both measured only inside service hours (e.g. 9×5×5, 24×7) unless the contract says calendar hours.
• MTTR (mean time to repair/restore), MTTA (acknowledge), MTBF (between failures), MTTD (detect).
• FCR / FTF: resolved on the first contact without escalation. Abandon rate, ASA (average speed of answer), AHT (average handle time = talk + hold + after-call work), service level (e.g. 80/20 - 80% of calls answered in 20 seconds).
• Backlog / ageing, reopen rate, SLA compliance %, CSAT (satisfaction score), NPS, cost per ticket.
• Erlang C staffing: the help desk is a queue, so agents needed depend on call arrival rate, AHT and the answer-speed target, plus a shrinkage allowance (leave, breaks, training - typically 25-35% in Indian BPO practice).
• Penalties and earn-back: Indian managed-services contracts commonly put 5-15% of monthly service charges at risk, with service credits for breaches. Exact figures are contract-specific.

Common technical resolutions a fresher must know

• Identity/access: password reset and unlock in Active Directory, group membership, MFA re-enrolment, SSO failure, account lockout source tracing (event ID 4740 on the DC).
• Connectivity triage (bottom-up): cable/Wi-Fi link → IP configuration (ipconfig /all, APIPA 169.254.x.x means no DHCP) → gateway ping → DNS (nslookup) → proxy/VPN → application.
• Endpoint: blue screen and event log reading, disk space, driver rollback, slow boot (startup apps), profile corruption, OS re-image via SCCM/Intune/MDT.
• Mail: Outlook profile rebuild, OST corruption, mailbox quota, autodiscover, spam/quarantine release.
• Print: spooler restart, driver mismatch, queue clear, network printer IP change.
• Remote and patching tools: RDP, SSH, Intune/SCCM, WSUS, antivirus/EDR console.
• Data protection duty: never ask for a user's password; verify identity before any reset; log what was accessed. Under India's Digital Personal Data Protection Act, 2023 the employer is a *data fiduciary* and the support agent handles personal data on its behalf - breach reporting to the Data Protection Board is mandatory from 13 May 2027 (until then IT Act s.43A and the SPDI Rules 2011 govern). CERT-In's 2022 directions require reporting specified cyber incidents within 6 hours and retention of ICT logs for 180 days. The DPDP Rules were notified in 2025 with phased commencement, so check the current compliance dates before quoting them.
• Other frameworks referenced in Indian contracts: ISO/IEC 20000-1 (service management), ISO/IEC 27001 (information security), COBIT (governance), and IS/ISO/IEC standards adopted by BIS for both.

Tools, ticket hygiene and soft skills

• ITSM platforms: ServiceNow (dominant in Indian enterprise), BMC Helix/Remedy, Ivanti, Jira Service Management, Freshservice and Zoho Desk (both Indian products), ManageEngine ServiceDesk Plus (Zoho), osTicket/GLPI (open source).
• Adjacent stacks: monitoring (Nagios, Zabbix, SolarWinds, Datadog), CTI/telephony and IVR, chatbots and AIOps for auto-triage, RPA for repetitive requests.
• Ticket hygiene: every update timestamped and in the ticket (not in chat or memory), reproducible steps, actual error text pasted, resolution written so the next agent can reuse it.
• Call handling: acknowledge → verify identity → active listening → paraphrase the issue → set expectations with a time commitment → do not blind-transfer → confirm before closing.
• Communication during an outage: state what is affected, what is being done, the next update time; never speculate on cause to the business.
• Shift operations: rosters, warm handover notes, on-call/pager rotation, night-shift transport and safety obligations for the employer. From 21 November 2025 the four Labour Codes are in force (Code on Wages; Industrial Relations; Social Security; Occupational Safety, Health and Working Conditions - the OSH Code replacing the Factories Act and related laws); night-shift work by women is permitted with consent and prescribed safety conditions, with details set by state rules.

Key points

• Service desk - single point of contact for all IT; a help desk is only break-fix.
• Incident - unplanned interruption; goal is fastest restoration, not root cause.
• Problem - the underlying cause of incidents; goal is permanent elimination.
• Service request - pre-approved routine ask from a catalogue; never logged as an incident.
• Priority = impact × urgency - impact is how many/how much business is hit, urgency is how fast it must be fixed.
• Functional escalation - sideways to greater skill; hierarchical escalation - upwards to greater authority.
• SLA / OLA / UC - customer-facing, internal-team, and vendor-facing commitments respectively.
• Workaround - temporary restoration; a known error is a documented cause plus workaround in the KEDB.
• MTTR - mean time to restore; FCR - share resolved at first contact without escalation.
• AHT - talk + hold + after-call work, the basis of staffing calculations.
• Shrinkage - the fraction of paid agent time unavailable for calls (leave, breaks, training).
• CMDB - database of configuration items and their relationships; underpins impact analysis.
• Change types - standard (pre-authorised), normal (CAB approved), emergency (ECAB).
• Major incident - high-severity, wide-impact event with bridge call, incident commander and a PIR/RCA.
• Shift-left - move resolution to a cheaper tier (L2→L1→L0 self-service) to cut cost per ticket.
• Service level 80/20 - 80% of calls answered within 20 seconds; distinct from resolution SLA.
• CERT-In 6-hour rule - specified cyber incidents must be reported within six hours of noticing.
• DPDP Act, 2023 - governs personal data handled by support staff; employer is the data fiduciary.

Formulas and examples

Example 1 - SLA compliance and the breach count. A desk closed 4,250 tickets in October; 3,910 met the resolution target.

• Compliance = 3,910 ÷ 4,250 × 100 = 92.0%.
• Contracted target is 95%, so breaches allowed = 5% × 4,250 = 212.5 → 212 tickets. Actual breaches = 4,250 − 3,910 = 340, i.e. 128 tickets beyond tolerance.
• To reach 95% the desk needed 0.95 × 4,250 = 4,037.5 → 4,038 tickets within target.

Example 2 - MTTR in service hours vs calendar hours. P2 ticket logged Friday 16:30, resolved Monday 11:30. Service hours 09:00-18:00, Monday-Friday.

• Calendar elapsed = Fri 16:30 → Mon 11:30 = 67 hours.
• Service hours: Friday 16:30-18:00 = 1.5 h; Saturday and Sunday = 0; Monday 09:00-11:30 = 2.5 h. Total = 4.0 hours.
• Against a 6-hour P2 resolution SLA the ticket is met on service hours and breached on calendar hours - which is why the service-hours definition must be in the contract.

Example 3 - Availability, allowed downtime and MTTR. A service promises 99.9% availability in a 30-day month.

• Period = 30 × 24 × 60 = 43,200 minutes. Allowed downtime = 0.001 × 43,200 = 43.2 minutes.
• Four outages occurred, totalling 96 minutes → MTTR = 96 ÷ 4 = 24 minutes; downtime 96 min → availability = (43,200 − 96) ÷ 43,200 × 100 = 99.778% - the SLA is breached.
• Uptime = 43,104 min over 4 failures → MTBF = 43,104 ÷ 4 = 10,776 minutes (about 179.6 hours).

Example 4 - AHT, staffing and shrinkage. A desk takes 1,800 calls in a 9-hour shift. Talk 240 s, hold 30 s, after-call work 90 s per call. Shrinkage 30%, occupancy 85%.

• AHT = 240 + 30 + 90 = 360 s = 0.1 hour.
• Workload = 1,800 × 360 ÷ 3,600 = 180 agent-hours.
• Productive hours per agent = 9 × (1 − 0.30) × 0.85 = 9 × 0.595 = 5.355 h.
• Agents = 180 ÷ 5.355 = 33.6 → 34 agents rostered. (Erlang C would add a small extra margin for arrival randomness at a tight answer-speed target.)

Example 5 - Cost per ticket and the shift-left business case. Monthly desk cost ₹18,00,000 for 12,000 tickets closed.

• Cost per ticket = 18,00,000 ÷ 12,000 = ₹150.
• Password resets are 2,400 tickets/month. Self-service deflects 70% = 1,680 tickets. If 85% of a ticket's cost is agent effort, saving = 1,680 × 150 × 0.85 = ₹2,14,200 per month (₹25.7 lakh a year) against a one-time portal cost - a standard payback argument in Indian managed-services bids.

(These targets are illustrative - every contract defines its own matrix and service hours.)

Where it is used

• IT services and BPM: TCS, Infosys, Wipro, HCLTech, Tech Mahindra, Cognizant, Accenture, Capgemini, LTIMindtree, Concentrix - global service desks run from Chennai, Pune, Hyderabad, Bengaluru, Noida, Kolkata and tier-2 cities, on follow-the-sun rosters.
• Captive GCCs and internal IT: banks and insurers (SBI, HDFC, ICICI), telecom (Jio, Airtel), manufacturers, hospitals - internal desks supporting thousands of employees, audited under ISO/IEC 20000-1 and ISO/IEC 27001.
• Government and public digital infrastructure: NIC and state e-governance desks, GSTN and Income Tax e-filing helpdesks, UIDAI/Aadhaar and UMANG support, railway and PSU desks - usually tender-driven with contractual SLAs and penalties.
• Product and SaaS technical support: Zoho, Freshworks, Tally, Razorpay, Postman - L1/L2 product support, often with escalation into engineering.
• Job roles and pay: Service Desk Analyst, Technical Support Engineer, Desktop Support Engineer, NOC/Monitoring Analyst, Incident/Change Manager, Site Reliability-adjacent support. Entry pay commonly ₹2.5-4.5 lakh a year, more on 24×7 international voice processes; ranges vary by city, employer and year.
• Credentials that get interviews: ITIL 4 Foundation, CompTIA A+/Network+, Microsoft certifications (Azure/Endpoint Administrator), CCNA, RHCSA, plus platform-specific ServiceNow certification.

Interview questions

• Q: What is the difference between an incident and a problem? A: An incident is an unplanned interruption to service and is handled to restore it quickly, often with a workaround; a problem is the underlying cause of one or more incidents and is handled to eliminate it permanently.
• Q: How is ticket priority decided? A: From a priority matrix combining impact (how much of the business is affected) and urgency (how quickly it must be fixed) - not by the caller's seniority, though VIP or business-critical users may be defined as high impact in the SLA.
• Q: Differentiate functional and hierarchical escalation. A: Functional escalation moves the ticket sideways to a team with more technical skill; hierarchical escalation raises it up the management chain for authority, budget, exception approval or customer communication.
• Q: Difference between SLA, OLA and UC? A: The SLA is the commitment to the customer; OLAs are internal agreements between support teams supporting that SLA; underpinning contracts are agreements with external vendors. If OLAs or UCs are weaker than the SLA, the SLA is structurally unachievable.
• Q: A user says "the internet is down." Walk me through your triage. A: Confirm scope (one user or many - many means an incident, not a desktop issue), check physical link, then ipconfig /all for a valid IP and gateway, ping gateway and a public IP, test DNS with nslookup, then proxy/VPN and finally the browser or application; escalate to network at the layer that fails.
• Q: What does 169.254.x.x on a user's machine tell you? A: It is an APIPA self-assigned address, meaning the client could not reach a DHCP server - check cabling/switch port, the DHCP scope and VLAN, then release/renew.
• Q: If you cannot resolve a ticket within SLA, what do you do? A: Escalate before the breach, not after; update the ticket and inform the user with a revised time commitment, record the reason for the delay, and tag it for SLA reporting - hiding an impending breach is worse than the breach.
• Q: Why is first contact resolution important, and what is its risk? A: It cuts cost per ticket and improves CSAT; the risk is agents closing tickets prematurely or wrongly to protect the metric, which shows up as a high reopen rate - so FCR is always read with reopen rate.
• Q: What is a known error and a workaround? A: A known error is a documented problem with an identified root cause for which no permanent fix is yet deployed; its workaround is the documented interim step that restores service, held in the KEDB for reuse by L1.
• Q: A caller claims to be a manager and asks for a colleague's password. What do you do? A: Refuse - passwords are never disclosed or known to the desk. Verify the requester's identity, and route any legitimate access need through the access-request workflow with the data owner's approval; log the attempt as a possible social-engineering incident.
• Q: What happens in a major incident? A: A severity-1 is declared, a bridge call and incident commander are set up, business communications go out at fixed intervals, the fix or workaround is applied, and after restoration a post-incident review produces an RCA and preventive actions through problem and change management.
• Q: How do emergency changes differ from normal changes? A: Emergency changes bypass the full CAB and are approved by an ECAB (or a nominated authority) to restore or protect service, but they still need a rollback plan and must be documented retrospectively in the next CAB.
• Q: What is the difference between MTTR and MTBF, and which does the business feel? A: MTTR is the average time to restore after a failure; MTBF is the average time between failures. Users feel MTTR during an outage, but availability depends on both - availability = MTBF ÷ (MTBF + MTTR).

Common mistakes

• Mixing up incident, problem, service request and change - the most common exam and interview slip; a repeated incident is still an incident until a problem record is raised.
• Computing SLA or MTTR in calendar hours when the contract specifies service hours, or ignoring pending/clock-stop time.
• Prioritising by caller designation rather than the impact-urgency matrix, and then having no defensible basis in the SLA review.
• Working a ticket "quickly" over chat or a call and updating it later or never - undocumented work is unprovable work and destroys reporting and KB reuse.
• Treating a workaround as a resolution and closing it without raising a problem record, so the same incident recurs monthly.
• Forgetting shrinkage and occupancy in staffing sums, which understates headcount by roughly a third.
• Resetting a password or granting access without verifying identity, or asking a user for their password - a security and DPDP compliance failure, not just poor practice.

Related topics

Network administration and troubleshooting · Windows Server and Active Directory · Data centres, storage and backup · TCP, UDP, HTTP and DNS · IT governance and information security management (ISO/IEC 27001) · Cloud and endpoint management (Intune, Azure AD)