How to evaluate an MDM as a Service provider for Canadian transportation and logistics

An IT Director at a national LTL carrier pulls a patch compliance report from her SOTI MobiControl console. Roughly 40% of the fleet’s Zebra TC-series scanners are running Android security patches from six months ago. Then she opens the policy templates — three of them, labelled Ontario, Quebec, and Alberta, created by an administrator who left the company 14 months ago. All three are identical.

She has an MDM platform. What she does not have is MDM operations.

This is the most common state we find when we audit a Canadian transportation fleet, and it is why the evaluation question for mdm as a service in transportation and logistics in Canada is not “which platform?” but “who is actually going to operate it, from where, and to what measured standard?” This post gives you the criteria to answer that — the specific questions to ask providers, the benchmarks to hold their answers against, and the Canadian-specific requirements that should disqualify a provider before you get to pricing.

The stakes are not abstract. The average cost of a data breach in Canada reached $6.32 million in 2024, according to IBM’s Cost of a Data Breach Report. A fleet of 800 rugged devices carrying cached proof-of-delivery data, customer addresses, and GPS telemetry — running six-month-old patches across four provinces — is carrying a meaningful slice of that exposure on every truck.

If you want the broader context on the full managed mobility category before diving into MDM administration specifically, our complete guide to managed mobility for Canadian transportation fleets covers the surrounding pillars. This post stays narrow: how to evaluate the providers who want to run your MDM environment.

Why the evaluation criteria are different for Canadian T&L fleets

The MDM evaluation guides published by analyst firms and by the MDM vendors themselves are built for knowledge-worker smartphone fleets. They assume devices live in climate-controlled offices, connect to a corporate Wi-Fi SSID, get replaced on a three-year refresh cycle, and belong to employees who stay in one province.

None of those assumptions hold for a transportation fleet.

Your devices live in −20°C truck cabs, get dropped on concrete at cross-docks, roam across three carriers’ coverage footprints in a single shift, and are handed to a different driver every few months. That last point matters more than most evaluation frameworks acknowledge. Trucking HR Canada’s labour market data shows roughly 11,220 vacant driver positions against a base of about 301,500 drivers. Every position that gets filled is a device that needs provisioning. Every driver who leaves is a device that needs wiping, re-staging, and reassignment. That churn is the baseline load on your MDM operation, not an exception to it.

These devices are supply-chain infrastructure, not productivity tools

There is a second reason the criteria differ: consequence. Transport Canada reports that 46% of Canada’s international merchandise trade moves by road, against a total trade value of roughly $1.55 trillion.

When a knowledge worker’s phone stops syncing email, they use a laptop. When a driver’s proof-of-delivery handheld stops scanning, freight stops moving and someone starts hand-writing waybills.

That difference should show up in how you weight every criterion below. Uptime is not a convenience metric in T&L. It is a revenue metric.

The state most fleets are actually in

Here is what actually happens as T&L companies grow. A carrier acquires a regional operator in Quebec. The IT team inherits a second MDM tenant on a different platform, a Bell contract alongside their existing TELUS contract, 340 devices nobody has an accurate inventory for, and a provincial privacy regime they have never had to configure for.

Nobody plans for that. It arrives with the acquisition, gets triaged for six weeks, and then becomes permanent.

The criteria that follow are built for that reality — a fleet assembled over years, running mixed platforms and mixed carriers across multiple provinces, with an IT team that is carrying MDM alongside network management, the TMS integration, and the ELD vendor relationship. Not a greenfield deployment.

SOTI MobiControl and 42Gears SureMDM — platform expertise as a baseline criterion

Ask a prospective MDM as a Service provider to walk you through how they handle a Zebra LifeGuard over-the-air security update across 800 devices using a ring-deployment model. Test group, pilot group, general availability, rollback trigger.

If the answer contains the phrase “we’d need to check with our team,” that provider has not operated SOTI MobiControl or 42Gears SureMDM at fleet scale. They have logged into a console.

This distinction is the first filter, and it eliminates more providers than any other criterion. SOTI and 42Gears dominate rugged Android fleet management in Canadian T&L. A provider who steers the conversation toward Microsoft Intune or VMware Workspace ONE within the first ten minutes is telling you where their operational depth actually sits — knowledge-worker devices, not scanners and handhelds.

What platform-level expertise looks like in practice

