There are more than 18,000 police departments in the U.S, each of which must deploy and operate certain software applications to meet their primary mission of protecting and serving the public. The universal applications deployed by these agencies include computer-aided dispatch (CAD) and records management systems (RMS).
Full-service agencies will need more sophisticated applications, such as Automated License Plate Recognition (ALPR) systems or investigation software. However, approximately only one out of six of these agencies will need a jail management system (JMS).
When the JMS represents just a sliver of a public safety software company’s total revenue and customer base, it will also receive fractionalized attention in ongoing investment, product management, and research and development.
This doesn’t bode well for ad hoc products like a mobile inmate tracking application. You’ve been likely told about the depth of product synergies that exist between your current JMS and its new ad hoc mobile inmate tracking application and the virtues of its integration. And like a kid who just got an air hockey table for Christmas, or a middle-aged man who got himself a treadmill for his 45th birthday, the excitement and enthusiasm is palpable – for now.
Then, less than two weeks later, you know what happens to the air hockey table and the treadmill?
Dust starts to settle.
Weeks pass and the air hockey table is forgotten about. You’re sitting there thinking, “Crap, you’re right. I bought an air hockey table once. It was full force excitement the first weekend. Maybe two. Then nary a soul touched it.”
Same for your treadmill. It always becomes a wardrobe. Clean clothes, dirty clothes, and chip bags cover its treads. Funny how an objective brimming with promise for a brighter future just weeks earlier is already dead to you.
The reality is: your JMS’s ad hoc mobile inmate tracking application is the air hockey table.
In this blog, let’s review the four biggest risks you should expect with an ad hoc mobile inmate tracking system from your JMS.
#1: If Your JMS Has Been Neglected by Your Public Safety Software Vendor, Its Ad Hoc Mobile Inmate Tracking App Is Most Decidedly an Air Hockey Table
CAD and RMS products are the bread-and-butter for public safety software companies’ business models. They represent the largest total addressable market opportunity because the need for CAD and RMS applications is six times bigger than a JMS.
In more cases than not, the JMS is a bolt-on product to complete a public safety software suite. It may have been acquired from a smaller firm to form a suite of software. And if it wasn’t acquired, it was built as an afterthought because more than likely, your public safety software vendor was obligated to build an integrated JMS at one time for a full-service agency that needed a CAD, RMS, and JMS.
Very few companies set out to build a world-class JMS. And even fewer set out to build a world-class, ad hoc mobile inmate tracking system.
What separates a good software from a great one is often a combination of factors. For example, never underestimate an exceptional user experience (UX) and user interfaces (UI). Great UX and UI isn’t accidental or happenstance. It’s methodical. It’s rigorous testing and iteration. And like a golf swing, you can’t just copy someone else’s.
Nothing screams imposter faster than trying to mimic the way someone’s software looks and feels – just as it may be completely harmful to your golf swing to mimic the amount of side bend in Joaquin Niemann’s swing. You might like how it looks, but if you don’t understand why it’s there, you’re applying an approach that’s not fit for you.
Another factor to consider is maintaining outstanding performance under heavy loads. As an example, your JMS’s ad hoc mobile inmate tracking application is unlikely to have been deployed to a production environment for a minimum of six months to a metropolitan jail system with daily inmate counts well above 5,000 inmates across four, five, or six different jails in the system once – let alone numerous times.
And it’s unlikely that the ad hoc mobile inmate tracking application goes beyond simply fulfilling basic functionality such as rounds, movements, supplies, recreation, meals, and headcounts.
You might be thinking, “You know, I just got a demo of the ad hoc mobile inmate tracking app. It doesn’t have all the bells and whistles of Mobile Command XR, but it has similar core functions to Mobile Command XR. Your product looks better and seems easier than our JMS’s. I’m not sure what to do.”
In the case of ad hoc mobile inmate tracking apps, at best, imitation is just an indicator of lacking originality.
Case in point: below is a side-by-side comparison of Tyler Technologies’ enclosed RFID tag and a GUARDIAN RFID Hard Tag. Tyler Technologies has demonstrated a clear lack of originality in their approach, down to the exact placement and dimensions of their screw holes. Their design closely mirrors our work, resembling an unrefined imitation rather than an innovative contribution. They are not the only ones following this trend, but it’s a testament to the strength of our original 2005 design that it continues to impress newcomers even today.
Great software products not only solve problems well, but they also provide a delightful and intuitive experience that anticipates user needs and continuously improves over time.
At its worst, imitation can reflect a fundamental misunderstanding of WHY?
- Why should I force a late check justification in the moment?
- Why should I capture an image of a declined meal?
- Why should certain ways staff could describe observation checks never be permitted?
- Why is differentiating between structured and unstructured out-of-cell time matter?
Quick and Dirty App Building Can Create a Perception of Competence That’s Not There
When budgets are tight and teams are small, it’s not uncommon to build apps using tools that can pump out apps fast but may lack significant foundational features that you didn’t know to ask about (until now.)
As an example, a mobile application needs to have Internet access.
However, in certain buildings, especially jails and prisons, Internet access via Wi-Fi can be challenging due to environmental factors and construction materials. As a result, you’re going to be in an “out of Wi-Fi connectivity” range, meaning your app will have no access to the Internet intermittently throughout the day.
If your app was built low-cost and fast, the application itself may not function at all without Wi-Fi. It’s essential to know whether the application is wholly or partially dependent on Internet access with Wi-Fi. If it can’t function without Internet, meaning you can’t capture data and you can’t sync data, that should be a non-starter for you.
Conversely, Mobile Command XR is built completely from an offline first – then we incorporate Wi-Fi connectivity. So, no matter whether you’re out of Wi-Fi access for seconds, minutes, or hours, Mobile Command XR continues to operate without interruption. This is a feature called Store and Forward.
Some JMSs build their ad hoc mobile inmate tracking systems with tools like Xamarin. Store and Forward was difficult, if not impossible to achieve, with Xamarin. And now, Xamarin (which is owned by Microsoft) has been sunset. There is product support for it as of May 2024. If your ad hoc mobile inmate tracking app is built in Xamarin, you’re going to experience mid-term and long-term challenges and will likely need to change systems altogether.
Form Factor Matters
Is your JMS building an ad hoc mobile inmate tracking app for tablets? Do you prefer that? If so, stay that course because after twenty years, less than a fraction of 1% of total users prefer tablets over smartphones.
While a few times a year, we might hear an occasional complaint about needing to hold a mobile device the size of an iPhone 16. And when we do, we often think to ourselves the well-known quote from Abraham Lincoln, "You can please some of the people all of the time, and all of the people some of the time, but you cannot please all of the people all of the time."
In reality, frontline workers, such as correctional officers, should never use tablet devices in our opinion. From ergonomics and lack of durability to cost and over-engineering, some tasks that are simply better performed on a smartphone. A tablet never outperforms smaller, more portable mobile devices for frontline staff.
#2 My JMS Has Tighter Integration With Its Own Products, Right?
The true reflection of any great software company is its ease of integration with any product, whether it’s its own products working together natively, or working natively with a third-party system.
Great software supports great integration capabilities.
Command Cloud has a robust integration layer powered by REST APIs. You can call these REST APIs and build integrations in minutes or hours. So, the same level of integration can be achieved with Mobile Command XR as your JMS’s integration with its ad hoc mobile inmate tracking system.
Knowing that, you’re probably thinking next about price. Integrating Command Cloud with another application or system using our REST APIs is free. There’s no charge to build a REST API interface with your JMS.
So what are some objective measures to know if a company builds and supports its integration capabilities well? Here are four tips:
- How thorough is the REST API documentation? Does it include things like code samples, guides, and explanation of endpoints and functions?
- Does it provide pre-built connectors out of the box? The deeper the experience here, the more veracity there is to its integration might.
- Is there an API sandbox for testing? Top-tier companies provide a sandbox or testing environment where you can experiment with their APIs before implementing them in production.
- Can you customize the integration to meet your specific needs, such as custom fields, complex workflows, etc.?
#3 The Engineering and Support Resources are Typically in Short Supply
A few questions you should ask any software vendor:
- What is the total team size dedicated to its mobile inmate tracking system? Sure, anything can be built with a developer and a smartphone. But what if that one developer gets a better offer to build somewhere else? What if that developer gets sick or decides to go on vacation? As they say in the Army, one is none because one offers zero redundancy.
- Is your team in-house or is it outsourced? And if development is outsourced, is it offshore or U.S.-based? For cybersecurity reasons, if you’re needing to source technology from a SOC 2 Type 2 compliant company, there are complexities that exist making SOC 2 Type 2 compliance harder to achieve and maintain if you’re using offshore software development.
- Who will be supporting the ad hoc mobile inmate tracking app if I need help? For new software product initiatives, it’s often a company’s small engineering team that supports the product, too. This means they’re burning the candle at both ends – on both product and feature development, as well as supporting its new users – resulting in either slower innovation or software updates and patches being released less frequently, or less responsive support. You cannot have it both ways when there’s a small team responsible for both functions.
#4 You Don’t Get Many Chances to Make a Good First Impression
The wrong technology choice for your staff isn’t just a sunk loss in terms of cost – or productivity that could have been. It’s a degradation in staff confidence. It’s demoralizing – especially if they hear that a buying decision was made solely on money alone or the fact that you got something for free, like an ad hoc mobile inmate tracking application.
The challenge you’ll face is that once your team forms an initial impression, more than 50% tend to stick with it due to confirmation bias. Confirmation bias involves seeking information that confirms preexisting beliefs. So, when a low-cost, ad hoc mobile inmate tracking application fails to support store and forward capabilities, or fails to support digital evidence collection, or fails to properly sync data from mobile to JMS, each one of these issues confirms what some staff had already made up in their minds.
Unwinding a decision such as this is possible. Some staff can be persuaded to go with a different solution if you’ve made the wrong choice. But it’s always optimal to choose a proven technology first – and not one built by public safety software vendor where the JMS was already an afterthought.
Choosing a mobile inmate tracking system is an important decision to get right. You don’t get a lot of bites at the apple on these initiatives, so going with a proven vendor that has depth of experience, technology knowledge, and deep domain expertise should be the first three areas of due diligence you perform.
Public safety software companies do great work. But not surprisingly, they’re going to invest their time, money, and effort on products that have a large total addressable market, such as computer aided dispatch (CAD) and records management systems (RMS). They will build a JMS out of obligation, not passion – and certainly not total addressable market.
An ad hoc product like a mobile inmate tracking application will receive fractional support long-term – leaving you with latent regret that you made a buying decision based purely on what was low-cost or free. And in the end, you’ll have repeated the same mistake you made on your air hockey table.
.jpg)
