The persona model — what most IT teams get wrong about who needs what
Most mid-market fleets give everyone a laptop. The persona model — matching each user to the device that actually serves their work — quietly removes 20-40% of fleet cost without anyone losing what they need.
Walk into most mid-market IT shops and ask how they decide what devices to give people, and the answer is some version of "we give everyone a laptop." Maybe two configurations — a standard one and a premium one for engineers or executives. Maybe a third tier for users who have unusual needs. Either way, the framework is one device class for most people, with a small number of exceptions.
This is one of the most expensive habits in mid-market IT. It's also one of the most invisible, because it doesn't show up as a problem — it shows up as a normal expense, year after year, fleet refresh after fleet refresh. Nobody questions it. Nobody models the alternative. The hardware budget is what the hardware budget is.
It doesn't have to be. The fleet's actual usage patterns, modeled properly, reveal that 20-40% of users in a typical mid-market organization are running on hardware that's substantially over-provisioned for what they actually do. The same fleet, redesigned around persona-driven device selection, costs meaningfully less to acquire, less to manage, and less to refresh — without anyone losing the device they actually need.
This is the persona model. It isn't new as a concept, but most IT teams don't run it as a real operational discipline. Here's what it is, why it works, and what the resistance to adopting it usually looks like.
What "persona" actually means in practice
In the persona model, a persona is a defined category of user characterized by what they need to do their work, not by their job title. A clinician using a workstation that drives an imaging console is one persona. A clinician using a laptop to access EHR from exam rooms is a different persona, even though both might have "RN" or "MD" on their org chart. The persona is defined by the work, not by the role.
For a typical mid-market healthcare or manufacturing operator, the persona map usually resolves into something like:
- A small number of high-performance roaming users — knowledge workers, executives, traveling salespeople — who genuinely need a premium laptop with strong battery life, light weight, and the full Office 365 stack.
- A larger group of standard roaming users — most administrative staff, mid-level managers, people who work primarily from one location but occasionally travel — who can run on a standard business-class laptop, often a generation older than the premium tier.
- A surprisingly large group of fixed users — call center agents, accounts receivable, scheduling staff, anyone whose physical location is the same building every day — who would be better served by a small form factor desktop. A $700 desktop will outlast the $1,500 laptop, run quieter, support multiple monitors better, and survive five years of operation instead of three.
- A group of single-purpose users — checkout terminals, kiosk operators, certain clinical workstations, certain plant-floor stations — who don't need a general-purpose computer at all. A thin client or virtual desktop accessing a centralized environment is the right answer. The device on the desk costs $300, lasts seven years, and never needs to be re-imaged.
- A scattering of edge cases — engineers running CAD, video editors, data scientists running local models — who actually do need workstation-class hardware and should get it.
The point of the persona map isn't to take laptops away from people. The point is to give each person the device that actually serves them, which is often cheaper, often longer-lived, and often a better match for their work.
Why this is more than a procurement exercise
Persona-driven device selection sounds like a budget conversation, and it is. But the savings on hardware acquisition are the smallest part of what the persona model does.
The compounding effects show up in three other places.
First, in operating life. A small form factor desktop runs five to seven years; a laptop runs three to four. A thin client runs seven to ten years. Right-sized devices last longer, which means refresh cycles get further apart, which means total cost of ownership drops by a multiple of the per-device price difference. The fleet that's 30% desktops and thin clients refreshes less often than the all-laptop fleet, even though both started at the same total cost.
Second, in support load. Laptops generate more help-desk tickets than desktops per unit time — broken keyboards, dropped screens, battery problems, charger losses, lost devices. A fleet that's right-sized to personas has fewer laptops, which means fewer of these tickets, which means less help-desk load. The savings show up in IT operating cost, not in capital cost, which is exactly why most budget conversations miss them.
Third, in security posture. Laptops travel, get lost, get stolen. Desktops don't. Thin clients don't. Fewer laptops in the fleet means fewer endpoints that walk out of the building, which means a smaller attack surface and lower incident rates. The savings here are even harder to model in advance, but they're real — and for healthcare operators dealing with PHI and manufacturers dealing with sensitive IP, they're worth taking seriously.
What the resistance actually looks like
If the persona model produces these savings reliably, why don't most organizations run it? Three reasons, all worth understanding.
The first is cultural. In most organizations, the laptop has become an employee benefit, not just a tool. "I want a laptop" isn't really a statement about work; it's a statement about status, flexibility, and the option to work from home occasionally. Giving someone a desktop instead of a laptop feels like a downgrade, even when the desktop is objectively better for the work they actually do. Persona-driven device selection requires explicit communication about why the device assignment makes sense for each role — not as a defense against complaint, but as a clear statement of the operating model. When the communication is good, most users accept the assignment because the reasoning is sound. When the communication is missing, the persona model collapses under social pressure.
The second is the one configuration to manage fallacy. IT teams sometimes resist the persona model because it feels like more complexity — five device classes instead of one, five sets of images, five sets of accessories, five vendor relationships. This is backwards. The persona model is more complex to plan and dramatically simpler to operate, because each persona gets a known-good configuration that doesn't need to be customized per user. The complexity is in the design, not the operations. Once the persona map exists, ordering becomes more efficient, not less. Imaging becomes more efficient, not less. Asset tracking becomes more efficient, because every device in the fleet maps to a defined persona and a defined refresh cycle.
The third is the absence of a forcing function. Most IT teams know intellectually that not every user needs a laptop. They don't act on it because there's no moment that requires them to. The refresh project is the moment — when the fleet is being touched anyway, that's the opportunity to re-baseline the persona map. Done as part of refresh planning, persona modeling adds days, not weeks, to the project timeline. Done outside refresh, it's hard to justify the disruption.
What a persona-driven refresh looks like in practice
The persona model starts with fleet data: who has what device today, what role they're in, what applications they actually use, where they work, how they travel. Some of this data comes from the MDM or IT asset management system. Some comes from interviews with managers and HR. Some comes from light usage analytics — looking at which users actually move their device versus which ones leave it on the same desk for months at a time.
From that data, the personas emerge. Usually five to seven for a mid-market organization. Each persona gets a defined device class, a defined application stack, a defined warranty model, and a defined refresh cycle. The persona is documented and becomes part of the operating model — new hires get assigned to a persona on day one, role changes trigger persona reassessments, the persona map gets reviewed annually.
The refresh project then becomes the moment when the existing fleet gets re-mapped against the new persona definitions. Some users move up a tier; some move down; most stay where they are but get a more accurately-sized device than they had before. The hardware order reflects the persona map. The imaging strategy reflects the persona map. The deployment plan reflects the persona map.
The hardware budget for the refresh, run this way, lands meaningfully lower than the budget for the equivalent "everyone gets a laptop" approach. Not because Surya is doing something clever with procurement, but because the fleet that gets ordered is the fleet that actually matches the work.
How Surya thinks about this
The persona model is core to how we run both refresh and continuous lifecycle management. Every fleet assessment we do starts with the persona map, and every refresh project we run reorganizes the existing fleet against that map. The savings show up immediately in hardware cost and compound over time in operating cost, refresh cadence, and security posture.
For organizations approaching a refresh, the persona work is the highest-leverage piece of upfront planning. For organizations thinking about continuous lifecycle management, the persona map becomes the permanent operating model — a foundation that every other piece of IT operations builds on.