“We support SOTI” is a licensing statement. Operating SOTI means something narrower and harder.

It means configuring and maintaining OEMConfig profiles per device model. It means using XSight analytics to spot battery degradation before drivers start reporting dead devices at 2 p.m. It means knowing that for Wi-Fi-only rugged devices, Zebra StageNow or a QR-code enrolment flow usually outperforms Android zero-touch — because zero-touch depends on network connectivity the device does not have when it comes out of the box in a warehouse with no guest SSID.

It means having a documented ring-deployment cadence with a named rollback procedure, not a monthly maintenance window and hope.

We have written elsewhere about the operational gaps between owning an MDM licence and operating it at scale. The short version: the console will keep showing green long after the floor has stopped agreeing.

Independent ratings — SOTI versus SureMDM for T&L use cases

Independent ratings are a useful input, and an incomplete one. They tell you about the platform. They tell you nothing about who operates it.

That said, the G2 head-to-head comparison shows genuinely different strengths: SOTI scores 9.5 on device enrolment against SureMDM’s 8.8, while SureMDM leads on ease of use at 9.0 versus 8.4 and on quality of support at 9.1 versus 7.8. On Capterra Canada, SureMDM averages 4.77 out of 5 across 22 reviews, with SOTI MobiControl at 4.37 across 26.

What you should take from that: neither platform is the default answer. A credible provider asks about your fleet composition, your enrolment volume, and your internal team’s comfort level before recommending one — and is willing to tell you that your current platform is the right one to stay on.

The provider who can only administer one platform

Many T&L fleets run both. SOTI for the rugged scanner fleet that came with the subsidiary acquisition. SureMDM for the tablets the operations team bought independently two years ago because procurement was faster that way.

A provider who can only administer one platform is a provider who will eventually ask you to consolidate. That means re-enrolling every device, rebuilding every policy, retesting every application, and coordinating a fleet-wide cutover across cross-docks that run overnight.

That is a six-figure project wearing the costume of a service transition. Ask early. Ask which platforms they hold current certifications on, how many clients they administer on each, and whether they have ever run a client on both simultaneously.

Multi-province policy enforcement — the criterion most providers cannot demonstrate

A driver’s Zebra TC53 crosses from Ontario into Quebec three times a week.

In Ontario, the employer must maintain a written Electronic Monitoring Policy under Section 41.1 of the Employment Standards Act, disclosing who is monitored, when, and with what technology. In Quebec, Law 25 (An Act respecting the protection of personal information in the private sector) requires explicit consent and a documented Privacy Impact Assessment before deploying a monitoring system. In Alberta and British Columbia, the Personal Information Protection Act requires notice.

The MDM policy governing that tablet should change based on where it operates — or, at minimum, the policy architecture must default to the most restrictive provincial requirement across the fleet. A single national template does neither.

Province-by-province requirements that translate into MDM configuration

These are not legal abstractions. Each one becomes a specific configuration decision in your console.

Ontario’s Section 41.1 requirement means your MDM location-tracking policy must match what your written Electronic Monitoring Policy actually discloses. If the policy says tracking is limited to working hours and your SOTI location profile polls every 15 minutes around the clock, you are non-compliant with your own disclosure document — and that document is the first thing an investigator asks for.

Quebec Law 25 is the sharper one. It requires a documented Privacy Impact Assessment before you deploy or materially change a system that collects personal information, and it carries penalties reaching $25 million or 4% of worldwide turnover. For a mid-sized carrier, that ceiling dwarfs the annual cost of outsourced MDM administration by an order of magnitude. The operational question for your provider is whether they can produce templated PIA documentation for a fleet device programme, or whether every policy change routes through outside counsel at your expense.

Alberta and BC PIPA notice requirements are lighter, but they still require that drivers be told — which means a distinct consent flow at enrolment, not a shared one.

The OPC trucking precedent every T&L IT Director should know

This is where multi-province policy architecture stops being best practice and becomes enforcement history.

In PIPEDA Findings #2021-008 and #2022-006, the Office of the Privacy Commissioner investigated Canadian trucking companies over in-cab monitoring and found always-on audio recording in truck cabs unreasonable under Section 5(3) of PIPEDA. The reasoning matters more than the outcome: collection has to be proportionate to the purpose, time-limited, and consented to.

That is a configuration standard. It means your telemetry policies need defined collection windows, defined retention, and a documented rationale — and it means PIPEDA is not a background consideration for your industry. Federally regulated transportation companies are explicitly named in its scope.

