Portals: Opening the lines of communication

This post is the fourth in a series about building portals for teams and groups to interact with customers. If you’re interested in reading more please follow us on twitter or subscribe in the right-hand margin of this blog —>

At this point you’ve got a website up, and your communicating to your customers, which is adding value and improving their experience.

Now they want more – what’s next?

Again “it depends” and I certainly have my opinions, but consider your users first and ask questions (as noted in the second post in this series).

Let’s tell a story.

You’re a customer of a company. They missed your garbage pick up this week. You go to their website. On said website there is a big banner or pop-up that says “We are experiencing a one-day delay in garbage pick ups” and offers the number to customer service.

What do you think about this experience? Pretty good right? This is basically where a portal begins; one-way communication with the option to initiate further. It’s a stepping stone to two-way communication.

There’s a reason this exists – because communication is a two-way street. So usually, I recommend giving your customers a voice. It makes them feel valued and listened to.

Now, depending on your culture, needs, audience size and web platform this could take many forms. Maybe you add a chat option so that users can chat with agents or fulfillers or staff directly. Maybe you need a webform? Maybe you just display a phone number call.

Something, anything that allows two way communication will greatly improve the portal’s value and demonstrate compassion for customers.

The chat option is the most advantageous because it also provides a universal “out” for customers who are stuck, can’t find something or just have a simple question.

Remember to design this for the customer. Test out multiple methods of conversation, and continue the dialog and feedback loop.

Next post will be about content! Subscribe in the right margin or follow us on twitter for updates!

Portals: How to get started?

This post is the third in a series about building portals for teams and groups to interact with customers. If you’re interested in reading more please follow us on twitter or subscribe in the right-hand margin of this blog —>

When we look at the common needs of users of portals there are always trends, fads and basics. I prefer to start with the basics and keep options open.

Remember that the goal of a portal is to make people happy. So how do we start doing that?

Most portal projects jump way ahead into the future. They go straight to “we want to be like amazon” or some other phrase like this.

The reality is, you can’t afford to be like amazon AND unless you’re in retail, your goals do NOT align. Your number one priority should be happiness for your customers and your providers. I’ll use these terms going forward to describe the people viewing your portal, but do keep in mind they can be the same.

The most obvious and noticeable feature of all portals is communication.

This is even true for amazon – as soon as you go there, they tell you buy something.

What does your portal say?

We often don’t communicate well as a group because communication is difficult and people delude themselves into thinking it’s simple. Portals start like a mouth, or a brand. This may be the first time anyone sees or notices your group exists, the first interaction they’ve ever had with your team!

So what do you want them to think?

You know what I want and are ready to give me what I want.

If you can convince your customer of this, on their first interaction; congratulations, you have reached success.

How did you get here? Understanding the customer. How did you understand them? By listening to them (most likely) – or maybe you were one once. That last one is a doozie – don’t let your experience cloud your vision. Always go back to the customer and base your decisions on data.

So, the easiest way to start a portal is to get a webpage set up. And post a message to your customer. Something along the lines of:

Hi, we’re (insert group/team/person name here),

You’re here for __________, and we have ____________.

Here’s how you get __________:

And that’s it. Follow up with instructions on how to get it.

No fancy technology. No $3m project. No integration, no automation… nothing.

And already your customer has value.

Next post: adding value to a simple portal.

Building IT Portals – what have we learned?

I was honored to lead a roundtable discussion at HDI Minnesota yesterday. Topics ranged from hiring practices to career paths for agents. Very involved discussion with a ton of experience and leaders in the room.

I loved being there and listening.

The topic I was ‘leading’ (which means asking questions) was on IT portals. Mostly every support team had a portal along with the challenges exist that have always existed.

However, I think our industry and software in general has come a long way to understanding the shortcomings of portals, adoption and experience.

I started off the session by asking who had a portal. And some hands flopped around uncomfortably. Maybe they don’t think their portals are good enough to call them portals.

One leader offered up his story about using Sharepoint as a portal and what that meant to the sharepoint service (when we upgrade we have some issues with our portal).

Several people noted that posting critical information on the portal was a huge win for both communication and contact avoidance.

Someone else noted that Knowledgebase access was a great feature to have (totally agree) – and went on to shock me that they even allow a forum feature for people to simply discuss anything (very innovative IMHO).

