How to Use the People, Process, Technology Framework to Diagnose Your IT Service Desk

An IT team spends six months evaluating IT Service Management (ITSM) platforms, builds the business case, gets budget approved, and completes the migration. Six months after go-live, tickets are still bouncing between tiers, agents are still re-solving the same problems from scratch, and end-users are logging the same complaints they were before the project started. The tool changed. The dysfunction didn't.

That outcome is almost always a misdiagnosis problem, not a technology problem. The People, Process, Technology (PPT) framework gives IT service desk leaders a structured root cause analysis approach for finding out which of the three pillars is actually failing before they commit budget and staff time to a fix. This guide covers how to apply PPT as a diagnostic tool, which questions reveal the real problem per pillar, and why the order you sequence your fixes matters as much as the fixes themselves.

ITSM Team Using People, Process, Technology Framework to Diagnose Service Desk

Key Takeaways

• Diagnose in order: Assess People first, then Process, then Technology. Fixing tools before stabilizing workflows almost always reproduces the same problems on a newer interface.
• Symptoms point to pillars: Low First Contact Resolution (FCR) typically signals a People or Process gap. Slow ticket intake points to Process. Poor self-service adoption points to Technology. Mapping symptoms to pillars before choosing a fix saves months of misdirected effort.
• PPT maps directly to ITIL and ITSM: ITIL (the internationally recognized IT service management guideline set) practices are the "Process" layer. IT Service Management (ITSM) platforms are the "Technology" layer. Trained IT staff are the "People" layer. A PPT assessment is, in practice, an ITSM maturity diagnostic.
• "Stable enough" is the threshold: Each pillar doesn't need to be perfect before you move to the next. It needs to be stable enough that adding structure or tooling won't reproduce the same failure at a different layer.

What Is the People, Process, Technology (PPT) Framework?

The People, Process, Technology (PPT) framework is a diagnostic and planning model that treats every operational problem as a symptom of imbalance across three interdependent pillars.

The framework has roots in the 1960s, when MIT management professor Harold Leavitt introduced what became known as Leavitt's Diamond Model. His original version covered four components, which he named people, structure, technology, and tasks. By the 1990s, structure and tasks had been consolidated into "process," and the familiar PPT triangle became the standard framing in business and IT management.

For IT service desks, the three pillars map directly to familiar ITSM concepts:

1. The Process pillar corresponds to your ITIL (the internationally recognized IT service management guideline set) practices, covering incident management, service request fulfillment, escalation paths, and knowledge management.
2. The Technology pillar covers your ticketing system, automation rules, self-service portal, and integrations.
3. The People pillar covers your agents, their training, their tier structure, and how well they know both the processes and the tools they're using.

When service desk performance falls short, the root cause almost always sits in one of these three areas, or in how they interact with each other.

3 PPT Categories of IT Service Desk Problems

Every chronic service desk problem can be grouped into one of three categories, corresponding to the PPT pillars. Think of the three pillars as legs of a stool. The structure fails whenever one is significantly weaker than the others, regardless of how strong the remaining two are. Identifying which category a symptom belongs to is the first step of a useful diagnostic:

1. People Problems

   People problems show up when the team itself is the limiting factor. This can mean the wrong number of agents for the ticket volume, agents who haven't been adequately trained on the most common ticket types, or experienced staff being retained poorly.

   Common symptoms include:

   • Tier 1 agents regularly handling tickets that should be escalated, or escalating tickets that should be resolvable at Tier 1
   • Inconsistent resolution quality across agents handling the same ticket type
   • High agent turnover, which continuously resets institutional knowledge
   • No one contributing to the knowledge base, so the same solutions are reinvented daily
   • Agent satisfaction scores declining, often a leading indicator of Customer Satisfaction (CSAT) problems

   People problems also tend to be localized. If an inconsistency shows up across the whole team, it's more likely a Process gap than a staffing or training issue. If it's concentrated in one tier, one shift, or one cohort, the People pillar is almost certainly the right place to look first.