The question that settles it

Here is the question to put to every provider on your shortlist: “Show me the policy templates you use for a fleet operating in Ontario, Quebec, and Alberta simultaneously.”

If they show you one template, they have not done this before.

If they show you three and can explain the consent-flow differences between them without checking notes, they have. And if they can also explain how a device reassigned from a Mississauga cross-dock to a Laval terminal gets moved between policy groups — automatically, based on the device group, not by someone remembering to do it — you are talking to a provider who has actually operated a multi-province fleet.

Which brings us to the operational side of the equation. Policy architecture protects you on paper. What protects the freight is who answers the phone at 1 a.m. when 60 scanners drop offline mid-shift.

Canadian support desk SLAs — what the numbers should actually be

Every MDM as a Service provider claims 24/7 support. The slide decks all say it. The contracts all include it.

The evaluation question is not whether they claim it. The question is where their support staff are located, what language they speak, and what their measured performance is on a P1 incident at 2 a.m. Eastern when 60 scanners just dropped their Wi-Fi profile mid-shift at a Mississauga cross-dock.

SLA benchmarks worth demanding

Here are the numbers you should be writing into your evaluation scorecard.

P1 incidents—fleet-wide outages or security events affecting more than 10% of devices—should have a 15–30 minute response target, around the clock. Not acknowledgement. Response by someone who can actually do something.

First-call resolution should exceed 90%. If your drivers are being bounced through three tiers of support before someone remotes in and fixes the problem, your SLA is a formality.

Calls answered within 60 seconds for at least 80% of contacts. US-based provider Stratix publishes 84.5% of calls answered within 60 seconds and 93.1% first-call resolution. Use those as comparison benchmarks—then ask the critical follow-up.

Why “Canadian-based” is a procurement criterion, not a preference

The follow-up question is: where are the people achieving those numbers located?

When a support agent remotes into a fleet device to troubleshoot a scanning failure, they are accessing GPS history, app usage data, cached delivery records, and potentially customer names and addresses. Where that agent sits determines which country’s laws govern that access.

This is not theoretical. CIRA’s 2025 cybersecurity survey found 69% of Canadian organisations cite data sovereignty as the most important factor in vendor selection, and 56% have reviewed their use of US-based vendors in the past year. For federally regulated transportation companies—explicitly named in PIPEDA’s scope—support desk location is a compliance decision, not a convenience preference.

The operational version of this plays out at 1 a.m. A logistics company running overnight cross-dock operations calls their MDM provider because scanners are failing to authenticate. The provider’s US-based support desk routes the call to a tier-1 agent who has never configured a Zebra OEMConfig profile. Three hours later, the shift supervisor is hand-entering package data into a spreadsheet. That is what a support desk SLA gap costs in T&L.

Carrier-agnostic MDM management across Bell, Rogers, and TELUS

A national LTL carrier operating in all ten provinces almost certainly has devices on at least two of the three national carriers. Bell in Ontario and Quebec, TELUS in the West, Rogers filling gaps where the other two have weaker coverage on northern routes.

This is not poor planning. It is the reality of Canadian geography. Coverage variability—particularly on routes through northern BC, Alberta, and Quebec where only one carrier may have signal—drives multi-carrier strategies.

Your MDM as a Service provider needs to manage device profiles, SIM assignments, and policy enforcement across all of them without structurally favouring one carrier’s ecosystem over another.

Carrier-managed MDM programmes — what they offer and where they stop

TELUS Managed Mobility Services and Bell Enterprise Mobility Management are legitimate options. They offer deep integration with their own network infrastructure, established 24/7 support operations, and simplified procurement for devices on their SIMs.

For fleets that operate primarily on one carrier, with device mixes that are predominantly smartphones, these programmes deliver genuine value.

The limitations are structural. Carrier-managed programmes provide the deepest visibility into their own network and less depth on cross-carrier device management, rugged-device OEM expertise beyond what ships with standard Android Enterprise profiles, and MDM platform flexibility—TELUS historically partnered with AirWatch/Workspace ONE when the programme launched in 2012.

What carrier-agnostic management actually requires

“Carrier-agnostic” is not a philosophy. It is a capability set.

