Managed Device Services: A Practical Guide for Teams Without an IT Function

TL;DR

• Managed device services means paying somebody else to run some or all of your device estate: buying, deploying, supporting, securing and eventually retiring machines.
• You do not need this while somebody internal enjoys the work and it fits around their job. That situation lasts longer than vendors suggest.
• Four different models are sold under this name and they overlap confusingly. Buying the wrong one is the usual mistake.
• The term is also a manufacturer's brand in parts of this market, so search results mix a product with a category.
• What you are actually buying is usually time and accountability rather than a lower cost per device.
• The thing that fails afterwards is the record. If the arrangement leaves you without your own view of the estate, you have outsourced the work and kept the risk.

The Monday That Nobody Owned

A company of about seventy people has no IT function. It has a head of operations who is good at this, a finance lead who handles the purchasing, and a developer who everybody asks when something breaks.

A laptop dies on a Monday morning. The developer spends forty minutes diagnosing it, concludes the drive has failed, and discovers nobody is certain whether the machine is still in warranty because the purchase record is a PDF in an email thread from two years ago.

The head of operations orders a replacement that afternoon. It arrives Thursday. Nobody has a standard build, so the developer spends another two hours on Friday setting it up from memory, missing two applications the person actually needed, which surface the following week.

Recommended Tools

Best tools for Device Management

B BambooHR HR management system L Lattice Performance management D Deel Global payroll & EOR

View all recommended tools

The failed machine goes into a drawer. Nobody wipes it, because wiping is not anybody's job and the person who would know is busy. Eleven months later it is still there, still holding whatever was on it.

Total visible cost: one laptop. Total actual cost: most of three people's days, a week of reduced output for the person affected, and an undocumented data risk sitting in a drawer.

The real issue is not that nobody could fix the laptop. It is that five different people each owned a fragment of the problem and nobody owned the outcome.

What the Story Actually Cost

Before going further it is worth putting numbers against that Monday, because the absence of numbers is why situations like it persist for years.

The developer spent forty minutes diagnosing and two hours building. The head of operations spent perhaps an hour ordering and chasing. The person whose laptop failed lost most of three days of useful output and part of the following week to the two missing applications. Nobody recorded any of it, and the only figure that reached a system was the cost of one replacement laptop.

Run that four times a year across a company of seventy and the hardware looks cheap while the displaced time does not. Run it monthly, which is realistic once the fleet is a few years old and has no refresh cycle, and it becomes a meaningful fraction of a role.

Two further costs sit outside even that. The machine in the drawer is an unresolved data risk with no owner and no end date. And the new starter who spent a week without the right tools formed an impression of the company during the one period they were paying closest attention.

None of this argues that the company should have bought managed device services that Monday. A standard build and a documented warranty record would have removed most of it. The argument is narrower and more useful: you cannot evaluate any provider until you know what the current arrangement costs, and almost nobody does, because the cost is denominated in a currency nothing measures.

When You Do Not Need This

While somebody internal is genuinely covering it. A company of forty with a technically confident operations person and standard machines does not need a managed service. It needs that person to have ten per cent of their week protected for the work.

When the friction is visible but contained. Around sixty to a hundred people the cracks show: inconsistent builds, warranty uncertainty, slow replacements. Still fixable internally with two standard configurations and a documented process.

When it becomes a liability. Past roughly a hundred people without an IT function, or any size where security requirements have arrived, the gap between what should be happening and what is happening stops being visible to anybody. That is the threshold.

The edge case that overrides all of it is a compliance requirement. A customer contract or a certification that requires device encryption, patch currency and evidence of both will arrive with a deadline, and that deadline is usually shorter than the time needed to build the capability internally.

What Teams Actually Need

"Who do people contact when something breaks?"

One route, known by everybody, with a response expectation attached. Most companies without IT have three informal routes and no expectation, which is why small problems become multi-day problems.

It matters because an unclear route means problems get raised late, after somebody has already lost half a day trying to self-serve.

"What is on our machines, and are they secure?"

Encryption state, patch level, who has administrator rights, whether a lost laptop could be wiped remotely. Most companies in this position cannot answer any of these with confidence.

It matters because these are exactly the questions a customer security review asks, and the answers cannot be retrofitted in the two weeks before a deadline.

"What happens when somebody joins or leaves?"

A repeatable sequence with an owner. Joining is usually handled adequately because somebody is watching. Leaving is where the gaps are.

It matters because departures are where equipment and access both leak, and neither is visible until somebody looks.

