If you're just joining in on the discussion of combining the rich deposits of personal data and social history that we're creating every day with technology for more effective communication, you might want to take a look at some of my earlier posts:

Part 1: Introduction

Part 2: Location

Part 3: Location privacy

What exactly is a social graph?  It's essentially a digital representation of all the relationships that we have online, explicit or implicit. What makes the social graph truly powerful though is that it's not just a repository of connections. In the most mature deployments, it's something that includes other information about all the interconnected people and can be queried by other systems.

What does all that mean? A version of your social graph cobbled together from all the services that you use would reveal family relationships, friendships, professional connections, shared interests, places where you get together with friends, birthdays, favorite movies, what time you're likely to be online, what products you like, and lots more.

If you're not yet convinced, consider the 3 largest sets of social graphs and what they might reveal about you: Facebook (750 million users), LinkedIn (100 million users), and email services (2 billion users).

Like most things, this powerful information can be used to provide innovative new services that individuals would want and gain benefit from, or they can be used badly to annoy, violate our privacy, and in ways that are just plain wrong.  If you're interested in the negative responses to growing use of social graphs, just search for "<company name> privacy controversy" and you'll find lots to work with.

For the purposes of this post, we'll try to stay focused on the good side of all of this information and go through a couple of use cases where social graph represents critical information about a person that allows them to receive and be a part of relevant communications.

Emergency Management

With earthquakes, fires, tornados, typhoons, and heat waves in headlines all over the world, there has been no shortage of disasters to put emergency management and communication to the test.  Where social graphs can be invaluable in communicating under these circumstances are the links that they provide between people.  If one of my coworkers evacuates a building safely with me, and we can provide that update into our social graphs, the natural clustering effect in our relationships will ensure that most people who would want to know that we are OK, will get that information.  Our professional graph through LinkedIn or an Enterprise 2.0 system knows about other coworkers & managers; through common Facebook connections our friends and family can be updated.

And that's for the simplest cases.  If you don't know someone's name who has been injured, the social graph can first help with identification.  Do you know where they work? Where they live?  What school they attend?  All of those are starting points to query a broader set of graphs to first identify the person and then notify the people who would want to know their status.

The social graph could also be a means of authenticating and determining who can see what information about me.  In the event of an emergency, I would be OK with providing transparent updates to my Facebook friends, it would be great to share some basic information with my LinkedIn connections, and may be share tagged updates with my Twitter and Google+ followers.

Customer Communications

Outside of targeted advertising (which is always a lightning rod for controversy), once you've done business with a company a few times, it might actually make sense to share limited access to your social graph with them.  Why?  The assumption here is that once you've done business with them you might want to trust them with more information about you so that they can help you make better decisions for the products & services that they offer.

Here's a personal example: I am terrible at remembering birthdays, anniversaries, and just about any other important dates in my life and those of my friends and colleagues.   I do however have all this information close at hand IF i remember to go looking for it - in Facebook, Plaxo, LinkedIn, Email threads lies all the information that I can never remember myself.  As an Amazon Prime customer, I buy lots of stuff there.  They also have a great recommendation engine.

Combining those things together, I would love to have a service delivered by a combination of Amazon & my social graphs that tells me when a special occasion is coming up and also based on that person's published interests/likes/dislikes/recent activity, what I might want to get for them.  The system would have to be tune itself based on my feedback of course for things like who gets a card, an actual present, an email, a FB wall post with a virtual present, and so on. 

It's a win-win situation.  Amazon gets me to buy more products, and I don't get in trouble for forgetting things. 

Other use cases

There is certainly no shortage of innovative services that crop up every week looking to take advantage of this wealth of information.  Whether it's advertising, movie recommendations, discovering new music, finding the next career opportunity, personalizing news content, picking classes in college, looking for help with homework, getting your writing proof read, reporters looking for sources, finding the hot new restaurant, picking up on style trends, just about any service you can think of benefits from a little social flavor.

A word of caution though, if you really want to make sure that you're exposed to new things, social graphs have to be diverse enough to avoid the dreaded Filter Bubble.

Stay tuned for the next post in the series as we continue exploring the impact (both good and bad) that personal data & social history have on our quest to better target communications.

And on a final note, if you'd like to join any of my social graphs, here's where to find me on a few services:

Twitter

LinkedIn

Google+ (click here if you need an invite)

I sign up for pretty much everything to try it out and consistently use "abbashaiderali" as my username.

Abbas Haider Ali.

image credit: SWAT Labs

One of the things that surprised me at DRJ this year was what seemed to be a trend for professionals placing all of their communication strategy on voice call outs. I understand the initial charm of voice communications. It is still a relatively special communication channel compared to the junk emails and SMS messages we receive throughout the day. The truth is that we still pay attention to a ringing phone, so it is a great communication channel.

However, there are a few key things to think about:

Voice is a very reliable network - up to a point. When a major disaster occurs there is immediately a huge call volume increase caused by local callers and long distance callers checking in on their loved ones. To further complicate issues, a little known government program known as the Telecommunications Service Priority ("TSP") pops into effect to reserve call capacity for national security and emergency preparedness organizations - that means there is less available capacity for corporate usage. (You can read more about the TSP here: http://tsp.ncs.gov/). The net-net is that the telephone system literally runs out of capacity to route calls. When that happens, your call is greeted with a "All circuits are busy, please try your call again later..." type of message. And we aren't talking about an isolated situation - Nick DeSimone tells me that he gets this message every year trying to call his mom on Mother's Day!

Nick also mentioned another good point... a large majority of our customers jump on conference bridges as part of their incident management process. If the only channel used to push out incident updates is voice, they won't be able to receive the update call without performing some sort of call-waiting magic to answer the call containing the update. Most people won't know how to do it without dropping off the conference bridge, and a number of the people that do will have hold music broadcasting into the conference bridge while they take the update. Yikes.

The moral of the story? Voice is a key component of processes, but it would be foolish to only use voice call outs in your processes.

Update: a friend of mine just sent me this related story from Wired... it does an even better job (darn you Wired) of describing the telco's challenges in what they ironically call an "unexpected Mother's Day event": http://www.wired.com/wired/archive/9.12/mustread.html?pg=2

Nothing like a quick wake up call to remind us of how tricky our jobs can be:

Ooops sorry, U of I scares 87,000 people with false alert - mass notification at its worst

Of course accidents will happen, but now would be a good time to double check who can do what in

your messaging kitchen.

To support your efforts, we are putting the finishing touches on some new security options for scenarios in the xMatters on demand environment. Historically our security options have supported setting top level edit/test/run permissions at a Role level for each scenario. Our new improved security goes more granular across both the permission settings and the initiator settings.

What this means is that in your planning you can determine not only who should kick it off, but should they be able to modify the message contents. Or the response options. Or the recipients. Or a ton of other things. And these settings are available on a plan by plan basis. Good stuff! Check it out:

The initiators can now be defined at a Role level, a User level, or combinations of both, and you can see at a high level if they have no, All or Custom permimssions:

Here you can see the typeahead (I LOVE THE TYPEAHEAD) in action displaying both Roles and Users:

And lastly, here is the view showing the added granularity of permissions which can be granted for each scenario where each of the "Editable on Launch" checks corresponds with a section of our scenario launch screen:

And remember you can define this differently for each scenario if you like!

The features you see here will be available in early June for xMatters on demand clients, and will also be shipped in our 5.0 product (delivery date not available yet).