A shout-out to Cambridge Savings Bank for great customer service

It sucks to write checks for the IRS. But then again… I’m happy to contribute my share for the greater good. No big deal. A bigger deal would be losing money because of oversight.

So the other day, I had to write a check for what I owed the government. I filled it out, mailed it, out of sight, out of mind. But then, as things go, I remembered this while driving around in my car through beautiful Somerville MA. The morning of that day I had checked my account balance, and for some reason my brain put 1&1 together and surfaced the thought that I don’t have the balance for the check to go through!

Luckily, my bank, local Cambridge Savings Bank, offers text banking! So as I got to a red light… (ha! Thought you had me there, didn’t ya) I reached for the phone that, of course, already sat on my dashboard, and switched to the messaging app. I texted the words “transfer 2000” to the bank. A few seconds (!) later, they confirmed that I had successfully transferred $2000 from my savings to my checkings account.

What had happened? Within a mere 15 or 20 seconds I went from thought of the moment to resolution. And all because my bank got four of the following “now consumer” (me!) expectations right:

They “let me do it”. They “made it mobile”. They “fit into my life”. They “saved me time”.

Here’s another example why I consider myself already a loyal customer. A few months ago I asked them whether they supported Apple Pay with the MasterCard I have. I asked this question on Twitter; a convenient channel for simple customer service inquires. They got back to me. Not in record time, but that wasn’t needed for this type of inquiry. They told me they didn’t support Apple Pay yet, but would tell me once they did – they were working on it. Did I honestly believe they would remember telling me? Not really. However, a few weeks ago, I got a tweet out of the blue: Cambridge Savings Bank informed me that they now support Apple Pay, adding a link to more information. They did remember!

They “know” me. They “made me smarter”.

Finally, I get frequent updates by email from the person that setup my account last year, proactively, without me even asking for it, whether the great interest rate that made me a customer in the first place, was being continued beyond the promotional timeframe or not. (It is.)

OK, one more. Just a few days ago, I needed to deposit a check that had a higher amount than what the deposit function in their mobile app allowed. I wasn’t in the mood for going into the branch, so I asked via email if they could help me somehow. Within an hour or two the mobile deposit limit was raised temporarily. I could deposit the check the same day.

They “made it easy”. 

Here’s a shout out to you, Cambridge Savings Bank. Thanks for providing great customer service. Keep doing what you’re doing. (Oh and if this post brings you a new customer or two, why don’t you keep up that interest rate on my money market account for a bit longer… ;-))

Sincerely,
A loyal customer.

How UPS doesn’t Grok Twitter Support, and 5 Lessons for Doing it Right

I have to share this memorable customer experience I “enjoyed” today for your reading pleasure. It started a few days back, when I tried to change the delivery of a package from Apple I was awaiting.

I knew I wouldn’t be home in person for a signature on the expected delivery date, neither did I want to pre-sign, so I opted for a pick-up option at a UPS facility. On the UPS website I found out I had to register for a (free) account to make a change like that. Fine. I tried to register, but the website kept going in a loop of me registering, then trying to change the delivery option, and it telling me to register to do that, then me registering, then trying to change the delivery option, and it telling me to register when trying to do that, then me… you get the idea. A bug. I had no choice but to contact an agent (which is very expensive for UPS vs me using their website). I opted for Web chat. It worked fast and smoothly. I had the agent change my delivery to a drop it at a pick-up location. So far so good…

Today, I got an SMS alert from Apple (love their service) telling me that “today is the day”. I clicked on Track Shipment to find out where to pickup the package from – ie., which UPS facility. The tracking website told me everything about the journey of my package, how it started in China, then went to Korea, then Alaska, Kentucky, finally Massachusetts. What it failed to tell me? Where to pick the package up. All it said was “A pickup facility in Somerville, MA”. Thanks UPS, that’s helpful. Google tells me there are many UPS locations in Somerville. Which one?

Lesson 1: Fix your data.
It’s needs to be self-explanatory, not force the customer to make unnecessary inbound service requests.

 

I turned to Twitter, asking @UPSHelp for help. Here’s how that journey started:

Uh, yeah… There is. Kinda obvious, no?