2. Process Problems

   Process problems are often misidentified as technology problems because the symptoms look similar. Slow resolution times, tickets bouncing between groups, and users resubmitting issues that were never fully closed can all look like a tool failure. But when the root cause is in how work is structured rather than the tools used to track it, buying new software won't fix it.

   Common symptoms are:

   • Tickets categorized inconsistently on intake, which causes mis-routing and delays downstream
   • No defined escalation path for specific issue types, so agents make individual judgment calls with no consistency
   • Knowledge articles exist but aren't structured for agents to find quickly during a live ticket
   • No documented runbook or standard procedure for the top 20 ticket categories
   • Self-service exists on paper, but users aren't directed to it at the right moment in their issue journey

3. Technology Problems

   Technology problems occur when the tools don't support what the people and processes need them to do. This is less common than teams assume, but it's real. This is identified when well-defined processes break down specifically at the points where the tool is involved.

   Common symptoms include:

   • Agents manually routing tickets because the system can't apply routing logic automatically
   • No automation handling routine, repeatable requests that shouldn't require agent time
   • The self-service portal exists but users consistently bypass it, often because it's hard to find or the search doesn't return relevant articles
   • The ITSM platform was selected before current workflows were mapped, so the tool's built-in logic doesn't match how the team actually works
   • No integration between the ITSM tool and adjacent systems, forcing agents to context-switch and manually transfer information

Symptom-to-Pillar Quick Reference

Use this table to match what you're observing to the most likely root pillar before starting a deeper assessment:

How to Run a PPT Assessment of Your IT Service Desk

A PPT assessment isn't a one-time audit. It's a structured review that gives you a clear picture of which pillar is limiting performance right now, so you can direct your next fix at the actual problem.

One thing the steps below don't say explicitly is that data analysis works best when joined with direct input from agents. A 20-minute conversation with a team lead and two front-line agents per tier will often reveal which escalation paths are being quietly bypassed and where documented procedures have developed informal workarounds that ticket data won't capture. The diagnostic questions in Steps 3 through 5 can also be used as structured interview prompts:

• Step 1: Collect Your Service Desk Data

  The assessment starts with metrics, not opinions. Pull at least 90 days of data on the following:

  • First Contact Resolution (FCR) rate
  • Average Handle Time (AHT)
  • Mean Time to Resolve (MTTR) by ticket category and priority
  • Ticket volume by category and priority
  • Escalation rate and escalation path distribution
  • Customer Satisfaction Score (CSAT) and any open-text feedback
  • Ticket backlog age and distribution
  • Self-service portal usage and deflection rate
  • Agent utilization and workload distribution across the team

  Most ITSM platforms generate this data out of the box, but it's worth pulling it in a format you can filter by category, tier, and time period. Aggregate trends hide the detail you need. A high FCR rate averaged across all ticket types can mask a serious gap in one category that's driving most of the escalations and callbacks.

• Step 2: Match Symptoms to a Pillar

  With data in hand, look for patterns that point to a specific pillar. The table above is a starting point. The question you're trying to answer at this stage is narrow. Where exactly does the system break down? Not "everything is a bit slow," but "tickets in category X almost always get reassigned at least once, and the reassignment happens between Tier 1 and Tier 2."

  Some symptoms cross pillars, and that's worth acknowledging. Low FCR can reflect agents who haven't been trained (People), a knowledge base that agents can't search effectively during a live call (Process), or a ticketing system that buries the relevant resolution article three clicks deep (Technology). The symptom identification step narrows your focus. The diagnostic questions in steps 3 through 5 confirm the pillar.

