How to Write an RFP for MDM Solutions (with Examples)

When crafting an RFP (Request For Proposal) for mobile device management (MDM), you need to balance the competing concerns of hardware and software. While the devices themselves were the top priority in days past, today, the ability to deploy software (apps, AI models, security patches) is a major concern for any operator of a device fleet, especially at scale. Automation is a major facet of modern device management, and not every MDM solution is architected to help you grow and innovate your fleet.

Background and Overview: Where Am I Right Now?

It’s crucial to describe the state of affairs for your device fleet as it exists now. Are you at the QA stage? Have you selected your hardware? Are you trying to migrate an existing fleet to a new device management platform? Here’s how to describe your device management background in a way that a solution provider can understand.

• What is your business?
• Why are you seeking a device management solution?
• Do you have devices in the field today?some text
  • If yes, are you seeking to migrate those devices to a new device management solution?
  • If not, what stage of device deployment are you at? Prototyping? Hardware selection? Procurement? Field testing? Ready to deploy?
• What do you do (or want to do) with these devices?

At this stage, there’s no need to get very technical, but you should be trying to tell vendors a story: Who am I, why am I looking for help, and what’s the situation on the ground?

Project Scope: What Are My Technologies and Scale?

While most device management and MDM solutions can work at large scale, the type of hardware and operating systems they support — and to what degree — vary considerably. This is why it’s important to be as specific as you can about the composition of your fleet. As part of the project scope, you should include:

• How many devices you will need to manage (both today and into the future).
• The operating systems those devices will run (be specific — e.g., do you mean Android with Google services, or Android AOSP? There’s a big difference!).
• Where those devices will be deployed (also important: will they have consistent internet connectivity?)
• The type of device — exact hardware models are best, but at least the OEM and form factor, if you have them.
• Your use case for the devices. How will the devices be used, and by whom?

Goals: What Outcome Do I Want?

This one sounds simple, but it’s vitally important to be very clear and very specific about the objectives your device deployment needs to meet. If you need to enable a self-checkout retail scenario for customers in your stores to increase customer transaction volume and lower operational costs, your device management solution needs to support and drive you toward those outcomes. Here are some examples of goals that would be relevant to device management solutions.

• Lower technical support ticket volume for devices in the field by X%
• Automate deployment of X% of devices in the field
• Reduce device kitting costs by X%
• Increase fleet deployment count X% by 202X
• Roll out new AI model to devices every X days
• Achieve >X% uptime for devices in the field

Goals don’t have to be numerical, either — they can simply be about meeting a milestone or completing a project successfully. But don’t be afraid to sound demanding at this stage, because goals are the touchstone you should always be returning to when evaluating a device management solution. If a vendor can’t concretely demonstrate how their solution maps to achieving one of your mission critical goals, that should be a pretty big red flag.

Current Roadblocks: What Issues Do I Currently Face?

Similar to goals and outcomes, it’s important to highlight any current roadblocks either with your current MDM, trialing existing MDMs, or anything in between. This is an opportunity to really dig into any and all issues you and your team current face with device management. Some common examples: 

• Application management: Delivering and managing content on edge devices
• System updates and other software deployments: Pushing OTA updates or security patches to the edge, especially in batches 
• Provisioning: If you manually provision devices or it requires significant time, simplifying this process
• Missing features or functionality: Maybe you need remote access to devices, need a better way to lock devices down, etc. 
• MDM support: Not all MDM providers prioritize support for everyone outside of their biggest customers, causing issues for many organizations

Like most other pieces of this puzzle, there’s no one-size-fits-all answer to this question. Bring up all your pain points! 

Technical Requirements: What Do I Need?

This section, despite often being the most detailed, needs the least explanation. You know better than anyone what features are critical to me? This is where all the nitty-gritty must-haves go.

Separately, the preferred functionality is where you can put your it-would-be-nice-to-have (or straight up pie-in-the-sky) features and functionality. There’s no harm in asking!

Evaluation Criteria: Why Should I Pick You?

The evaluation criteria section considers all of the previous sections and creates a formula for the ideal vendor. For example, “Our ideal vendor must support AOSP Android and Linux, offer remote control for both, and cost under $25,000 per year at a scale of 2,500 devices.” The evaluation criteria is a space to list reasons you’ve rejected past vendors, too, or why you’re leaving your current one. Enumerating your disqualifying factors can be just as important as qualifying ones.

The evaluation criteria is also a good venue for voicing your values and priorities. Do you care about having a good one-to-one relationship with your technical account managers? Do you prioritize companies that can close deals quickly? Do you need help selling a device management solution? Do you need always available remote control access? Geofencing? Support for a legacy operating system distribution? Onsite management server deployment? Security or other compliance guarantees? Device support lifetime? Resources to sell a solution up to a leader in your organization? Would the ability to sign a separate deal for an unrelated project increase the chance of selection? The evaluation criteria section is where you get to be the rock star with a tour rider — tell the vendor what they need to give you to make this process easy and straightforward.

Timelines and Milestones: When Does It Need To Be Done?

This section is about as straightforward as it gets. You can provide time ranges, but it’s good to be specific about the timeline for a few milestones, specifically.

• RFP window: When do vendors need to submit quotes?
• Vendor selection: When do you need to pick a vendor?
• Contract close: What is your deadline to sign? How long do contracts typically take at your org?
• Deployment start: When do you need the first devices in the field (or existing devices migrated)?
• Deployment finish: When should deployment (or at least, the first round of deployments) be complete?

Again, the more specific you can be about time, the more serious you’ll appear to vendors. Being vague or non-committal with dates can mean you’ll get vague and non-committal responses to your RFP. If it’s clear you’re serious about needing a solution, vendors will be a lot more serious about that solution’s suitability to purpose and what it will cost.

Start Your RFP

You can get started with your device management RFP using our easy-to-fill form right here. It’s formatted just like this post, so you can go section by section and in the same order as the content above.