The device naming problem announces itself clearly at scale. You open the MDM dashboard, and the device list reads like a series of random strings: iPad, iPad (2), iPad (3), Samsung-A8-unknown, ANDROID-4F2C. You need to find the self-ordering kiosk at the downtown Chicago location that is showing an offline alert, and there is no fast way to identify which entry in a list of 200 devices corresponds to that specific unit.
This is a preventable problem, and the solution is straightforward: a consistent device naming convention defined before the first device is enrolled and applied uniformly across the entire fleet.
A good naming convention is not about aesthetics. It is an operational tool. The right format tells you instantly what a device is, where it is, and what it does, without requiring a separate lookup or a call to someone at the location. When an alert fires at 2 AM, the person responding should be able to read the device name in the notification and immediately understand the full context of what they are dealing with.
What a Device Name Needs to Communicate
Before building the format, define what information needs to be encoded in the name. The right answer varies by organization, but the most operationally useful naming conventions typically encode four elements:
- Location identifier: Which site, store, facility, or region the device is deployed at
- Device type or use case: What the device does, such as kiosk, POS terminal, signage display, or handheld
- Platform or hardware: Which operating system or hardware type, particularly important in mixed iOS and Android fleets
- Unit number: A sequential identifier that distinguishes multiple devices of the same type at the same location
Together, these four elements give anyone looking at a device name in the Moki dashboard or in an alert notification the full context needed to act without additional investigation.
Building the Format
The most practical naming formats use short, standardized codes for each element separated by a consistent delimiter. Hyphens work well because they are readable, compatible with most systems, and do not create issues in exports or integrations.
A format that works for most multi-location deployments looks like this:
[LOCATION CODE]-[DEVICE TYPE]-[PLATFORM]-[UNIT NUMBER]
Applied to real devices, this produces names like:
- CHI-KIOSK-AND-01 (Chicago location, kiosk, Android, unit 1)
- CHI-KIOSK-AND-02 (Chicago location, kiosk, Android, unit 2)
- CHI-POS-IOS-01 (Chicago location, POS terminal, iOS, unit 1)
- NYC-SIGN-BS-03 (New York location, signage display, BrightSign, unit 3)
- DAL-HH-AND-07 (Dallas location, handheld device, Android, unit 7)
Every element in this format is immediately readable, the location is the first thing visible when scanning a list, and the sequential unit number makes it easy to identify a specific device at a location with multiple units.
Defining Location Codes
Location codes should be short, unique, and standardized across the organization. Three to five characters works well for most deployments. Common approaches include:
- City abbreviations for single-location-per-city deployments (CHI, NYC, DAL, LAX)
- Store or facility numbers for organizations that already have an internal location numbering system (STR001, FAC042)
- Regional plus sequential numbering for organizations with many locations in the same city (MW001, MW002 for Midwest locations)
The critical rule is that location codes must be unique. Two locations with the same code create ambiguity that defeats the purpose of the naming convention. Maintain a master location code registry, even if it is just a shared spreadsheet, so new locations are assigned a code before any devices are enrolled there.
For organizations managing devices across multiple industries or business units, adding a business unit prefix can help distinguish device contexts at a glance: RET-CHI-KIOSK-AND-01 versus HC-CHI-KIOSK-AND-01 for retail versus healthcare deployments in the same city.
Defining Device Type Codes
Device type codes should reflect the functional role of the device rather than the hardware model. Common codes that cover most deployments:
- KIOSK for self-service customer-facing kiosks
- POS for point-of-sale terminals
- SIGN for digital signage displays
- HH for employee handheld devices
- TAB for general-purpose managed tablets
- CKIN for check-in terminals in healthcare or hospitality contexts
- WFIND for wayfinding displays
Keeping these codes short and consistent across the organization means anyone who works with the fleet understands them without a reference guide.
Defining Platform Codes
Platform codes identify the operating system or hardware platform, which is particularly valuable in mixed fleets where troubleshooting steps differ by platform:
- AND for Android Enterprise or Android Agent devices
- IOS for iOS supervised devices
- BS for BrightSign players
In a homogeneous fleet where only one platform is in use, the platform code can be omitted to keep names shorter. In any mixed-platform environment, including it is worth the extra characters.
Applying the Convention in Moki
In Moki’s MDM platform, device names are set at enrollment and can be updated remotely without touching the device. For new deployments using zero-touch enrollment, device names can be set as part of the enrollment configuration so each device arrives with the correct name already applied. For existing fleets being brought under the new convention, names can be updated in bulk through the dashboard.
The device name should also be recorded in your physical asset inventory alongside the serial number and location, creating a two-way lookup: you can find the Moki device record from the serial number, and you can find the physical device from the Moki dashboard entry.
Device Groups and Naming Work Together
Device naming and device grouping are complementary. The naming convention tells you exactly which device you are looking at in any context. The group structure determines which devices receive which configurations and updates. When both are set up consistently, the fleet is navigable at any level of detail: you can look at a single device’s status by name, or look at all Chicago kiosks as a group, or look at all Android signage displays across all locations.
Building the naming convention and the group structure in parallel, before enrollment begins, gives you an organized fleet from day one rather than trying to impose structure on a fleet that has already grown organically into chaos.
Handling Edge Cases
A few naming edge cases come up consistently and are worth addressing in the convention documentation before they cause inconsistency:
- Replacement devices: When a device is replaced, the replacement should receive the same name as the device it replaces, not a new sequential number. The name belongs to the role and location, not the physical hardware.
- Temporary deployments: Devices deployed for a short-term purpose, such as an event or seasonal installation, should be identified as temporary in the naming convention, for example by adding a T prefix or TEMP suffix, so they are easily identified for decommission at the end of the deployment.
- Shared devices: Devices shared between locations or moved regularly should reflect their primary assigned location in the name with a note in the MDM record indicating the mobility.
Documenting these edge cases in the device deployment playbook ensures consistent decisions across the team over time.
The Payoff
A naming convention is one of those investments that feels minor at the start and becomes increasingly valuable as the fleet grows. At 10 devices it is convenient. At 100 it is important. At 500 it is the difference between a manageable operation and a dashboard full of strings that no one can interpret quickly under pressure.
Schedule a Moki demo to see how device naming and fleet organization work in the platform, or start a free trial to begin structuring your device fleet from the ground up. Moki’s support resources are available to help with fleet organization best practices during onboarding.