Really? I’m contacting you on Twitter and you’re sending me to email? There’s your first mistake, @UPSHelp. I picked Twitter for a reason (simple: I like it – it’s convenient and fast for simple inquiries like this), and you would be perfectly capable of answering my question on this channel.

Lesson 2: Don’t force your customers to switch channels unless they ask for it.

 

Great. Looks like you got it now. So here is my DM:

Wow. “the local center”. Really UPS? You do know the very reason why I contacted you, don’t you? Also, spotted the second mistake? They responded on the public channel, rather than staying on the DM channel that we had just established through mutual following.

Oh, and – pickup times of 3 hours and only on weekdays? That’s almost disrespectful.

Lesson 3: Once on DM, stay on DM.
I didn’t chose Twitter to make my request public – I chose the channel for its convenience, speed, and simplicity.

 

I’m still communicating on DM, but their response again happens on the public channel:

I then realized that the pickup times were actually really bad, and I really wanted this package on a Saturday.

Wow. You just completely blew my mind. 20 minutes and you already completely forgot our conversation? That’s unbelievably silly. I don’t care if they had a change of shifts (note that the agent apparently changed from “SB” to “SO”). It’s just unacceptable to be treated like this. I’m starting to lose patience. Also: again the request to switch to email, even though they have clearly demonstrated they could answer my questions on Twitter.

Lesson 4: Never lose context, never force your customers to repeat themselves.

 

I responded right away, assuming I had their attention. That was naive of me to assume. Of course. I waited 30 minutes for a response. I became impatient.

That may very well be, but what about other facilities nearby? Can the package not be transferred to a facility with better opening hours (assuming those exist in the first place – I don’t know, you tell me)? Please try to solve my problem, not just answer questions.

Lesson 5: Think and help, proactively – don’t just answer questions.

 

That was my last interaction. I am still waiting for a response, hours later.

Sorry @UPSHelp, but you have a lot to learn (and fix) if you want to get this customer service thing right. Need help in doing it? Talk to my company, we are in the business of fixing bad customer service. Meanwhile, you have one more unhappy customer who happens to be a customer service professional that likes to blog.

 

Addendum: I did email them, which they had asked me to do, and they responded (6 hours later). In that email response, they told me that the location actually opens in the morning AND in the afternoon. So the info in their tweet was actually wrong! I’m still sitting here, shaking my head.

The Dawn of the Era of “Human-assisted Machine Service” in Customer Care

For the longest time, we have looked at how to complement human labor in the contact center with computer programs – to reduce costs, provide 24×7 service, and offer quicker access to basic information. IVR systems are the prime example of technology that complements human service by pre-qualifying a caller through some simple questions and routing them to the right agent. What we have been finding until recently is that customers usually preferred the “human touch” over automation. The terms “automation,” “bots,” or ”IVR” tend to come with heavily negative connotations. TV ads have been mocking bad IVR systems and showing off with short wait times to get to live operators. Websites such as gethuman.com have been launched to show consumers how to quickest get to an operator.

As another example of how technology is complementing human labor, let’s look at the agent workplace itself. In the contact center, agents are equipped with Internet access, dedicated knowledge bases, document management systems, CRM systems, and more, to have the answer to the customer’s question ready as quickly as possible.

All of this, however, is slowly changing. Rather than having machines assist humans, we’re slowly entering the era of the reverse: algorithm-based customer service, assisted by humans to put the “finishing touches” on an otherwise increasingly impeccable experience. Virtual assistants on websites are recently gaining in popularity as they expose a more natural interface (conversational, “spoken language” style) to finding information vs. manual search. The younger demographic prefers texting to calling. The older ones seem to catch up and agree. We are now carefully sending a text first to check if it is OK to call. What a remarkable change in behavior and expectations!

Why is this change happening?

First and foremost: the mobility revolution. The introduction of the iPhone in 2007 has truly brought the mass consumer market to realize the power of computer technology if applied to their daily lives. For the first time ever did the Internet, an invention that in its current form came into being around 1989, find its way into a pocket-sized device without compromising the user experience. More and more people realized that with a mobile device of this form factor, they had the world of information and communication literally at their fingertips. It suddenly became cool to be a nerd – a person who understands and can program computers. Consumers now seem to shout ”give me an app, I can look this up quicker than your agents!” at any company they do business with.

