Crisis communications

The problem

Steady-state media monitoring is tuned for a different problem than an incident. A daily digest, a keyword alert and a weekly report are all built around the assumption that the interesting thing is rare, and during an incident the interesting thing is continuous while the questions change every twenty minutes. Who has it, is it spreading, is it spreading to outlets that matter, has our statement landed, is anyone still asking. Those are ordering and propagation questions, and the monitoring tools that serve the steady state answer them badly — they report volume, which during an incident only tells you that something is happening, which you already know.

How does a news API support crisis communications?

Work in explicit short windows and read the shape of coverage rather than its size. Two things carry most of the information in the first hours: the sequence, which tells you whether outlets are reporting independently or rewriting one another, and the outlet spread, which tells you whether the story is travelling beyond the publication that has it. Retrieve un-collapsed and sorted by publication time while you are establishing the sequence, then switch to collapsed story polling once the shape is clear and you need to know what is new rather than what exists. Keep the window explicit and written down, because during an incident several people will be looking at overlapping windows and reaching different conclusions from the same coverage.

What the workflow looks like

1. In the first hour, query un-collapsed over a window of a few hours and sort ascending, to establish who has it and in what order. If the incident is at a site, add near with a small radius around it: local outlets often name the town before they name the company.
2. Read the outlet spread rather than the count: five unrelated newsrooms is a different situation from fifty pickups of one wire item.
3. Watch the languages of the markets you operate in, not only the language of the newsroom that broke it — syndication crosses languages within hours.
4. Once the shape is established, switch to polling collapsed stories from your last-seen timestamp so the channel carries only what is new, or to a watch that runs the query server-side and posts new and growing stories to a webhook. Read outlet growth from get_story, which counts over the whole story rather than the window.
5. After a statement goes out, re-run the same query to see which outlets carried it and which are still running the original framing.
6. Keep watching after coverage stops. The absence is information, and a second wave usually looks like a fresh cluster rather than a continuation.

What will a news API not do for crisis communications?

This covers news publishers, and in the first hour of many incidents the story is on a platform rather than in a publication. If the origin is social, you will see it here only once a newsroom picks it up, which may be hours later and is sometimes never. Broadcast is similarly outside the frame except where an outlet publishes a web version. It also cannot tell you what any of the coverage means for you — outlet spread measures reach, not damage, and a single piece in a publication your regulator reads matters more than a hundred aggregator pickups. That judgement is the job; this supplies the input for it.

The mistake teams make here

The common mistake is escalating on volume. Volume during an incident is dominated by syndication, so a story carried by two hundred sites can be one newsroom's report republished, while three independent investigations by serious outlets can produce a smaller number and a much larger problem. Escalating on the first and not the second is a well-documented way to spend a crisis reassuring people about the wrong thing. The second mistake is stopping too early: coverage almost always pauses before a second wave arrives with the follow-up, the reaction or the regulator's comment, and a monitor switched off at the first quiet hour will miss it entirely.

How would you know crisis communications is working?

Run the drill before you need it. Take an incident that happened to somebody else in your sector, reconstruct it with these queries, and time how long it takes to answer the three questions that actually get asked in the room: who has it, is it spreading, and who is rewriting whom. If the answer takes more than a few minutes, the problem is usually that the queries are being written under pressure rather than kept ready. Afterwards, in a real incident, record when you knew each thing and compare it with when the coverage appeared. That gap is what the setup is worth, and it is the only number that will justify keeping it warm between incidents.

What to build in the first week

Write the queries now, while nothing is happening, and store them somewhere the on-call person can find them without reading documentation. There should be three: the un-collapsed sequence query, the collapsed polling query, and a language-scoped version of each for the markets you operate in. Fill in the subject and the window and they run. Then rehearse once on a past incident in your sector so that the person who will use them has seen what the output looks like when there is nothing wrong. The work that makes this useful is all done in advance; nothing about writing a query for the first time at midnight goes well.

What are the alternatives for crisis communications?

Full-service crisis monitoring firms provide analysts who read, triage and advise in real time, which is what most organisations actually want at three in the morning and is priced accordingly. Social listening tools reach the platforms this does not and are usually the earlier signal. Broadcast monitoring services cover television and radio, which remain the dominant channel in many markets and are entirely outside this index. This is the component that answers the published-record questions quickly and reproducibly, and it is at its best as one input beside those rather than as the system.

The queries that implement it

• Find who reported a story first — /search in hybrid mode
• Follow one story as coverage accumulates, without re-reading it — /stories in hybrid mode
• Notice when coverage stops — /stories in hybrid mode

Each recipe makes the case for its parameters. Response fields, failure modes and scheduling cost are in the technical documentation.