It means reconciling device inventory against SIM inventory across all three carriers—matching enrolled MDM devices to active billable lines and surfacing the mismatches. It means managing eSIM profiles for coverage optimisation on routes where only one carrier has signal. It means surfacing zero-use lines regardless of which carrier bills them.

During initial device-to-SIM reconciliation audits, we routinely find 8–15% of billable lines that do not match any enrolled device in the MDM console. Devices that were decommissioned, lost, or reassigned, but whose SIM lines were never cancelled. A carrier-managed programme will surface this for its own lines. A carrier-agnostic provider surfaces it across all carriers simultaneously—and that is where the cost recovery actually lives.

Rugged device OEM expertise — Zebra, Honeywell, and the OEMConfig gap

Enrolling a Zebra TC58 scanner into SOTI MobiControl is not the same as enrolling a Samsung Galaxy S24.

The scanner requires OEMConfig profiles for beam width, scanning mode, peripheral pairing, and enterprise browser configuration. It requires DataWedge profiles for barcode parsing. It requires Zebra LifeGuard patch management that follows a different cadence than standard Android security updates.

Without those configurations, the device is enrolled but not operational. The MDM console shows compliant. The driver is standing at a cross-dock trying to scan a pallet label with default settings that cannot read a Code 128 barcode at arm’s length.

Patching workflows that matter — Zebra LifeGuard OTA

Zebra publishes two security-only updates and one maintenance release per quarter through LifeGuard for Android. That is a different patch cadence than Google’s monthly Android security bulletins, and it requires a different deployment workflow.

A credible MDM as a Service provider should have a documented ring-deployment process: test group, pilot group, general availability, with defined rollback triggers. Ask to see their LifeGuard deployment history for a current customer. Not the process document—the actual deployment log showing when patches were pushed and to how many devices.

Here is why this matters operationally. A Zebra LifeGuard update once broke a specific barcode symbology configuration on TC52 devices running a particular version of DataWedge. The fix was a profile adjustment in OEMConfig, not a rollback of the entire update. A provider without deep Zebra OEMConfig expertise would have rolled back the patch—leaving the fleet unpatched for weeks—rather than applying the targeted fix in hours.

Data residency and Canadian sovereignty — beyond the checkbox

When a support agent remotes into a driver’s tablet to troubleshoot a scanning issue, they can see GPS history, app usage, and potentially cached delivery data including customer names and addresses.

Where that agent is located, and where the MDM console they are accessing is hosted, determines whether that data is governed by Canadian law or by the laws of another jurisdiction.

What “Canadian data residency” means operationally

There are three components to verify, and most procurement teams only check one.

Console hosting: where the SaaS MDM tenant actually lives. SOTI Cloud can be deployed in Canadian Azure regions. 42Gears SureMDM Cloud has Canadian hosting options. But “can be” is not the same as “is”—confirm in writing which data centre your tenant will reside in.

Support tooling: where the ticketing platform, remote access tools, and analytics dashboards live. A provider can host the MDM console in Canada but route all support tickets through a US-based Zendesk instance—creating a data residency gap in the operational layer.

Operational access: where the humans who touch the data are located. Canadian-hosted infrastructure accessed by staff in another country is not Canadian data residency. It is Canadian data storage with foreign access.

78% of Canadians refuse to have their personal data hosted outside Canada, according to an OVHcloud/Léger survey. For federally regulated transportation companies, that sentiment is also law—PIPEDA explicitly covers federal works, undertakings, and businesses, including interprovincial trucking.

The question to ask: produce a data-flow diagram showing every system that touches device data—MDM console, ticketing platform, remote-access tool, analytics dashboard, backup infrastructure. If any of those systems are hosted outside Canada or accessed by staff outside Canada, the provider’s data residency claim has a gap you need to understand.

What good looks like — a reference architecture for Canadian T&L MDM operations

If you cannot answer these five questions about your current MDM operations, you do not have managed MDM. You have a licence and a login.

The five operational indicators

1. Patching cadence: Monthly Google security patches applied within 30 days of vendor release. Zebra LifeGuard updates ring-deployed within a defined test/pilot/GA cadence with documented rollback triggers.
2. Policy architecture: Distinct templates per province, with documented consent flows for Quebec and electronic monitoring disclosures for Ontario. Device reassignments between provinces trigger automatic policy group changes.
3. Device-to-SIM reconciliation: Enrolled device count matches active SIM count within 2%—audited quarterly. Mismatches are investigated and resolved, not carried forward.
4. Incident response: Documented playbook aligned with the Canadian Centre for Cyber Security’s baseline controls, including the specific Mobile Device Security control area. The playbook has been tested in the past 12 months.
5. Visibility: Real-time fleet dashboard showing battery health, signal strength, app versions, and enrolment status—not a monthly PDF report that arrives three weeks after the month closes.