Then I asked the difficult question “what do your customers think about it?”  – – crickets.

“I don’t want another password” is what one end user cited for not using the portal.

Over the next weeks I will outline some of the heavy topics involved in department portals. I’m not going to focus on IT though, because I believe this is a challenge that all many-to-one relationships have. Meaning that any department, team, group, organization, or organization can learn from other groups’ failures and challenges to build an app to improve interaction, collaboration, service, and experience.

Subscribe in the right-hand margin to follow along ->

Or follow us on twitter to read as they are posted.

Better Service Visibility = Better Delivery!

Service disruption occurs when change and release management collisions occur.

How do we prevent these collisions from occurring in the first place?

Even the most sophisticated teams are subjected to these problems; why?

No matter how much planning and automation you have, there are still outages!

Now the service desk is getting hammered with calls and a VP is irate over not being able to reach his “key” system. No one is happy. The world is on fire!

We planned. We strategized… We have GREAT tools! We have GREAT PEOPLE! We AUTOMATE!!!

Why? Why me? Why us?

While you may have planned accordingly, followed the good practice handbook to the letter and thought you understood the decisions in the CAB, you still had collisions. Why?

Because you made decisions based on incomplete information.

There are MANY systems of record that hold critical information related to service delivery. That information is often not all in a single database — such as your ITSM system.

Vacation and business event information? It’s in your messaging system (Exchange).

Customer specific case information? It’s in your CRM (Salesforce.com).

Release information? It’s in your ITSM system (ServiceNow).

If key data related to change/release decisions is not all in the same system, the effort to correlate it may be painful and time-consuming, but; ultimately it is worth it if service is improved. Figure out how to get it correlated — even if it is a spreadsheet. Reduce the risk by knowing what is what.

calendar-video-preview-1
1:56 — A demonstration of a unified calendar view.

We built Kinetic Calendar to enable real-time visibility into key data from multiple applications. it’s more important than ever to be able to cross reference data from those systems. Request a free demo here.

Your Next ITSM Tool Should be Neither

TL,DR; decouple IT operations from customer service and development. Then realize the incredible savings and benefits thereof.

The term “ITSM” has always bugged me, and I think I know why.

The primary customer of ITSM is IT; everything else is lumped into “customer service” and “customer experience”.

ITSM_WikiEven Wikipedia says there are too many “fluff words” and that ITSM has an unclear definition.

But in IT, we know better. We understand what we’re talking about when we say Service Management. It’s a standard way of operating so we don’t fail.

So why would any business person buy Service Management?

To keep the lights on.

“But that’s what we hired you for! We don’t care what you call it. We don’t want to buy it, we want you to DO IT!”

Then I’ll need $1.5m every three years to replace my tools, redesign processes and…

Wait, $1.5m? Don’t you remember when last year we were managing changes via email? Don’t you remember the spreadsheets of Assets? Why $1.5m?

Technology has become complex and our colleagues want to reduce risk. Some also want to understand the value and depreciation of assets. ITSM is just IT Operations Management + Customer Service.

DING DING DING DING DING DING – we have a winner! Here’s your $1.5 million. But why every three years?

Think of ITSM tools like a car lease. Three years comes along, and it’s time for a fresh smelling one, the latest one with all the bells and whistles.

Do the bells and whistles keep the lights on?

No.

Then why keep upgrading and rebuilding your operations empire?

The tools and practices that surround Service Management change, and they change often.  Have you considered who benefits from that change?

Consider separating your systems of operation from your systems of service. It gives you the freedom to change platforms without impacting your customers.

The impact of this is far greater than you realize. We believe in building systems of engagement separate from systems of record. To understand the nature of this problem:

 

systems-of-recordDoes this image describe your problem? If so, you’ll be interested in understanding our approach to enterprise software. Read more here, or just call us directly: 1-651-556-1030

Be a Provider… NOT a Broker!

At Kinetic Data we’ve been talking for years about Service Integration and Automation (SIAM) and building software products to enable Service Providers to deliver at scale.  Understanding the SIAM concept has real value for enterprises looking to achieve successful delivery where service models are distributed across fulfillment silos, and customer experience is of paramount importance.