"What do we own and where is it?"

A list with serial numbers, holders and ages. Almost nobody at this stage has one that is current.

It matters because every other decision depends on it, and because reconstructing it later means asking every employee what they have.

"What is this actually costing us now?"

Not the hardware. The hours spread across people whose jobs are something else.

It matters because without that number, every proposal looks expensive compared to a status quo that appears to be free.

Count What This Costs You Today

The question above asks how many hours this consumes internally and then leaves you to work it out. Here is the method, and it is the number that decides whether managed device services are expensive or cheap.

Take the last ten device problems. Not the dramatic ones, the ordinary ones: a replacement, a failure, a new starter setup, a password issue, a leaver. For each, list everybody who touched it and roughly how long they spent.

Multiply by your monthly frequency and you have an annual hours figure. Most companies of seventy to a hundred and twenty people without an IT function land somewhere between 300 and 600 hours a year, which is a third of a role spread invisibly across four people who were hired to do other things.

Two things make this number persuasive internally in a way a vendor's case never is. It is yours, so nobody argues with the inputs. And it is denominated in the time of people whose actual work is visibly being displaced, which is a more uncomfortable fact than a line in a budget.

The last row deserves particular attention. A single customer security questionnaire can consume twenty hours when nobody can answer from a system, and those questionnaires arrive without notice and with a deadline attached.

The Four Models Sold Under This Name

Device management software, sold as a service

A platform doing enrolment, policy, patching and remote wipe, with somebody configuring it for you.

When it is right: when the requirement is security and consistency rather than hands-on support. This is the core of what most compliance questions are asking about.

When it fails: it is software. It does not help somebody whose laptop will not start, and it does not buy, ship or recover anything.

Managed service providers

A firm providing a help desk, support engineers and ongoing administration, usually per user per month.

When it is right: when people need somebody to talk to, which is the gap most companies without IT actually feel.

When it fails: on hardware logistics for distributed teams. Most MSPs are built around an office and a van, and their model strains when the people are in nine countries.

Equipment lifecycle platforms

Vendors handling the physical life of a machine: purchase, storage, shipping, retrieval, wiping, resale.

When it is right: distributed teams, especially where hires are in markets you cannot serve.

When it fails: these are logistics businesses. They do not run a help desk, they do not do network discovery, and they do not manage software licences.

Manufacturer device services

Programmes from the hardware makers combining finance, deployment and support for their own machines.

When it is right: single-manufacturer fleets in markets the manufacturer serves well.

When it fails: mixed fleets, and anything outside the manufacturer's own footprint. Worth noting that one of these programmes is itself called something close to managed device services, which is why a search for the category returns a specific vendor's product alongside the general one.

Who Should Still Own Things Internally

Outsourcing the work does not outsource the accountability, and three responsibilities should stay inside the company regardless of how comprehensive the arrangement is.

The asset register. Your own copy, exported on a schedule rather than on request, reconciled against an independent source. A provider's record is accurate about what they handled and silent about everything else: machines bought before the arrangement, equipment bought locally in an emergency, anything a team expensed. Those are invisible to a provider by definition and they are usually the devices that cause trouble later.

The decisions about standards. What machine people get, what software is default, who gets administrator rights, how long a machine stays in service. A provider will happily make these and will make them to suit their operation, which is not always the same as suiting yours. Keep the decision and delegate the execution.

The relationship with the question. When a customer security review arrives, it comes to you. A provider can supply evidence and a good one will supply it quickly, but somebody internally has to understand what is being asked and whether the answer is true. A company that cannot interpret its own security posture without a phone call to a vendor has a dependency rather than a service.

None of this requires much time. A monthly export, a standards document reviewed annually, and one person who understands the estate well enough to answer a question. Perhaps a few hours a month in total.

What it prevents is the slow hollowing out that makes changing provider feel impossible. The companies that find themselves stuck with an arrangement they have outgrown are almost always the ones who stopped keeping their own record early on, and then could not evaluate alternatives because they no longer knew what they had.

What the Security Questions Actually Ask

Compliance is named repeatedly above as the thing that arrives with a deadline, so it is worth setting out what is actually being asked, because it is narrower and more answerable than it sounds.

Customer security reviews and certification checklists converge on a short list, and almost all of it is about devices.

Three observations worth having before you buy anything. A management platform answers the first four directly and is the cheapest route to a credible response. The fifth and sixth are process and record questions that no software answers by itself. And every one of them is answerable with evidence or with an assertion, and reviewers increasingly want the first.