Questions to ask every provider on your shortlist

These are the questions designed to reveal operational depth—or expose its absence. Copy them into your next vendor call.

• Walk me through your ring-deployment process for a Zebra LifeGuard update. Who approves the rollout from pilot to GA, and what triggers a rollback?
• Show me a sample multi-province policy architecture for a fleet operating in Ontario, Quebec, and Alberta simultaneously. Explain the consent-flow differences.
• What is your measured first-call resolution rate for the past 12 months—not your target, your measured rate?
• Where are your support desk staff physically located? Can I speak with a French-language agent right now?
• Show me a device-to-SIM reconciliation report from a current customer. What percentage mismatch did you find at onboarding?
• Describe the most recent P1 incident you managed for a T&L customer. What went wrong, and how long did resolution take?
• Produce a data-flow diagram showing every system that touches device data. Where is each system hosted?
• What is the handover process if we terminate the contract? Who owns the MDM console and the data in it?

The most revealing question is the one about the last failure. A provider who cannot or will not answer it has either never managed a fleet at scale or is not being transparent about their operations.

How PiiComm approaches MDM as a Service for Canadian transportation and logistics

The evaluation criteria above are designed to be provider-agnostic. Here is how PiiComm, Canada’s largest pure-play managed mobility services provider, maps against them—and what you should verify independently.

Platform expertise — SOTI and 42Gears certified administration

PiiComm is certified on both SOTI MobiControl and 42Gears SureMDM, and supports VMware Workspace ONE and Microsoft Intune for mixed environments. MDM as a Service (MDMaaS) transfers day-to-day operational administration—policy configuration, app deployment, compliance monitoring, incident response—to certified, Canada-based administrators.

The MDM platform stays the same. The staffing model changes.

Canadian operations — staging, support, and data infrastructure

PiiComm operates its own Canadian staging and deployment facilities, a 24/7 bilingual (English/French) service desk staffed in Canada, in-house certified technicians, and Canadian-hosted data infrastructure. No core operational function is outsourced or offshored.

The company manages 500,000+ devices across thousands of locations—scale that has produced the operational patterns, the policy templates, and the reconciliation findings that inform every onboarding.

Rugged device heritage — Zebra Premier Partner, Honeywell, Samsung

PiiComm holds Premier partnership with Zebra Technologies—the highest partner tier—plus partnerships with Honeywell and Samsung. The company’s heritage is in rugged, industrial-grade enterprise mobility: scanners, handhelds, vehicle-mounted computers, RFID systems.

This is not a smartphone MDM provider that added rugged devices as an afterthought. PiiComm’s managed mobility for transportation and logistics is built on 15+ years of operational delivery for Canadian carriers, freight operators, and aviation companies.

Carrier-agnostic management and wireless expense visibility

Cross-carrier visibility comes through ClearSight TEMs AI—Canadian-built, bilingual output, Canadian carrier invoice parsing—and the AIM portal for real-time fleet visibility. These tools support the carrier-agnostic management criterion: device-to-SIM reconciliation across Bell, Rogers, and TELUS simultaneously, with anomaly surfacing that does not favour one carrier’s billing format over another.

PiiComm’s T&L operational references include deploying mission-critical devices to thousands of flight crew across Canada and transitioning a road transportation fleet from frequent device failures to full fleet reliability in six weeks. These are operational references—and you should ask for direct reference contacts as part of your evaluation.

Realistic alternatives and how to compare them

The Canadian MDM as a Service landscape includes carrier-managed programmes, Canadian independent providers, US-based managed mobility specialists, and the option of keeping MDM administration in-house. Each has genuine strengths and genuine limitations.

Carrier-managed programmes (TELUS, Bell)

Strongest for organisations whose fleet operates primarily on one carrier and whose device mix is predominantly smartphones. Deep network integration, established support infrastructure, simplified procurement. Less flexible on MDM platform choice and cross-carrier visibility for multi-carrier fleets.

US-based managed mobility providers