Other enhancements came with the iPhone and Apple’s insistence on quality user experiences. Siri, Apple’s speech assistant, is only possible as general-purpose data connectivity and required bandwidths allowed overcoming the restrictions of the PSTN (public switched telephone network) in terms of what sound frequency ranges it submits. Sounds such as “s”, “f”, or “th” differ in frequency ranges that are simply cut off in normal telephony (above 8 kHz). Siri can submit the full range of an utterance recording in high definition, which improves speech recognition accuracy. Cloud computing does its share to quickly respond with a transcription of what was said, of which Siri then applies a semantic analysis to truly “understand” the user – at least to the extent that it can perform the operation the user asked for.

Big Data and today’s capability to automatically farm large quantities of data contribute to making systems such as Siri more and more perfect. The formula is simple: the more context you have, the better you can understand someone. While this is even more true for pragmatic context (i.e. dialog history and “world” knowledge), it is even important in the phonetic domain alone. As an example: try to understand a few words of a spoken conversation by only hearing a second or so of what was said. If you don’t have any context at all, you will realize it’s not that easy to do. However, if you heard the domain and topic the conversation is about, and heard what the immediately neighboring words were, your brain uses deduction and other mental techniques in addition to the pure “hearing”, to understand an utterance.

What does all of this have to do with customer service?

Recently, companies and technologies have emerged that invert the paradigm of machines helping humans become better. There are companies out there in the field of IVR technology that are running call centers of people that do nothing but listen to what people tell IVR systems. They never talk to the callers directly, they are merely jumping in if automated speech recognition cannot tell what a caller said, or isn’t confident enough it understood the caller properly (speech recognition engines always associate a likelihood with a recognition hypothesis). When hearing an utterance, they then either quickly type in what they heard, so that the IVR system can move forward, or they click on predefined data items (the so-called “semantic interpretation” of a verbatim utterance) that are expected in the current dialog step. This is a case of “human-assisted machine service” in the field of customer service that is an amazing testament to the change that is taking place.

After great success on TV’s “Jeopardy,” IBM released Watson to developers to build applications that use Watson’s unique cognitive capabilities in creative new ways. A prime use case for Watson, however, is customer service. When done right, Watson can engage with customers, say through chat on a website, as if the customer was talking to a live person. Watson doesn’t merely bring up Web pages that seem to have the information you are asking for – it answers your question. Something that Google also increasingly does on their core search product (try searching for “who wrote Norwegian Wood,” and Google will answer your question – in addition to showing you relevant websites). Watson goes beyond Google, though, in that it can ask back to narrow down your question, to lead you to the right answer. It can deduce. It can learn. Like a child absorbing everything, or a very astute student. Most importantly: Watson learns from unstructured data, i.e. data expressed in human language such as English. That’s a new level of computing, beyond plain big data analysis.

With Watson, humans again take a step back from the spotlight, and operate “behind the scenes.” They need to feed Watson with information, constantly. Watson doesn’t go out by itself to learn. Watson needs to be fed product brochures, manuals, data sheets, research papers, books, etc. Anything that is relevant for the domain of knowledge Watson is operating in.

This is the emerging new role of humans in customer service: make sure that the data is accurate, but let machines do the “talking” and “serving.” Humans then also step in when that “human touch” is really needed: Not to answer the simple questions, but to mitigate in complex situations, to calm down angry customers, to provide a level of confidence and confidentiality when needed, e.g. in the domain of financial advising.

It’s going to be exciting to see what the limits are.

Customer Service – Don’t Treat Us Like We’re Still in the 90ies

I witnessed a conversation on my Facebook wall today that obviously caught my attention, as I am working in the customer service technology industry. I want to share it here:

It is obvious how the recent advances in communication technology simply overwhelm some bigger organizations. While in the past they could compensate lack of speed of adoption as technological progress was slower, it is nowadays pretty much impossible to keep up with the Whatsapps, Snapchats and Secrets of this world. But looking at what my friends here discuss – they really don’t demand much. SMS and email are technologies from the stone-age! SMS celebrated its 20-year anniversary in December 2012! And still today, so many years later, businesses are not using the power of this channel for the most basic B2C customer communication.