The reason this belongs in a managed device services decision is that it narrows the purchase. A team facing a questionnaire often believes it needs a full service arrangement when what it actually needs is enrolment and reporting, which is a smaller and faster purchase with published pricing.

Buy the thing that answers the question in front of you. The broader arrangement can wait until you know whether you still want it, and in a good number of cases the pressure that prompted the search turns out to be fully satisfied by the narrower purchase.

Building a Brief That Gets Comparable Answers

Most companies at this stage run three informal conversations and compare impressions. That is reasonable and it has one reliable failure: the three vendors answer different questions, so the decision becomes a judgement about who presented best.

A brief fixes it and fits on one page.

Your estate. Device count, operating system mix, roughly how old, and where the people are. Include the awkward parts rather than tidying them, because the awkward parts are where quotes diverge.

Your standard build, if you have one. If you do not, say so, and expect quotes to carry a margin for the uncertainty.

The job you want done, stated as outcomes rather than features. "Every machine encrypted and reportable", "somebody staff can contact within two hours during their working day", "machines delivered within five days in these six countries, and recovered within thirty when people leave".

What you will keep internally. Standards decisions, the register, the customer relationship. Saying this up front avoids a proposal built around taking all three.

Your decision date. Nothing concentrates attention more effectively, and it protects you from a process that drifts for a quarter.

Then ask for four things in writing rather than in a presentation: what is included at the quoted figure, what is explicitly excluded, what the response commitment is during your people's hours, and what happens if you leave.

That last one is the most informative and the most often deflected. A provider who will commit in writing to returning your data and any held machines without a fee has told you something real about how they operate. One who prefers to discuss it later has also told you something.

How to Choose: Five Questions

What is the actual gap: support, security, or logistics?

These are three different purchases. Write down your last ten problems and sort them, because the answer is usually lopsided and tells you which model to look at.

How many hours a week is this consuming internally?

Count them honestly across everybody involved. This is both your business case and your benchmark.

Do you have a compliance deadline?

If yes, that constrains the timeline and probably the model, because the security and evidence requirements are specific and not all models deliver them.

Where are your people?

One office changes the answer completely compared to nine countries. Logistics capability only matters in the second case, and it is expensive to buy if you do not need it.

Who will hold the register afterwards?

Name a person internally. If the honest answer is the provider, make sure you can export it at any time.

The Naming Problem, Which Costs People a Day of Research

Worth addressing directly because it wastes time for anybody researching this category.

The phrase is used in at least three ways. As a general category covering any arrangement where somebody else runs your devices. As a specific product name by at least one major hardware manufacturer, offering finance, deployment and support around their own machines. And loosely by managed service providers describing part of what they do.

The result is that a search returns a vendor's product page, a category explainer and an MSP's service description, all apparently about the same thing and none of them comparable. People reasonably conclude the market is confusing. It is not especially confusing; the label is just doing three jobs.

Two habits make the research tractable.

Describe the job rather than the category when you search and when you brief vendors. "Enrolment, policy and patch reporting for 90 laptops across six countries" produces a shortlist. "Managed device services" produces a reading list.

Ask every vendor the same four questions regardless of what they call themselves. Do you provide software, people, logistics, or some combination. What specifically is included at the quoted figure. What do you not do. And who do your customers typically buy alongside you. That last question is the most revealing and the most frequently answered honestly, because a vendor who knows what they do not cover usually says so.

The same confusion affects pricing research. A published per-device rate for a management platform and a quoted per-user rate for a support arrangement are not comparable numbers, and seeing them side by side in a comparison article is how people end up budgeting for the wrong thing by a factor of several.

The Options

Scalefusion. Device management across three product lines, and one of the few vendors here publishing rates. Scalefusion UEM lists Essential at $2 per device per month and Growth at $3.50. The identity line, OneIdP, lists Access Core at $4 and Access Pro at $5. The security line, Veltar, lists Security Core at $3 and Security Pro at $4. All plans are billed annually only with a minimum of ten devices. Note $4 appears twice, once for OneIdP Access Core and once for Veltar Security Pro, so it is meaningless without the product name. Note also that the Scalefusion 360 Enterprise Suite at $12.42 per device per month is a bundle of three products rather than a management rate. Best for security and consistency. It does not buy, ship or support hardware physically.