• Step 3: Assess Your People Component

  A People assessment covers three dimensions, each requiring a different kind of data:

  • Capacity: Are there enough agents available during peak hours to handle incoming volume without queue buildup? Look at ticket volume by hour and day against agent scheduling.
  • Capability: Do agents have documented training coverage on the top 20 ticket categories? If 80% of your volume falls into 20 ticket types and agents haven't been trained on procedures for all 20, capability is limiting FCR.
  • Retention: What's the annual turnover rate for service desk staff? Each departure takes institutional knowledge with it, and the team can spend significant time re-training before a replacement reaches full productivity.

  Diagnostic questions for People:

  • Are your Tier 1 agents handling tickets that should be at Tier 2, and if so, what's driving that: overconfidence, unclear escalation criteria, or something else?
  • What percentage of agents completed documented training on your top 20 ticket categories in the past 12 months?
  • How does your annual service desk agent turnover rate compare to the previous year? Is it trending up?
  • What percentage of your agents contributed at least one knowledge article in the past 90 days?
  • When you ask agents what slows them down the most, what do they say? Agent-reported friction is often more accurate than manager assumptions about where the bottlenecks are.

  One thing that's genuinely hard to assess here is the gap between what agents say they do and what they actually do. If your documented training is strong but FCR is still lagging, it's worth watching a handful of live tickets before assuming the training is the problem. Sometimes documented procedures exist and agents have developed informal workarounds that nobody has challenged.

• Step 4: Assess Your Process Component

  Process problems are the most common root cause of chronic service desk dysfunction, and the hardest to see from the outside because they're invisible until a ticket breaks down. The assessment here focuses on whether work is structured clearly enough for anyone on the team to handle it consistently.

  • Ticket intake: Is there a defined categorization schema, and is it applied consistently? Inconsistent categorization on intake is one of the highest-impact process problems to fix because it affects every downstream step.
  • Escalation paths: Does every ticket category have a documented escalation path? "Use your judgment" is not an escalation path.
  • Knowledge management: Are knowledge articles being created, updated, and actually used? Effective knowledge management follows a solve-evolve loop, where each resolved ticket either confirms an existing article is accurate or generates a new one. A knowledge base that agents don't reference during active tickets isn't functioning as a process tool.
  • Problem management: When the same incident recurs, is there a defined process for moving it from incident to problem, investigating root cause, and documenting a permanent fix?

  Diagnostic questions for Process:

  • What percentage of tickets are miscategorized on first submission, and does your system track this?
  • If you randomly asked five agents to handle the same complex ticket type, would you get the same resolution path from all five?
  • Do you have a documented resolution path for every ticket category in your top-20 volume list?
  • What is the average number of times a knowledge article is accessed per ticket resolved? If it's close to zero, agents aren't using the knowledge base during live tickets.
  • How many unique escalation paths exist in your current system, and are they named, documented, and consistently followed?
  • What is your repeat incident rate? If the same configuration issue or system error recurs without a permanent fix, problem management isn't functioning.

  The cost of process gaps in this area is measurable. HappySignals' IT Experience Benchmark research, drawn from millions of end-user feedback responses, found that each ticket reassignment costs the end-user an average of 1 hour and 42 minutes of lost work time. Most of those reassignment problems trace to unclear escalation paths and inconsistent categorization at intake, both fixable without a new tool.