And phone calls that ask you to call back on a number that isn’t even the one the call is coming from? Or a text that asks you to call back? Why the forced switch of channel, if obviously I chose to have you reach me via SMS?

It quite frankly blows my mind, knowing what is possible if only modern software and cloud solutions were embraced. How much longer will consumers tolerate companies with customer service technology from the 90ies? Well, research shows that they are increasingly taking their business elsewhere already, so hopefully the dinosaurs of the service industry will either go extinct soon, or adapt. Remember, it’s not the strongest that survive, but the “fittest”, meaning those that can adapt…

How New Technologies Necessitate Customer Care Collaboration

Back in September, I wrote about the need to break up organizational silos in order to improve overall customer service. The rise of the smartphone and the advent of social networks simply necessitate collaboration among different teams and departments to jointly work towards the goal of a consistent customer experience.
 
 Read more here: http://www.icmi.com/Resources/Technology/2013/09/How-New-Technologies-Necessitate-Customer-Care-Collaboration

WebRTC business models (and impressions from WebRTC Expo 2013 – East)

WebRTC, WebRTC, WebRTC. I just returned from 3 days of WebRTC. Nothing but WebRTC. I was right there, in the eye of what probably is the heaviest hype storm of the communications industry at the moment. It was interesting to see which businesses were there, jumping the bandwagon of realtime communications brought to “the Web”, and also who wasn’t there (traditional communications service providers and mobile carriers, for instance). A LOT of startups. And quite a few incumbents, too. A few impressive show cases of what’s going to be possible, but even more “me-too’s”.

It became obvious at the Expo that there clearly is a correlation between the maturity of a market and the ability of conference speakers to handle the microphone. Speakers at the WebRTC Expo were exceptionally bad with the microphone – showing that WebRTC is still predominantly a techie play, not yet a solutions play. Otherwise we would have seen more marketers speak, who know that you are supposed to speak INTO a microphone, not wave it around as you’re gesticulating to try to make your point.

However, for something that is a techie play, and – even more importantly – NOT a mobile-first initiative, the interest in WebRTC is surprising. But don’t get me wrong – it entirely makes sense (for Google, above anyone…) and will definitely happen. The question is just when, and how.

To get to the topic of my blog post: I want to provide a classification of current vendors that deal with WebRTC, hoping that it can help you get an idea of who’s playing what.

I see 5 main categories of vendors in the WebRTC realm. The companies I will be listing as examples are only those that had a presence at the WebRTC Expo.

1) Media Engine and Gateway vendors
These are companies that offer gateways and engines for transcoding, trans-rating, trans-sizing of video/audio codecs, whether at small(ish) scale or largest possible scale (carrier-level). VB8 is new, H.264 the incumbent. No agreement on codec = their business model. No startups here, unsurprisingly. This is where the rubber meets the road.

Examples:

  • Audiocodes
  • Dialogic
  • Radisys

2) API and SDK vendors
These are companies that primarily provide APIs and SDKs to help developers implement WebRTC solutions. They all offer a hosted infrastructure (mostly on the shoulders of existing PaaS/IaaS vendors such as Amazon), and some provide their packages for on-premise deployments as well. This category shows a good mix of startups and established companies.

Examples:

  • Apidaze
  • Bistri
  • Crocodile
  • Quobis
  • Voxeo Labs

3) Full Stack Platform vendors
These are either hosting providers (PaaS) or software/hardware providers offering the full stack of technology needed for running WebRTC solutions incl. STUN/TURN, media engines, gateways, presence, etc. These companies typically sell to service providers (B2B). Again, no surprise: almost no startups. These vendors have a legacy of VoIP and networking expertise and technology.

Examples:

  • Genband
  • Ingate Systems
  • Mavenir
  • Oracle/ACME Packets
  • Sansay
  • Temasys Communications
  • TokBox
  • Xirsys

4) Solution Providers
These are (primarily) cloud vendors that provide specific solutions or applications (horizontal and vertical) around WebRTC. Most startups are to be found in this category. Use cases primarily group around the contact center/customer service, and video conferencing.

