Crime Analysis and Intelligence Software: Getting Off the Weekly Spreadsheet Before the Pattern Goes Stale

Monday morning, and the pattern is already old

The analyst starts Friday afternoon. Export from the records system, which is a saved query that times out if the date range is too wide. Open it in Excel. Fix the addresses that did not geocode, which is the same three hundred every week because the intersection format the department uses is not what the geocoder expects. Filter out the reports that were unfounded since last week. Build the map. Pull the field contacts. Cross reference the two burglary series manually because the modus operandi field is free text and one officer writes pry marks while another writes forced rear door.

Monday at 8am the command staff meeting sees a map of the previous week. The map is accurate and it is already history, because the pattern it describes has been running for ten days and the offender has moved. Nobody in the room can say what the department did about last week's pattern either, because the deployment side of the conversation is a lieutenant describing what he remembers assigning.

The analysis is limited by your records data, not by the tool

This is the part vendors do not say out loud. Every crime analysis product is downstream of the records system, and records data has known, specific problems in every agency: geocoding failures at intersections and commercial complexes, offence codes applied inconsistently between shifts, free text modus operandi fields, name records that hold the same person three times, and reports amended weeks later so the picture changes retroactively.

A product that assumes clean input produces confident output from dirty data, which is the worst possible outcome because it is not obviously wrong. The real work in this category is the extraction and normalisation layer: knowing that your agency writes intersections in a particular format, that a specific offence code was used for two different things until a policy change in 2022, that reports from one district carry a systematic address error because of how the CAD passes location.

That knowledge is agency specific. It cannot be bought, it has to be encoded, and it is why an analysis build usually pays for itself before it produces a single map.

Where Esri ArcGIS, CrimeTracer and Accurint stop

• Esri ArcGIS is a genuinely powerful spatial platform and many analysts do excellent work in it. What it is not is a crime analysis application. Somebody still has to build the extraction, the cleanup, the recurring products and the workflow, and in most departments that somebody is the analyst doing it manually every week.
• CrimeTracer and similar search platforms are strong at reaching across agencies to find a person or a vehicle. They are not built to run your weekly accountability product, to track whether a pattern was addressed, or to model your own deployment.
• Accurint and commercial data services answer questions about people using data your agency does not hold. Useful for an investigation, not a substitute for understanding your own incidents, and they come with their own policy and audit considerations.
• Records vendor mapping modules generally show incidents on a map with filters. They rarely support series identification, they do not connect the pattern to the response, and they inherit the records data quality problems without acknowledging them.
• None of them close the loop. The question a chief actually wants answered is whether the deployment decision made after last week's briefing changed anything, and that requires joining incidents with patrol activity, which no product does for you.

Intelligence data is regulated differently than incident data

One design point that trips up teams new to this work. 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.

The practical consequence for a build is that 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 your incident analysis. Confirm how the rules apply to your specific system with your agency counsel and your state fusion centre, because the answer depends on funding and scope. But design for separation from day one, because retrofitting it means unpicking a data model.

What a custom build has to include

The extraction layer first, running automatically and often rather than weekly, with your agency's specific cleanup rules encoded and a quality dashboard showing what failed to geocode and what looks miscoded, so data problems become visible and fixable instead of absorbed by the analyst.

Then the analysis products the department actually uses. Hot spots computed properly rather than by eye, series identification that groups incidents by the attributes your agency's crimes actually share, repeat address and repeat victim identification, and offender association built from your own arrest, field contact and incident data rather than from a commercial database.

Then the deployment side, which is the differentiator. Pull patrol activity, self initiated activity and where units actually were from the CAD, and put it next to the pattern, so the Monday meeting can ask whether the directed patrol assigned two weeks ago happened and whether the incidents in that box changed afterwards. That is the conversation accountability meetings are supposed to have and almost never can.

Then distribution: bulletins that generate from the analysis rather than being rebuilt in a document, delivered to the officers who need them and readable on a mobile data terminal, with a record of what was issued so it can be reviewed later.

And a clear line between analysis and intelligence, with separate storage, retention review and dissemination logging for the latter.

What it costs and how long it takes

Our delivery experience: a first release at $50,000 to $120,000 in 8 to 14 weeks, covering the automated extraction with cleanup rules, geocoding remediation, hot spot and series analysis, and the recurring products for the weekly meeting. This is the phase that gives an analyst back most of the week, and it is where we tell most departments to stop and use the system for a quarter before scoping more.

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

Cost drivers: whether your records vendor will provide a read replica or an interface, because screen level exports cap what is possible and add fragility. The state of your address data and whether the jurisdiction has authoritative address points. How many years of history you load, since series and repeat analysis want depth. Multi agency scope, which brings different records schemas and a data sharing agreement that will take longer than the code. And any intelligence handling, which brings retention and audit requirements as engineering scope.

When buying is the right call

Buy if you have one analyst, moderate volume and a records mapping module that answers your questions. Adding a system to maintain will not help.

Buy access to regional search platforms regardless of what you build. Reaching across agencies for a person or a vehicle is a genuinely different problem and building it yourself makes no sense.

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

How to choose a developer

Ask them what they would do about the three hundred addresses that fail to geocode every week. A developer who has done this will ask to see them, will talk about intersection formats, address point authority and a manual resolution queue that learns. A developer who says the geocoder handles it has not looked at police data.

Ask how they will get data out of your records system, by name. A read replica, a documented interface and a scheduled export are three different projects, and the answer determines whether your analysis runs hourly or weekly.

Ask how they would separate criminal intelligence from incident analysis, and whether they can describe why that separation exists. If the concept is new to them, they will build you one database and you will have a policy problem rather than a software problem.

Ask what they would build for the weekly accountability meeting specifically. The right answer is a product that generates itself, includes what was assigned last week, 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.

Ask who owns the code, the pipelines and the data, in writing before kickoff. At Digital Heroes it is yours from the first commit. Before you spend anything, have your analyst log their hours for two weeks split between extracting, cleaning and analysing. Whatever the first two columns add up to is the project's return, and it is usually more than the department expects.