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!

In the beginning…

tl,dr: all business processes start somewhere, whether data, event or request driven. That simple goal is the starting point of request process improvement.

I just need to collect people’s email addresses to get started.

I get into a lot of solution conversations with my friends. This is consulting 101, but there’s more on the line when I’m personally invested in this person.

There are other challenges too, when it’s personal there’s usually a cost prohibitive budget, a.k.a. no cash on hand.

So when someone asked me how to collect information and “get started” a lightbulb went off!

All processes start somewhere.

pexels-photo-28554It appears that almost all business processes come down to a click. An order. A bit. A byte. SOMETHING; whether it be data or a request, something triggers a business response.

Can we then assume that the best software gets this?

When I asked this, I re-asked it a couple times before I realized this was the value IT was providing. Particularly when it refers to Enterprise Architecture.

The decisions you make about the puzzle you are composing with technology investments influences your ability to react to information and events.

Which is why good architects and business analysts ask difficult questions about APIs and Integration points.

Can you send an example of the JSON?

It’s why great application developers know the details of how to alert and register events. As well as how to extract and parse event and alert information in a meaningful way.

How do you start a process? Is it as easy as filling in a request form? Do you click a button? Is it complex or simple? Why?

Participants in our second virtual hackathon have been challenged to start a business process. Create a simple registration application. Start capturing those email addresses and start the business process you need to start now.

For more information about how we feel about business processes check out this simple process flow, subscribe to our blog or check out who we are!