The first time a multi-location business deploys a device fleet, it is usually reactive. A need arises, hardware is procured, someone configures it, and it ships. The second deployment is faster. The tenth deployment starts to surface all the things that were never standardized. By the fiftieth location, the lack of a formal process has created a fleet with inconsistent configurations, undocumented setup procedures, and no clear owner for what happens when something goes wrong.
A device deployment playbook fixes this. It is the documented, repeatable process that tells every person involved exactly how a device goes from a box at a warehouse to a fully configured, remotely managed endpoint at a live location. When it is built well, your deployment speed increases, your configuration errors drop, and your ongoing device management becomes predictable instead of chaotic.
Here is how to build one.
What a Device Deployment Playbook Contains
A playbook is only useful if it is specific enough to follow without asking questions. Vague guidance produces inconsistent results. A good device deployment playbook covers six core areas:
- Hardware standards and procurement
- MDM platform configuration and enrollment method
- Device configuration profiles and kiosk or lockdown settings
- Content and application deployment
- Testing and go-live verification
- Ongoing management and escalation procedures
Each section should be detailed enough that someone who was not involved in the original deployment can use it to replicate the process accurately at a new location.
Step 1: Define Your Hardware Standards
Before you can deploy consistently, you need to standardize on hardware. This does not necessarily mean every location runs identical devices, but it does mean every device type is documented with a clear use case.
Questions to answer in this section:
- What device types are approved for each use case (POS, signage, kiosk, employee handheld)?
- What OS versions are supported and what is the minimum hardware specification?
- Which resellers or procurement channels are authorized, particularly if you intend to use zero-touch enrollment or Apple Business Manager?
- What accessories (cases, mounts, cables, power supplies) are part of the standard kit?
Locking down procurement to approved channels is especially important for zero-touch enrollment, since devices must be purchased through zero-touch compatible resellers to be registered in the provisioning portal before shipping.
Step 2: Document Your MDM Configuration Profiles
This is the core of the playbook. Your MDM platform should have named configuration profiles for each device type and use case. The playbook documents what each profile contains and why.
For each profile, document:
- Which apps are installed and which version
- Kiosk mode or lockdown settings, including which app is the locked app and what URL restrictions are in place
- Wi-Fi, VPN, and network configuration
- Security settings (passcode policy, encryption requirements, screen timeout)
- Alert thresholds (battery level, offline duration, app crash triggers)
- Content or media files that need to be present on the device
Moki’s features let you configure all of these settings from the dashboard and save them as named profiles that can be applied to individual devices or entire groups. The playbook should reference which Moki profile name applies to which location type or use case, so there is no ambiguity during deployment.
Step 3: Define Your Enrollment Process
Your enrollment method determines how a device gets from factory default to fully configured. Document which method applies to each device type:
- Zero-touch enrollment (Android): Device is pre-registered in the Google Zero-Touch portal and enrolls automatically on first power-on. The playbook should include the steps for registering a device in the portal and linking the correct Moki configuration profile before the device ships.
- Apple Business Manager or Apple School Manager (iOS): Device is purchased through an authorized channel and appears in the ABM portal automatically. The playbook documents how to assign a Moki MDM server token in ABM and assign devices to the correct profile before activation.
- Manual enrollment: For devices that cannot use automated provisioning, document the step-by-step process for manual enrollment into Moki, including which account credentials to use and which profile to apply.
The goal is for anyone following the playbook to be able to complete enrollment correctly the first time without needing to ask for help.
Step 4: Establish a Testing Checklist Before Go-Live
A device should never be shipped to a live location without a documented verification step. Your playbook should include a go-live checklist that confirms the device is fully operational before it reaches the field:
- Device is enrolled in Moki and visible in the dashboard
- Correct configuration profile is applied
- Kiosk mode or lockdown is active and confirmed
- All required apps are installed and launching correctly
- Wi-Fi connects automatically at the target network (if testable in staging)
- Alerts are configured and a test alert has been triggered to confirm they fire
- Device label or asset tag is recorded in the MDM platform for inventory tracking
- Remote control access has been verified (for Android and BrightSign devices)
Building this checklist into the playbook and requiring sign-off before a device ships creates a quality gate that prevents misconfigured devices from reaching customers.
Step 5: Document Ongoing Management Procedures
Deployment is not the end of the playbook. The document should also cover what happens after devices are live:
- How app updates are pushed and on what schedule
- How content updates are handled for digital signage or kiosk deployments
- What triggers a device replacement and how replacement devices are provisioned
- Who receives MDM alerts and what the escalation path is when a device goes offline
- How a device is decommissioned or wiped at end of life
This ongoing operations section transforms the playbook from a one-time deployment guide into a living document that governs the full device lifecycle.
Step 6: Assign Ownership
A playbook without ownership gets ignored. Every section should have a named owner or team responsible for maintaining it. As your fleet grows, your hardware standards change, or your MDM configuration evolves, someone needs to update the playbook to reflect those changes.
For multi-location businesses using Moki, the typical ownership structure looks like:
- IT or operations team owns the MDM configuration profiles and enrollment procedures
- Marketing or operations owns content updates and signage profiles
- Procurement owns hardware standards and vendor relationships
- Store or location managers own the local go-live checklist execution
Putting the Playbook to Work
Once your playbook is documented, the next deployment is faster, the next troubleshooting call is shorter, and onboarding a new location becomes a checklist rather than a project. Every additional location you open benefits from the work done to build the playbook the first time.
Moki’s platform is built to support the kind of standardized, scalable deployment process a playbook describes. If you are building your device deployment playbook and want to see how Moki’s configuration profiles, zero-touch enrollment, and remote management capabilities fit into that process, schedule a demo. You can also explore Moki’s case studies to see how other multi-location businesses have structured their device deployments, or start a free trial to begin building your profiles today.