Picture the week before a big festival in Bihar. Your travel and local-news desk is busier than usual: readers want train timings, road advisories, temple queue tips and market hours, all at once. Then the booking form freezes, or the page that lists ghat timings stops loading. Within minutes the group chat has forty messages, three people are “fixing” the same thing, and nobody has told readers anything. This is the moment where a small idea called IncidentOps earns its keep, and it suits a regional travel desk as comfortably as a large engineering group.
Think of this post as a diagnosis. We will name the symptoms you probably recognise, trace each one to a cause, and suggest a fix that fits a small team with a phone full of chat groups instead of a command centre.
What IncidentOps means for a travel desk
In plain words, the term describes how a team responds when something unplanned breaks a service people rely on: spotting it, calling it an incident, deciding who leads, keeping people informed, and talking it through afterwards. According to the Ops Atlas, this is a loose, informal name for what most people call incident management, so please do not expect a certification or a rulebook. What you get is a handful of habits borrowed from emergency services and large technology companies, and those habits translate surprisingly well to a desk that publishes guides to Bihar’s heritage sites. If you want the longer reference, the Atlas entry on IncidentOps lays out the scope, including what it deliberately leaves out, such as planned maintenance and attacker-driven events.
Symptom one: nobody is sure whether it is “really” a problem
The first stall is almost always hesitation. Someone notices that the ticket-price page shows last month’s numbers, but the thought is “maybe it is just my phone”. Ten minutes pass. Then an hour. The cause is not laziness; it is the absence of a written trigger.
The fix is to agree, once and in writing, what counts as an incident. The Atlas points to a simple style of criteria: another team is needed to help, readers can see the fault, or the issue is still unsolved after roughly an hour. For your desk that could read: “A page readers depend on is wrong or down, or two people are needed to fix it.” When the rule is written down, calling an incident stops being a judgment about anyone’s competence. A small incident that turns out to be nothing costs a few minutes. A late call costs hours, and in festival week hours are expensive.
Symptom two: too many hands on the same page
The second symptom is the pile-on. The editor, the developer and the person who manages social posts all log into the content system and start changing things. Someone reverts a change that someone else just made. Fixes collide.
Here the cure is to separate roles from job titles. The Atlas describes roles as hats: whoever wears the coordinator hat decides and organises, but does not touch the fix. Only the people in the hands-on group change production. Everyone else supports. On a desk of six, that might look like this:
- Coordinator: keeps the picture, assigns work, decides when to escalate. Does not edit pages during the incident.
- Fixer: the one or two people allowed to change the site or booking settings.
- Voice: writes the messages readers and partners see.
- Note-taker: records what happened and when, so nobody has to rebuild the timeline from memory.
One more detail from the Atlas is worth copying: the coordinator is whoever holds the hat for this incident, not automatically the most senior editor. In some frameworks the person with the highest rank on the call takes the role, but it is meant to be rotated and practised, not inherited.
Symptom three: readers hear nothing
The third symptom hurts the most for a public-facing travel site. The team is busy inside, and outside there is silence. A traveller planning a pilgrimage circuit sees a broken page and no explanation, then moves to another site.
The remedy is a communication rhythm. Technology teams commonly aim to post a first message within about five minutes of declaring the incident, follow with a scoping update soon after, and then keep updates coming at least every twenty minutes through the first two hours. That sounds strict, but a message can be very short: “The ghat timings page is not loading. We know about it and are working on it. Next update in twenty minutes.” Status tools usually give four plain labels, Investigating, Identified, Monitoring and Resolved, and borrowing those four words gives your readers a shared vocabulary. When it ends, say so clearly, and if any bookings or saved plans were lost, say that too.
If you are rebuilding your own planning content in the meantime, a lightweight packing guide such as our checklist for visiting historic shrines and ruins can be temporarily pinned as a useful page while the broken one is repaired, which keeps readers engaged instead of bouncing.
Symptom four: the chat group becomes a crowd
The fourth symptom is the one every volunteer team knows. The chat grows to dozens of members, the important message scrolls away, and the people actually working retreat into a private side chat. The Atlas cites field research showing exactly this pattern in large technical incidents: crowds of observers push the core group into hidden channels, which then defeats the purpose of having a shared record.
The fix is to use two spaces. One is a working channel for the few people involved, kept tidy. The other is an updates channel where the voice posts summaries that everybody else can read without chiming in. Observers are welcome in the second, not the first. If a senior person turns up and starts directing, the simple polite question from technology teams applies: ask whether they want to take over the coordinator hat. Either they say yes and the handover is explicit, or they step back and let the current coordinator work.
Symptom five: the fix works, but nobody knows why
Sometimes the problem disappears and the team never feels certain. This is where the “stabilise first, explain later” principle helps. Generic moves such as rolling back to the previous version of a page template, switching off a new feature, or moving to a backup route call for knowing roughly which part is misbehaving; nobody has to understand the whole story yet. Hunting for the perfect cause before acting keeps readers waiting longer. Once the page is back, the deeper question gets its own calm review.
Symptom six: the same mess happens again next season
The last symptom is repetition. Festival after festival, the same page breaks and the same chaos follows. A good review, held within a few days while memories are fresh, fixes that. A few habits from the Atlas help: decide who runs the review while the incident is still open, keep the follow-up list short, and attach a single name and a date to every item. Avoid ending the review at “someone made a mistake”. Stop at the conditions that made the mistake easy, such as a form with no confirmation step or a template that nobody had a backup for.
For a desk that also covers operations topics, our overview of reliability engineering for growing operations teams is a natural next read, since reliability targets and incident routines support each other.
A starter plan you can adopt this week
- Write a three-line definition of “incident” for your desk and pin it where everyone can see it.
- Name four hats and keep a one-page card for each.
- Create an updates channel and decide who normally posts there.
- Choose a repeating twenty-minute update rhythm and practise it on a dull Tuesday, not on festival eve.
- Hold a fifteen-minute review after the next hiccup, with an owner and a due date on every action.
You do not need pricey software for any of it. What helps is a small agreement among friendly colleagues, and the courage to say “this is an incident” early. That is the whole spirit of IncidentOps, and it will help your Bihar guides stay online precisely when travellers need them most.
