Enterprise Rules

Pages

30 December 2013

You're celebrating because the firm finally embraced the holy grail of Unified Communication. Finally the telephone handset -- that perfect symbol of the pre-digital age -- can become a manageable part of the infrastructure. Outlook-to-phone, Gmail-to-Hangout or prop CTI solution? All good. Especially the links to customer and supplier contact records.

Does the schema identify which of those contact phone numbers are mobile? Turns out, that could be quite useful. The FTC's Telephone Consumer Protection Act (TCPA) went into effect in 1991, but rule changes could affect many commercial enterprises who reach out to customers or prospects. As the Marketing Research Association noted in their opinion piece on the subject:

Nearly two-fifths of American homes (38.2%) had cell phones and no landline phones in the 2nd half of 2012 – almost double since 2008. About 36.5% of all adults (86 million) lived in wireless only homes -- and the same for 45% of all children (33 million children). In addition, a sixth of American homes (15.9%) still had a landline, but received all or almost all calls on their cell phones.

The October 2013 TCPA regulation update could mandate that firms conduct phone transactions with cell phone owners differently from others. One of the clearer set of guidelines is provided by IBM SPSS. Their list concludes with this sample solution:

Federal regulations prohibit the use of autodialers for dialing cellular phone numbers. In order to comply with the regulations, an additional column (IsCellPhone for example) can be added to the Sample Table. The new column contains the values True/False, to denote which sample records are cellular phone numbers. The Sample Management Script will then need to be modified such that if IsCellPhone = True, then the number should be manually dialed, rather than autodialed by the system.

Got it. Time to tweak scripts and add a few more audit rows in case the FTC or a class action lawyer comes calling.

Conclusion: Commercial organizations may be required to use manual methods to contact cell phone numbers and to demonstrate that they have policies in place to achieve this. A rule-based solution will require mobile bits associated with each phone number.

08 July 2013

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.

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.

23 June 2009

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.

CRM and EnterpriseRules

CRM has many dimensions. The focus here is how customer interactions touch upon enterprise rules: how their behavior is affected by them, how customers influence enterprise rules, and what constraints should and should not be placed on the more dynamic forms of rule-based systems that will emerge in coming years.