Examples

  • Avaya (as it relates to customer service and contact center)
  • Bistri (hosted Click-to-talk-to-me service)
  • Bolder Thinking (click-to-talk solution embedded in a hosted contact center)
  • CDE/Browsetel (click-to-talk solution embedded in a hosted contact center)
  • Genesys (click-to-talk solution embedded in a hosted contact center)
  • popexpert (expert finding and connecting service)
  • Presence Technology (click-to-talk solution embedded in a hosted contact center)
  • Priologic Software/tawk.com (free video conferencing service)
  • Requestec (video conferencing service, collaboration service, video contact center)
  • Solaborate (social networking and collaboration platform)
  • vLine (video conferencing service)
  • Weemo (video conferencing service)

5) Professional Services companies
These companies primarily provide app dev and SI expertise around WebRTC deployments

Examples:

  • Daitan Group
  • Priologic Software
  • Quobis
  • Requestec

For most incumbents, adding WebRTC to their portfolio is a natural, logical, and easy move. None of them have to change their business model to support it. WebRTC is an evolution after all, not a revolution – it doesn’t really enable applications that weren’t possible before. Which of the startups will survive of course depends on a multitude of factors, among them differentiation and … what Apple will do. Total number of users will be more important for the social network-type solutions (like Solaborate).

Where will it go? We will see. See you at the next expo to find out…

HTML5 or Native? HTML5 *and* Native! A comparison of desktop and mobile software

In the mobile application space, the question of whether HTML5-based or native apps will prevail is a rather open one, the resolution of which will either “never” come (note that never hardly ever means never, though, right?), or at least accompany us for years. I believe it will not come in the foreseeable future, and I’d like to argue by comparing the “mobile” to the “desktop” world, or the “small screen” to the “big screen”. I will also list several factors I see as critical for deciding for one over the other approach.

 

Desktop Software