Miradore. Device management with a free tier up to fifty devices after a fourteen-day trial, then Premium at $3.30 per device per month paying monthly or $2.75 paying annually, and Premium+ at $4.75 monthly or $3.95 annually. Best for small fleets needing management without a service relationship. Its pricing sits at a plans-pricing path; the obvious pricing URL returns a not-found error.

Managed service providers. Local and regional firms, priced per user per month, rarely published. Best for hands-on support and a help desk people can call. Where they struggle: distributed hardware logistics.

Workwize. Lifecycle platform with strong warehousing. Publishes no rate; the figures on its pricing page are savings claims.

allwhere. Lifecycle platform covering procurement, deployment and retrieval. Publishes no rate, quote and demo only.

RemoAsset. Buying, renting and leasing with shipping, retrieval, storage and wiping, and a register of what it handled. Disclosure: RemoAsset is our own product. We build it, which is why its limits appear here with the same prominence as its strengths. Best when the gap is physical: machines arriving late, never coming back, or sitting unwiped in a drawer like the one in the story above. Its Subscription tier is the only tier that publishes a figure, from $1,499 per year, and everything else is quoted. Where it struggles, and this matters on a page about managed device services: it does no network discovery, so it cannot find machines nobody enrolled through it, and it does no software licence management. It also does not run a help desk. If what you need is somebody your staff can contact when a laptop will not start, that is an MSP, not this.

Standard Builds Are the Cheapest Thing on This Page

Before buying managed device services, there is one internal change that removes a surprising share of the problem and costs nothing but a day of somebody's attention.

A standard build is an agreed machine specification plus an agreed set of software, settings and access, documented well enough that a different person could produce the same result. Most companies without an IT function have no such thing, which is why the setup in the opening story took two hours and still missed two applications.

What belongs in it is more than a laptop model. The specification, the operating system version, the applications everybody gets, the applications specific to each role, the settings that must be applied, and the accounts that must exist. Written down once, in a document anybody can follow.

Three benefits follow immediately and none requires a vendor.

Setup stops depending on one person's memory. Which means it stops being a bottleneck when that person is on leave, and stops producing inconsistent machines.

Problems become comparable. When every machine is built the same way, a fault on one is informative about the others. When each is bespoke, every problem is a fresh investigation.

Any future provider can quote accurately. A vendor pricing against an undefined build prices for variety, and variety is expensive in ways that never appear as a line item.

There is a fourth benefit that shows up later. Standard machines are reissuable, and a reissuable fleet is worth considerably more than a pile of mismatched hardware. A returning laptop that matches the standard goes straight to the next starter, while one that does not sits in a drawer while somebody decides.

Do this before any procurement conversation. It improves the quotes you get and it may reduce what you need to buy.

The exception path is what decides whether the standard survives its first year. A standard that admits no exceptions is one people quietly route around, and the routing around is invisible until somebody audits. A standard with a documented way to ask, give a reason and get an answer within a few days holds up, because it stays a rule rather than becoming an obstacle.

The Decision Table

The First Ninety Days With a Provider

If you do appoint somebody, the first quarter determines whether this works. Most of the value is won or lost before anybody resolves a single ticket.

Weeks one to three. Hand over properly. Your asset register such as it is, your standard build, your application list, and the names of whoever currently holds admin rights to things. The handover is always worse than expected because so much was held informally, and that discovery is itself useful.

Weeks four to eight. Agree the route and tell everybody about it twice. The most common failure in a new managed device services arrangement is that staff keep asking the person they always asked, because nobody told them clearly enough that something changed. The old route persists, the provider sees low volume, and the internal person is still doing the job alongside paying for somebody else to do it.

Weeks nine to twelve. Test the things you are actually buying. If security evidence is the point, ask for the reports and check they answer a real questionnaire. If support is the point, measure response times against what was promised. If logistics is the point, run a retrieval rather than waiting for one.

Then compare against the hours figure you calculated at the start. If internal time has not fallen, something has gone wrong, and it is usually the routing rather than the provider.

One warning about the handover period. There is a window where neither you nor the provider is fully responsible, and problems arriving in that window tend to sit. Name an owner for the transition specifically, with an end date, rather than assuming the arrangement starts cleanly on the day the contract does.

When It Goes Wrong, It Goes Wrong in Four Ways

Arrangements in this category fail predictably, and the failures are recognisable early if you know the shape of them.

The old route survives. Staff keep asking the person they always asked, because that person is responsive and known. The provider sees low ticket volume and reports excellent performance. Internally, the same individual is still doing the work, now alongside an invoice. This is the most common failure by a distance and it is a communication problem rather than a vendor problem.