For Shared Service IT organizations, most have an understanding of the Handshake above 2brokering concept with respect to infrastructure delivery.  In this context, the brokering concept is often referred to as the Hybrid Cloud infrastructure model. In this model, Corporate IT is typically the central provider of infrastructure services, while the actual components making up deployed technology stacks live both internally (corporate data centers) and externally (partner provided, Cloud-based data centers).  Often, Corporate IT may involve many back-end partners in providing those infrastructure components.

At a high-level, the Service Brokering concept appears to solve challenges associated with delivering enterprise IT service in the complex world of today’s global economy. In this model, services are made up of component functions where fulfillment tasks are sourced to provider-partners responsible for delivering their individual part.  While this may seem like a broker model, the reality is that if you view things from the customer’s perspective, the “Service Broker” concept doesn’t make sense at all.  

When I think about my experiences with brokers, some are great and some are not.  Regardless of how good the broker, I’ve ended up (as the customer) having to directly interact with downstream providers to resolve issues related to the service I’ve procured.  I’ll spare the gory details, but offhand I can think of examples with healthcare, investments, house-buying and home repair that make up my experiences.

Each time an issue came up in the delivery of a complex service (home-purchase) and I had to get involved in solving them, it was time-consuming, costly and frustrating. More than once, I decided that regardless of how good the broker was in my initial interaction, I would not use them for the same service in the future as it was easier for me to handle things directly with the downstream provider.  That’s an anecdote for IT outsourcing if you are keeping score at home!

Ultimately, the underlying issues with all of any of these challenging “Service Broker” experiences I have lived were due to the difference between my perception and the reality of the service model I was procuring.

As a customer, I expected an experience where the service being provided was truly integrated end-to-end regardless of who was doing the fulfillment.  What I got was a disparate and distributed service experience that was notintegrated and left me looking for an alternative provider for the future.

So, with respect to Enterprise IT and the idea of “Service Brokering”, think about:

  • A customer procures (requests or buys) a service and expects delivery of it, not just “part of it”.
  • That customer has an expectation (SLA) for that service with corporate IT.  It’s not the customer’s responsibility to coordinate sub-contractor agreements (OLA’s) between back-end fulfillers that comprise the component Sub-Services, nor is it their interest to have any complexity added to their experience.
  • They don’t care if Vendor A is responsible for Sub-Service 1, and Vendor B is responsible for Sub-Service 2.  All they want is simple access to the service and a great experience in it’s delivery.   

If there’s an issue with a downstream fulfillment by Vendor B, it’s ridiculous to expect a customer to care about a missed OLA or further, to get involved in the resolution of a stalled service.  When they come to get service from Corporate IT, they expect a great experience by a Service Provider, not a Service Broker.

If you understand what goes into end-to-end service delivery where there is afocus on customer experience, Service Brokering is nothing more than marketing-speak. Another attempt by industry vendors to try to re-label what already exists and sell it to you as “new.”  The multi-sourced delivery model has existed for decades.  It is not new, and there are real Service Providers out there that truly understand the value of Service Integration in driving excellent customer experience!


Remember:  What matters most is customer experience.  Be a ServiceProvider NOT a Broker!

Trying is Everything

How are we going to solve this problem?

It’s impossible to know all the possible solutions to a given problem, and the more complex the problem, the more possible solutions there may be.

Nothing inspires me to grab my toolbox more than problems that need solving. How do you add solutions to your toolbox? How do you hone your skills in applying those tools?

This is why trying is everything.tools

Without the upfront work of experience and trying things, you may not know which tool is sharpest, or the best fit for problem.  In tech work this means trying lots of things, platforms, technologies and approaches to applying those technologies. It means talking to people who have tried lots of things and connecting to people who carry a bigger toolbox or sharpened tools.

Get involved in communities, join meetups focused on solutions and try everything!

Ready to try something new? Join our hackathon: http://developer.kineticdata.com/hackathon

Higher Ed Service Catalogs: Six Top Questions Answered

While CIOs across industries are grappling with new threats and opportunities presented by revolutionary technological change, those who work in college and university settings face unique challenges.

Top questions about higher ed service catalogsWriting on LinkedIn Pulse, Tracie Bryant notes than in addition to common CIO challenges like budgeting, strategy, and training, higher ed CIOs must also address issues like scaling up bandwidth to handle “the booming popularity of online classes,” and implementing an advanced technology infrastructure to attract the best and brightest students and faculty (as well as donations).

Continue reading “Higher Ed Service Catalogs: Six Top Questions Answered”