Escalation Workflow Automation and the Prescott Fire Tragedy

Web Site of National Interagency Fire Center

In the NYT account of the lethal fire that overcame 19 experienced firefighters near the Arizona town of Prescott, mention was made of problems some dispatchers encountered with support systems. It would seem that the Doce Fire may not have been caused by issues in the region's dispatch and call center, but perhaps those contributing factors couldn't be ruled out, either. The NYT reporters wrote,

As the Hotshots carried their chain saws to Doce’s western edge, dispatchers faced serious technical challenges. Telephone calls were being disconnected or were not going through. A computerized system that helps the dispatchers track crews was “giving all kinds of error messages,” a frustrated dispatcher said in a report logged on June 18 by the National Interagency Fire Center, a multiagency logistical support center.  

“The problem is never taken seriously and never completely resolved for the long term,” the dispatcher wrote. “This has been an ongoing problem and happens EVERY time we have an incident. It is unacceptable! We need to remain at a high operational level 365 days out of the year."

The NYT story carried a link to the web site of the National Interagency Fire Center (which seemed to be down part of the time when this blog post was being authored) where these remarks can be seen. (Such organizational transparency is laudable.) What seems to be clear from these reports is that -- whether for reasons of personnel shortage, communications with vendor(s), inter-vendor coordination or other causes -- repeated periods of substandard service levels occurred and were not adequately addressed. For time-critical business processes such as these ( the NYC 911 call center is another example), automatic escalation and remediation is needed. Such escalation should be automatic, built into the workflow software / hardware of the associated systems.

Obvious triggers: dropped calls, connect latency, call duration, repeated calls to the same recipient -- and that's without knowing anything about the particulars of the dispatching software.

Capacity-based Triggers As De Facto Enterprise Rules

Here's a de facto enterprise rule. It may be an enterprise's intentional rule, but more often than not, it's a de facto one.

RULES Customer-perceived rule: If you can't reach the sales office (Carbonite) you can't purchase the service.
Enterprise rule: If inbound sales exceeds n calls / hour, push all calls to voice mail.

From an enterprise's perspective -- the seller in this instance -- the sales office's inaccessibility may be unintentionally salutary. It limits customer volume at a time when the enterprise's infrastructure and staff may be unable to handle the volume. Of course, sales are lost, and customers must question why the sales staff is unavailable during peak daytime periods, but the enterprise rule could serve its purpose, at least as a stopgap measure during an unusual circumstance.

Later facts that came to light about Carbonite (a hosted provider of backup services) suggest that this rule may not be de facto in their case, but nevertheless a capacity-based trigger such as inbound phone sales inquiry volume remains an illustrative use case.

Risky Editorial Workflow Can Sabotage Product Evaluations

Recently a colleague attempted to post a product evaluation for Origins, an Estee Lauder brand. An initial product review submission was rejected because it mentioned a non-Estee product. After excising the offending language, the review was resubmitted. It was rejected again. My dogged colleague was determined to post a review, and requested an explanation. This time the Company said it had made a mistake, and permitted the post (after an "up to 72 hours" delay).

Workflow for editorial review of product evaluations and customer-submitted commentary may prove increasingly important, as such postings may prove long-lived, and potentially quoted and spidered far beyond the original post. Eloquent or prolific posters can be influential, with opinions that spread virally beyond the original scope. Enterprises must develop efficient but sound editorial practices to respond to product evaluations sensibly, with both transparency and consistency.

Enterprise Rules in the Heat of the Moment

The Times-Reporter relays a story about a Verizon call center refusal to help the Ohio State Highway Patrol find a man in obvious distress by using the man's cell phone signal. According to the report, the reason given by Verizon was a $20 balance due on the phone.

The story is making its way around Twitter and will reverbate in ways the Verizon workflow architect may never imagined. Those working in public /private utilities have a responsibility to plan for extraordinary and infrequent situations. When I worked in a call center for a large heating oil firm in the Northeast, this usually meant instructing agents in how to recognize such situations and, sometimes, to escalate the call.

The general rule, "Provide no service if there are unpaid bills" may be tempered by subrules that assess the longevity of the account, the amount due, or the reason for the assistance call -- and that's just a few of the possible exceptions. There may be privacy or legal issues, which the reporter in the Verizon Ohio case does not mention. Withholding heating oil deliveries in Massachusetts in February can be a matter of life or death for the infirm or elderly. This was a technique used by some delinquent customers to obtain deliveries -- which is why the workflow rules must be decided in advance, not on the spot in the heat [sic] of the moment.

Another consideration is agent training and software access to enterprise rules. A lightly trained agent on a busy day might feel it easier to follow the rule without exploring exceptions than a well-trained and well-rested agent. That said, a call from the Ohio HP should have been exceptional enough trigger another look at the Verizon rule book. Asking the HP to pay the bill in order to locate a man after an 11-hour search seems, on the surface, to merit the ridicule the Verizon is likely to receive from the re-tweets and a Slashdot post.