The scope was never written down. The arrangement covers "devices", which turns out to mean different things to each party the first time something awkward happens. A machine that will not start, bought before the contract, held by a contractor, in a country the provider does not serve. The resolution is always slower than the problem deserves because it begins with a conversation about whose job it is.

The evidence does not arrive. Everything works operationally and then a security questionnaire lands and the reports are not in a form anybody can use. This is why the ninety-day plan above says to test the reports against a real questionnaire rather than admiring a dashboard.

The record quietly stops. The monthly export fails in month four, nobody notices because nobody was using it, and eighteen months later the internal picture of the estate is whatever it was in month three. This is the failure with the longest tail, because it is invisible until you need to evaluate alternatives or answer somebody external.

Three of those four are preventable with things that cost nothing: tell people the route twice, write the scope down including the awkward cases, and name somebody who would notice if the export stopped. The fourth, evidence quality, is worth testing before the contract rather than after.

The Cost of Getting This Wrong

Three layers, and only the first gets quoted.

The visible cost is the service fee, and it is the easiest number to object to because the alternative appears to cost nothing. It is also the only layer that appears in a proposal, which is why proposals make a poor basis for this decision on their own and why the hours exercise earlier matters more than any vendor comparison. It does not, and the reason it appears to is that the current cost is distributed across people whose time is recorded against something else.

The second layer is that time, which the opening story quantifies loosely and which most companies never count. Three people losing most of a day, repeatedly, is a larger number than any per-device fee once it happens monthly rather than annually.

The third layer is the one that persists after the arrangement ends: the record and the capability. A provider who does everything and leaves you with no internal view of the estate has solved your operational problem and created a dependency. That is an acceptable trade if you make it deliberately and keep an export. It is a bad surprise if you discover it when changing provider.

So the question is not whether managed device services cost more than doing nothing. It is this: if this arrangement ended tomorrow, would you have a current list of every machine, its holder and its security state, without asking the provider for it?

What Distributed Teams Change

Most managed device services were designed around an office, and that assumption breaks in three specific places when your people are spread out.

Support stops being physical. An MSP model built on an engineer who visits does not translate. Everything has to be remote, which means remote access tooling, which means the enrolment and policy layer matters more than it does in an office where somebody can walk over. Teams often discover they needed the management platform before the support contract rather than alongside it.

Hardware logistics becomes the dominant cost. In an office, getting a machine to somebody was a two-minute task nobody counted. Distributed, every delivery is a shipment, often across a border, with a declared value and an importer of record. Every return is a retrieval from somebody who may no longer be motivated to help. This is the single largest difference and it is the part most support-oriented providers handle worst.

Time zones change the service level. A response time of four hours means something different when the person raising the problem is eight hours ahead of the people answering. Ask what coverage actually looks like in your people's working hours rather than accepting a headline number, and ask specifically what happens overnight relative to the provider.

The practical consequence is that distributed teams usually need two providers rather than one: a management and support arrangement, and a logistics arrangement. Very few vendors do both well, and the ones who claim to are generally strong at one and partnering for the other.

That is not a worse outcome. Two providers each doing a job properly beats one doing half of each, and the coordination cost is smaller than it sounds because the two touch at only a few points: enrolment on delivery, and release on retrieval. Define those two handoffs clearly and the arrangement works.

When You Are Ready to Move Beyond Somebody's Side Job

Covering this internally is not a failure, and a company of a hundred people with a capable operations person and standard machines can run perfectly well without buying anything.

There is also a softer signal worth watching for. When the people covering this start describing it as firefighting rather than as a task, the arrangement has already exceeded what it was designed for. That happens well before any metric moves, because capable people absorb a great deal of disorder before it becomes visible to anybody above them.

Two things change the answer. The first is when the work stops fitting in the margins of somebody's week, which usually shows up as a slow drift rather than an event: replacements taking longer, builds becoming inconsistent, nobody quite sure what is where. The second is when somebody external starts asking for evidence rather than assurance, which arrives with a deadline attached.

At that point the useful purchase is specific rather than comprehensive. Buy the part that is failing. If the gap is security evidence, a management platform addresses it without a support contract. If the gap is physical logistics, a lifecycle vendor addresses it without changing how support works. If the gap is that people have nobody to ask, an MSP addresses that and will not fix your shipping.

The companies that get the most from this category are consistently the ones who bought the narrowest version that solved their actual problem, kept their own register, and expanded later if they needed to.

Frequently Asked Questions