Stratix is named as a Representative Vendor in the 2025 Gartner Market Guide for Managed Mobility Services and publishes strong SLA benchmarks. The trade-off for Canadian T&L buyers: data and support operations typically reside outside Canada, creating PIPEDA data residency considerations and potential gaps in bilingual support and provincial regulatory expertise.

In-house MDM administration

Viable for fleets under 100 devices in a single province with a dedicated MDM specialist on staff. The breakeven typically favours outsourced MDM as a Service once the fleet exceeds 250 rugged devices distributed across two or more provinces and requires 24/7 SLA coverage. One Canadian senior IT administrator FTE costs roughly $90K–$130K loaded; true 24/7 coverage requires 3–4 FTE rotation at $400K+ annually—before you account for recruiting, turnover, and the compliance expertise required for multi-province policy architecture.

Frequently asked questions

What MDM platforms should a Canadian T&L provider support?

At minimum, SOTI MobiControl and 42Gears SureMDM—the dominant platforms for rugged Android fleet devices in Canadian T&L. Providers should also support Workspace ONE and Microsoft Intune for mixed environments. G2’s independent comparison shows both platforms have distinct strengths; a credible provider advises on fit rather than defaulting to one.

What SLA benchmarks should I expect from a Canadian MDM as a Service provider?

P1 incidents should have a 15–30 minute response target, 24/7. First-call resolution should exceed 90%. Calls answered within 60 seconds for at least 80% of contacts. Critically, verify these numbers are achieved by staff located in Canada who can support in both English and French—not just claimed in a capabilities slide.

Why does data residency matter for MDM in Canadian transportation?

PIPEDA explicitly covers federally regulated transportation companies. MDM consoles log GPS coordinates, app usage, and device telemetry—all personal information under Canadian law. Where that data is hosted determines which country’s laws govern access. 69% of Canadian organisations now cite data sovereignty as the most important factor in cybersecurity vendor selection.

How do I know if my current MDM is being properly managed?

Check three things: when the last Android security patch was applied across your fleet, whether your policy templates vary by province, and whether your enrolled device count matches your active SIM count. If any answer is “I don’t know,” your MDM is running on autopilot, not being managed.

Can an MDM as a Service provider manage devices across Bell, Rogers, and TELUS?

A carrier-agnostic provider can. Carrier-managed programmes typically provide deep visibility into their own network but limited cross-carrier management. For T&L fleets operating across multiple carriers—which is most Canadian T&L fleets—carrier-agnostic management is essential for full fleet visibility and accurate device-to-SIM reconciliation.

What does multi-province MDM policy enforcement actually involve?

At minimum, maintaining distinct policy templates for Ontario (ESA Section 41.1 electronic monitoring disclosure), Quebec (Law 25 consent and PIA requirements), and BC/Alberta (PIPA notice requirements). A single national policy template is a compliance liability. The OPC has specifically investigated Canadian trucking companies for fleet telemetry practices.

How long does it take to onboard an MDM as a Service provider for a T&L fleet?

A typical onboarding for a 500-device fleet takes 30–60 days, including device-to-SIM reconciliation, policy architecture review, analytics configuration, and ring-deployment testing for the first patch cycle. Providers who promise instant onboarding are skipping the audit—which surfaces six figures in cost savings more often than not.

What is the difference between MDM as a Service and managed mobility services?

MDM as a Service (MDMaaS) transfers day-to-day MDM administration to a specialist provider. Managed mobility services (MMS) is broader—it includes MDMaaS plus strategic sourcing, staging and deployment, lifecycle management, and certified secure decommissioning with NIST 800-88 data erasure. MDM is one component within MMS.

Making the decision

The evaluation framework in this post is designed to be used in your next vendor conversation. Print the questions from the section above. Bring them to every call.

The provider whose answers are specific, verifiable, and anchored in Canadian T&L operational experience is the provider worth shortlisting. The provider who pivots to pricing before you have verified their operational depth is the provider whose true cost will reveal itself 18 months from now—when you discover that patching cadence, policy architecture, and device-to-SIM reconciliation were never actually happening.

Your SOTI console will keep showing green either way. The question is whether what it shows matches what is actually happening on the floor at your cross-docks and in your drivers’ trucks.

The devices are already mission-critical. The programme supporting them should be too.

Talk to a PiiComm mobility expert about your fleet’s MDM requirements. Contact PiiComm →