Consider the “big” screen first. We today have 3 major OS competing: Windows, Mac OS, and Linux distributions. I’d say these systems base their success on the ecosystem of software built for them – the very same criterion for the success of a mobile OS, if you think about it. Windows, e.g., has been drawing its success from the Office suite for a long time – and still does in the enterprise. On the Mac, a lot of software commonly used under Windows did not exist for quite some time, which made Mac more of a special-purpose environment, something from which Apple has emancipated by now. Users today can achieve pretty much the same on a Mac as they can on a PC, with less and less compatibility issues. Linux is not relevant in the consumer space. (http://en.wikipedia.org/wiki/Usage_share_of_operating_systems).

Developers choose which OS they implement their software based on the Reach (marketshare) of the OS, which constitutes my first decisive factor.

Detour: While we have been happily using the terms “software”,”programs”, or “applications” in the past, for some reason the term “app” has been established for software running on “mobile” devices (smartphones and tablets; laptops are also “mobile” to a lesser extent, but you wouldn’t call software running on them “apps”). The term “app” also involves a convenient distribution system, which is completely Web-based: the idea of “app stores”. These didn’t exist before with “traditional” software. You didn’t have one place to go to download software for your OS from, instead you either downloaded software from the vendor’s website with their own payment system, or you bought it physically as a CD or DVD. (Apple started to establish the online App Store idea with their “big screen” OS two years ago this month, with some success but also some skepticism attached to it, as described here:  http://www.macstories.net/stories/mac-app-store-year-two/).

On the “big screen”, software has to be released for each OS individually, in order to function. Only if software is offered “as a Service” (“SaaS”) does it usually get “consumed” via a Web browser (acting as a dumb terminal, as in the old days). It then has to be built only once: as an implementation involving HTML and complex Javascript (at least as far as the front-end is concerned; the backend and control logic live on the application server in whatever language and for whichever OS you program that).

There is a difference in the type of software that you use through a browser and that has been built specifically for an OS. Typically, the Web-based software is used for “simpler” tasks. It usually lacks features, functionality and speed (in terms of execution) as compared to desktop software. I will call these the factors Complexity and Speed (usability).

Why is the Web-based version of software usually a little restricted in comparison to native? Mainly because it requires an intermediate interpreter, the browser, which is native software that has to be developed and maintained for the OS of choice. New features and functionality of a device/computer is first made available to the developer of the browser, only then for the developer of browser-based software that runs in the browser. Native software, however, is written directly for the OS. By skipping this intermediate software layer, native software is, by definition, always one step ahead and quicker to provide enhancements, which (should) result in usability improvements for the user.

You don’t have to “install” Web-based software on your OS – you only download its front-end, which happens automatically in your browser. It therefore has less of a Footprint on your machine. (However, on a desktop or laptop computer with big hard drives, this is less of an issue).

As an example, consider Office. If your job is to write whitepapers, you will have no issue to install proper software for doing so. Whitepapers often embed complex graphics, page layout, tables, etc.; you will not be able to do that properly in a Web-based system such as Google Docs (now available via Google Drive). This version of a text processing software simply is too restricted in terms of functionality for your job. However, if all you want to do is maintain a simple spreadsheet for travel expenses with your buddy you went on vacation with (where the collaboration feature of online systems comes into play, too), or write an essay like this blog post, then you’ll be fine with a Web-based version.

The factor of how often you will use the software (and thus how “relevant” it is to you), I like to call Relevance:

Consider software for managing your insurance policies and claims. This is something you don’t need to do that often, and it usually only involves looking at some numbers and text and changing a few values here and there. Would you want to buy software for that, install it, have it sit on your system permanently? Probably not. It is just not that relevant to your daily life. If you need to file a claim, you would probably prefer going to your insurer’s website once, provide your input in your browser, and be done with it, not leaving anything behind on your machine.

If you look at all this together, I believe it is obvious why on the “big screen” both approaches have been living happily together for quite a while, and probably will be for quite some time more. Google’s Chrome OS, one that is based entirely on running the front-end of software as “HTML+Javascript” in a browser, has not really taken off yet, and I believe it only can once bandwidth and reach of wireless Internet technology is truly ubiquitous.

Depending on the factors Reach, Speed, Relevance, Footprint, and Complexity. one approach or the other will make sense for you as a developer, or a business. The mobile world introduces one more factor: Maintenance, or release requirements, which I will describe in the next section.

 

Mobile Software

Native mobile apps are nothing but software programmed for a specific OS and installed via a centralized app store (as opposed to independent downloads/installs predominant with desktop software). With mobile, we today also have 3 major competing OS: iOS (Apple), Android (Google), and Blackberry OS (RIM), with Windows Phone/8 lurking around the corner, and Symbian being on the decline. Samsung, Firefox, and Ubuntu have also announced proprietary OS. With mobile, software also has to be released for each OS individually, in order to function. But in the mobile world you can also program the front-end of your software as “HTML+Javascript”, with the backend and control logic living on your servers. So, developers will have to consider the Reach they like to accomplish – same as with desktop software.

The factor of Footprint is a much more important one in mobile: you have rather limited capacity on your mobile devices, compared to hard-drives of your desktop or laptop computer. Footprint therefore is, in my opinion, quite a decisive factor for Web vs native. It is closely coupled to Relevance: if you want to check your car insurance policy or review health claims, do you really want to download an app for that, which uses space on both your device’s memory and on your home screen? I, personally, do not. I’d prefer a Web app that I can browse to when I need it. (I have, however, noticed that I like to have a “proper app” for services that are important to me, even if I don’t use them often. Loyalty apps for retailers I use often fall under this. But do not forget that even those could technically be a Web app, while still living on your home screen: as a simple bookmark, as opposed to software stored locally on the device. The online/offline argument does not apply here, as I always need an update anyway; I would not know what to do with my Starbucks app, e.g., while being offline. I can neither search for stores, nor see my current balance…)

Mark Zuckerberg made this infamous statement in September 2012 that choosing HTML5 over native for the Facebook mobile app was the biggest mistake they have made to date. Concluding that therefore native apps will prevail is, while tempting, very wrong though. Facebook is for many the app most frequently used on their smartphones. UI speed or usability is, above anything else, therefore the most decisive factor. Nothing is more annoying than having to wait for the app to respond if you quickly want to check for an update or look at a picture someone has posted. Even fractions of seconds matter here. And which approach do you take if speed is so important? Native. Does that mean that HTML5 is the worse choice for all mobile apps? Definitely not. Again, it depends on Reach, Speed, Relevance, Footprint, and Complexity.

One final factor exists only in the mobile world today: that of Maintenance. Native mobile apps can today only be released through the app stores of the respective OS’s. Desktop software does not have that restriction today, even though Apple introduced the same mechanism 2 years ago with their Mac App Store – maybe we will see this to be the predominant, if not only, way to install new software on any OS in a few years time.

Web apps, whether they run on desktop computers or mobile devices, do not have this restriction either. You can update a Web app/site live, without having to involve the maker of the end device’s OS. If frequent and timely deployment of changes to your apps is important for your business, native might not be the best choice. The following post describes the drawbacks of native deployment well, with the most annoying being delays: http://blog.mightbuy.it/2012/12/26/table-applications-for-businesses/.

 

Conclusion

So, to come to a conclusion here: I have tried to argue that mobile software pretty much follows the same rules as desktop software, albeit with a few obvious differences. The desktop world has seen the battle of Web vs native for much longer than the mobile world (the latter only really having come into being since the 2nd generation iPhone in 2008, which introduced the App Store). With the desktop, the battle is not over yet; or you could maybe even say: there is no battle. Both approaches coexist peacefully. Much like fish and human beings do. I believe the same is true for mobile apps. There will always be use cases for Web apps vs native apps. It totally depends on the six factors: Maintenance, Reach, Speed, Relevance, FootprintComplexity. If anything, the number of OS and their marketshare will determine which approach is used more often. If we end up having 5 or more OS and ecosystems competing, companies will have to think twice whether they want to (or can) afford developing the same application that many times.

To finish up, here’s a decision graph helping to determine which approach is best for you, depending on the following factor hierarchy:

  1. Maintenance
  2. Reach
  3. Speed
  4. Relevance
  5. Footprint
  6. Complexity

(The last factor, complexity, stands out a little, as you might have cases where a Web app simply cannot implement a feature you need. You will then have no choice but to go native.)

How the Factor “Time” is Often Ignored in Management

We all have experienced this. Overzealous managers introduce new processes and put new structure in place in order to improve the results of their department. I’m not opposed to processes and structure; well-defined processes that are properly explained, justified, and put in place such that the team is onboard with them can only improve the outcome of any team. You have to find the right balance, though. Too many or too rigid processes prohibit creativity and can reduce motivation. That can only have negative impact on your productivity.

One mistake easily made is missing ownership and accountability. If a task or process is owned by everyone, it is owned by no one and eventually will not get done or applied. Define a clear owner (which might be the manager themselves), and have that person follow up on the progress.
As an example, consider a document or spreadsheet that lists a company’s partner landscape with team members, strengths, capabilities, etc. Once that’s produced, you get celebrated for putting it in place and everybody is happy right then as it is a useful source if information across departments; until it literally expires and shows old information. It has now become useless. Factor time has not been accounted for, an owner had not been declared, it doesn’t get maintained, your manager does not demand an update. *Even though* people would need an up-to-date document, nobody demands it.

Too often do I see managers put a new process in place, or demand a new “habit” from their team, without taking time into consideration. It is not enough to announce something once and expect everyone to follow along and apply. If you want change, you have to repeat. It’s a human trait. People get sluggish over time. To modify a well-known Chinese proverb:

Tell me (once), and I will (most likely) forget. Show me (once or twice), and I may remember. Involve me (over time), and I will understand.

Set yourself a reminder for 1/3/6/12 months from now, or whatever makes sense in your case, to repeat the idea, process, structure you came up with, or to update the document you came up with, or, if you’re the manager, demand an update from your team members. It’s easy to do with today’s digital calendars. Ask Siri to help you, if that’s what it takes. Re-train the team. Re-mind them of what the purpose of a process was. Remind yourself. And evaluate the results of the new process, as time has passed. Only then will your work have an impact, and your employees will respect you for seeing progress after the process.

It’s easy, but often forgotten. It’s not enough to kick something off. Take it to the finish line, only then is your job done and you can move on to something else.