• Step 5: Assess Your Technology Component

  Technology assessment comes last because it only makes sense once you know what your people and processes need the technology to do. Evaluating a tool before you've mapped your workflows is like designing a kitchen layout before writing the menu.

  • Automation coverage: What percentage of your total ticket volume could be handled without agent intervention? Common candidates include password resets, account unlocks, software license requests, and standard hardware procurement. If agents are manually resolving these, automation hasn't been deployed where it should be.
  • Self-service adoption: What percentage of total issue volume is deflected by your self-service portal? Low deflection rates can indicate a tool problem (poor search, hard to navigate) or a process problem (users aren't directed to self-service at the right moment).
  • Tool-process alignment: Was your current ITSM platform selected and configured after your workflows were documented? If the tool was chosen first, the built-in logic may not match how your team actually routes, prioritizes, and escalates work.
  • Integration gaps: Are there manual steps in your ticket lifecycle where agents copy information from one system to another? Each manual data transfer is a process-technology misalignment that costs time and introduces errors.

  Diagnostic questions for Technology:

  • What percentage of total ticket volume is deflected by self-service or handled by automation without agent involvement?
  • Were your current workflows documented and agreed upon before your ITSM platform was configured? If not, which came first?
  • Which recurring, low-skill ticket types still require agent time that automation could handle?
  • Where do agents most often leave the ITSM tool mid-ticket to retrieve information from another system?
  • When agents were trained on the current tool, was the training anchored to your specific workflows, or was it generic product training?

• Step 6: Sequence Your Fixes Correctly

  Once you've run the diagnostic for all three pillars, you'll usually find problems in more than one. The reliable order for fixing them is People first, then Process, then Technology. The right standard at each pillar is "stable enough," not perfect. Process documentation work can run alongside agent training, and some technology investment can happen while Process is still being refined. But budget priority and leadership attention should follow the sequence, especially when resources are constrained.

The Sequencing Mistake That Wastes Most Service Desk Budgets

The most common reason PPT improvements don't hold is that teams reach for technology first. This isn't irrational. New ITSM platforms are visible, budget-justifiable, and vendor-driven in ways that training programs and process documentation projects rarely are. A CIO can show a new tool in a board presentation. A documentation sprint is harder to put on a slide.

What makes the pattern lasting is that technology purchases do produce real short-term improvements. Reporting gets cleaner. Ticket intake looks faster. Dashboards are easier to pull. Those gains buy time before the underlying process gaps resurface, usually at scale, and months after the implementation is locked in and expensive to reconfigure.

What follows after is predictable. The organization deploys a new platform, runs training on the tool, and then discovers that agents still don't follow consistent escalation logic, all because that logic was never agreed upon before configuration began. The tool was built around informal habits rather than documented processes, and reconfiguring it later means relitigating decisions that should have been made before implementation.

The fix isn't complicated, but it does require discipline:

• Map your top 20 ticket categories to documented resolution paths before touching tool configuration.
• Get agreement on escalation logic, including which groups own which categories.
• Train agents on the process, not just the platform.
• Configure the technology to support what you've agreed to.

That order produces implementations that hold. The reverse produces expensive migrations that land back in the same place.

People, Process, Technology Framework FAQs for IT Service Desks

• What is the people, process, technology framework?

  The PPT framework is a management model that diagnoses operational problems by examining three interdependent pillars: the people doing the work, the processes structuring how that work happens, and the technology supporting both.

  The framework traces back to Harold Leavitt's Diamond Model (1960s) and became widely used in IT management through the 1990s. For IT service desks, it maps directly onto familiar ITSM concepts. ITIL practices are the Process layer, the ITSM platform is the Technology layer, and trained IT staff are the People layer. Most service desk problems have a clear root in one of these three areas, and identifying which one is the diagnostic work the framework is designed to support.

• What should I fix first: my team, my processes, or my tools?

  Fix your team first, then your processes, then your tools. That sequence is the one that holds.

  People problems undermine processes. If agents don't have the training or capacity to follow a defined workflow consistently, the workflow can't function regardless of how well it's documented. Process problems undermine technology. If you configure an ITSM platform around undocumented or inconsistently-followed workflows, the tool inherits and sometimes locks in the dysfunction. Technology is the last pillar to fix because it should support stable people and processes, not compensate for the absence of either.

  The pillars aren't always cleanly sequential, and that's fine. You'll often run process documentation work alongside agent training. The principle is really about where to invest budget first and which fix gets priority when you can only focus on one thing. Stabilize your team before your processes, and your processes before your tools.

• How do I tell if my service desk problems are a people issue or a process issue?

  Ask whether the problem is consistent across the team or concentrated in specific agents.

  A process problem shows up consistently. If five different agents all handle the same ticket category differently, or if tickets in a specific category routinely get reassigned, the problem is almost certainly in how that category is handled procedurally, not in who's handling it. A people problem, by contrast, is often localized. If one tier is consistently underperforming or a specific shift has disproportionate escalations, training coverage or staffing levels are the more likely culprit.

  The diagnostic question that clarifies this most quickly is a simple one. If you gave the same ticket to any agent on the team, would they handle it the same way? If the answer is no, it's a process problem. If the answer is yes but the outcome is still wrong, it's a people problem, which means the shared approach is incorrect or agents lack the skills to execute it.

• Is the PPT framework the same as ITIL?

  No, but they align closely. The PPT framework is a strategic model; ITIL is a detailed operational framework that fits inside it.

  Think of PPT as the organizing structure and ITIL as the methodology that populates the Process pillar. ITIL's practices are all Process-layer guidance, covering:

  • Incident management
  • Service request fulfillment
  • Problem management
  • Change enablement
  • Knowledge management

  The ITSM platform you use to run those practices is the Technology layer. The teams trained to follow ITIL procedures are the People layer.

  Organizations that implement ITIL without thinking about the People and Technology layers often find the practices don't take hold. Processes on paper don't run themselves. The PPT framing is useful precisely because it forces you to check whether all three supporting structures are in place, not just whether the process documentation exists.

  ITIL 4 actually reinforces this point explicitly. Its Service Value System describes how people, processes, and technology need to work in concert, which is a formalization of what the PPT framework has described informally for decades.

• What metrics indicate a process problem at my service desk?

  A high ticket reassignment rate is the clearest process indicator, but it's not the only one.

  Look for these signals:

  • Reassignment rate that consistently tops 10% of total ticket volume often reflects unclear escalation paths or inconsistent categorization at intake
  • Repeat incident rate: if the same issues resurface week over week without a permanent fix, problem management isn't functioning as a process
  • Knowledge base utilization near zero: if agents resolve tickets without accessing knowledge articles, process isn't connecting agents to the documentation that exists
  • Wide variance in Average Handle Time (AHT) for the same ticket category across different agents: consistent processes produce consistent resolution times; wide variance means agents are improvising

  Categorization accuracy on first submission is the hardest process metric to get and also one of the most useful. Most ITSM platforms don't track it natively. You have to review tickets that were recategorized after intake and calculate what share of total volume they represent. If that number consistently runs above 5%, intake categorization is a process problem worth fixing before investing in routing automation.

  Related Giva Resources

  • Service Desk/Help Desk Best Practices Assessment Questions
  • SLA Breach Root Cause Analysis: How to Find Causes & Fix Them
  • What Is a Maturity Model in ITIL & ITSM?
  • ITSM Frameworks: Major Types + How and When to Choose Them
  • IT Service Desk Software Guide: Features, AI & Best Practices

  Using the PPT Framework to Build a Service Desk That Actually Improves

  The PPT framework's value as a diagnostic tool comes from one thing. It forces you to ask which layer the problem actually lives in before spending anything on a fix. Most chronic service desk issues have a clear answer to that question. Ticket reassignments are almost always a Process problem. Low FCR concentrated in specific agents is usually a People problem. A self-service portal nobody uses could be either Process (users aren't routed there) or Technology (the portal doesn't show the right content). The diagnostic is the work.

  The sequence matters too. A service desk that builds its people foundation first, stabilizes its processes second, and then selects and configures technology to support both ends up in a fundamentally different position than one that starts with a tool purchase. The former gets an ITSM platform that amplifies what's working. The latter gets a migration project that reveals how much wasn't defined.

  This is also where the PPT diagnostic connects directly to service desk maturity modeling. A reactive service desk (Level 1 on any standard ITSM maturity scale) almost always has unstable People and Process foundations, with informal escalation paths, no knowledge management, and staffing that can't absorb volume spikes. Moving to a repeatable or managed level isn't primarily a technology investment. It's the People and Process work that makes the technology worth having.

  See How Giva Supports the Technology Pillar

  Once your People and Process foundations are in place, the right technology should feel like a natural next step, not a rescue mission. Giva's IT Help Desk and ITSM Software is built to support the workflows you've already defined. It handles:

  • Managing change requests and incidents in one system with consistent categorization rules
  • Routing tickets based on escalation logic you control
  • Reporting that gives managers visibility across all three PPT pillars
  • Tracking patterns in ticket volume, escalation rates, and CSAT that the diagnostic questions in this guide are designed to identify

  The diagnostic work this guide describes is also where Giva's free 25-question Service Desk Assessment fits in. It evaluates People, Process, and Technology maturity across five dimensions and gives you a baseline score to work from, which is a faster starting point than building your own assessment from scratch.

  Get a demo to see Giva's solutions in action, or start your own free, 30-day trial today!