Crime Analysis Software Problems: The 7 That Keep Analysts in Spreadsheets, and How to Avoid Them

Why does buying a mapping platform and calling it crime analysis fail so often?

The biggest scope failure in this category is treating the map as the product. A department licenses a capable spatial platform, sends an analyst on training, and expects the weekly product to appear. Two years later the analyst is still building it by hand, because the mapping was never the bottleneck.

The work that consumes the week sits either side of the map. Extraction from the records system, which is a saved query that times out if the date range is too wide. Cleanup, which is the same recurring set of address failures every time. Filtering out reports reclassified since the last run. Grouping incidents into series when the attributes that link them are recorded as free text by officers who describe the same forced entry three different ways. Then, after the map exists, rebuilding a bulletin in a document and emailing it.

Scope the extraction and normalisation layer first and the analysis products second. That layer encodes knowledge that is specific to your agency: the way your officers write intersections, the offence code that meant two different things until a policy change, the district whose addresses carry a systematic error because of how dispatch passes location. None of that can be bought, all of it has to be encoded, and it is why a first release covering automated extraction with cleanup rules, geocoding remediation, hot spot and series analysis and the weekly meeting products runs $50,000 to $120,000 over 8 to 14 weeks in our delivery experience. That release usually gives an analyst back most of the week, which is the whole business case.

What goes wrong with geocoding and historical records data?

Every crime analysis build is downstream of records data, and records data has known, specific defects in every agency. A product that assumes clean input produces confident output from dirty data, which is the worst outcome available because it is not obviously wrong.

Geocoding is the visible part. Intersections written in a departmental format the geocoder does not expect, commercial complexes with one address and forty units, apartment blocks recorded inconsistently, and rural addressing that changed when the county renumbered. The failure is not that some records do not geocode, it is that the same ones fail every week and nobody fixes them at source. A build needs a manual resolution queue that remembers its decisions, so an address resolved once stays resolved, plus a quality dashboard showing what failed and what looks miscoded, so data problems become visible and fixable instead of silently absorbed.

Historical loading brings a second class of problem. Series and repeat analysis want depth, so departments load several years, and those years span policy changes. An offence code used for two different things until a reclassification will merge two categories in any trend you build on it. Reports amended weeks after the fact change the picture retroactively, so a hot spot computed today does not match the one computed last month from the same period. Load history with the code mappings that applied at the time, record amendment dates, and let any analysis state whether it is using the original or current classification. Silent normalisation across a policy boundary produces trends that are wrong in a way nobody can see.

Why do the records and dispatch integrations break after launch?

Access to records data is the schedule risk in these projects, and it is also where they fail after go live.

The controlling factor is how you can read the data. A read replica or a documented interface supports hourly analysis. A scheduled screen level export caps what is possible and adds fragility, because the export is a saved query owned by nobody that breaks when a field is added or a form is redesigned. If your only option is an export, expect the feed to stop at least once a quarter, and build a reconciliation that compares record counts by day against the source so a stopped feed is caught in hours rather than at the next meeting.

Computer aided dispatch (CAD) integration breaks differently and matters more, because it is the part that makes the system worth having. Pulling patrol activity, self initiated activity and where units actually were is what lets a Monday meeting ask whether the directed patrol assigned two weeks ago happened and whether the incidents in that area changed afterwards. That join is the single most valuable thing to build and the most commonly missing, and it is fragile because dispatch data models change with agency practice: new unit designators, a new call type, a shift structure change. Treat the mapping from dispatch codes to your analysis categories as maintained data with an owner rather than a one time configuration.

Records vendor upgrades are the third breakage. A major version change can alter table structures without warning to a downstream consumer, so put the vendor's upgrade calendar in your own planning and test against a staging copy before the upgrade lands, not after.

What happens when intelligence retention rules are not covered?

This is the gap that turns a software problem into a policy problem, and it is the one teams new to police work miss most often.

Criminal intelligence, meaning information about suspected criminal activity that is not tied to a reported incident, is governed differently from records. Multi jurisdictional criminal intelligence systems operating with federal funding are subject to 28 CFR Part 23, which sets requirements around submission criteria, retention review and dissemination. How the rules apply to your specific system depends on funding and scope, and that is a conversation for your agency counsel and your state fusion centre rather than a developer.

What is not negotiable is the design consequence. Intelligence records need their own store with their own retention clocks, review dates, source reliability grading and a dissemination log, and they must not be casually merged into incident analysis. Build one database holding both and you have a data model that cannot express the difference between an arrest record and an uncorroborated tip, which is a distinction that matters legally and operationally.

Retrofitting the separation means unpicking a data model that other things already depend on, so design for it from day one even if intelligence is out of scope for release one. Reserve the boundary, keep the stores distinct, and add the retention and dissemination machinery when the phase arrives. A developer who has not encountered this before will build you one table for everything, and the resulting problem will not be fixable with a permission setting.

Should you build custom or configure what you already own?

Plenty of departments should not build, and we would say so.

If you have one analyst, moderate volume and a records vendor mapping module that answers the questions command actually asks, adding a system to maintain will not help. Push the module harder first: most of them do more than the department has configured, and an afternoon with the vendor costs nothing.

If your analyst already works confidently in Esri ArcGIS, the honest position is that it is a genuinely powerful spatial platform and the analysis quality is not the problem. What it is not is a crime analysis application, because somebody still has to build the extraction, the cleanup, the recurring products and the workflow. Before commissioning a build, look at whether that automation can be scripted around the platform you already own, because sometimes it can.

Buy regional search access regardless of what you build. CrimeTracer and similar platforms reach across agencies to find a person or a vehicle, and Accurint and comparable services answer questions about people using data your agency does not hold. Both are genuinely useful and neither is a substitute for understanding your own incidents. Building that capability yourself makes no sense.

Build when analysts spend most of the week on extraction and cleanup, which is the most common situation and the easiest case to make. Build when your records data has specific known defects a generic product cannot compensate for. Build when command wants patterns connected to deployment and nothing does that today. Build when several agencies in a county want a shared picture and their records systems differ.

How do hidden costs get into the quote?

Quotes in this category are usually wrong about access rather than about analysis.

• Records access assumed. A read replica, a documented interface and a scheduled export are three different projects with three different ceilings. Settle this with your records vendor before the project starts, not during it.
• Address data quality. Whether the jurisdiction has authoritative address points changes the geocoding work substantially, and building a resolution queue that learns is real scope.
• Years of history. Series and repeat analysis want depth, and depth crosses policy changes that need code mappings and amendment handling.
• Multi agency scope. Different records schemas plus a data sharing agreement that will take longer than the code, and access controls respecting each agency's ownership of its own data.
• Intelligence handling. Retention review, source grading and dissemination logging are engineering scope, not policy documents.

The full platform adding repeat offender and association views, deployment comparison from dispatch, bulletin generation and distribution, the intelligence store with retention review and command dashboards runs $150,000 to $350,000 over 5 to 10 months.

What separates a build that works from one that fails here?

The first difference is that the weekly product generates itself. Ask a prospective developer what they would build for the accountability meeting specifically. The right answer is a product that assembles from the live data, includes what was assigned at the last meeting, and shows what happened in those areas since. If they describe a dashboard with filters, they have built business intelligence (BI) and your analyst will keep making the real product by hand every Friday afternoon, which is the situation you are paying to escape.

The second is that the loop closes. Incidents next to deployment, so the question becomes whether the response changed anything rather than what happened last week. Bulletins that generate from the analysis and reach officers on a mobile terminal, with a record of what was issued so it can be reviewed later. Series identification that groups incidents by the attributes your agency's crimes actually share rather than by a vendor's assumed taxonomy.

The third is that data quality is surfaced rather than absorbed. A dashboard showing what failed to geocode and what looks miscoded turns invisible degradation into a work item somebody in records can fix, which improves every analysis afterwards. Analysts who have spent years quietly compensating for these defects tend to find this the most useful screen in the system.

Settle ownership of the code, the pipelines and the extracted data in writing before kickoff. At Digital Heroes it is yours from the first commit. The cleanup rules encoding your agency's specific data quirks are the most valuable asset the project produces, and they must not sit inside a vendor platform. Before spending anything, have your analyst log two weeks of hours split between extracting, cleaning and analysing. Whatever the first two columns total is the return, and it is usually larger than the department expects.