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… ;-))

A loyal customer.

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…

Pebble – How to Not Over-Architect a Smartwatch

I bought my Pebble in retail a few months ago and have since fallen in love with it. It doesn’t try to replace a smartphone, which is a stupid idea to begin with. The screen of any smartwatch is tiny by definition, and I don’t want to update Facebook, play games or write blog posts on my wrist. I can easily pull out my smartphone for those more complex tasks.

The Pebble does what it advertises it does:

  • Send all notifications from my iPhone’s lock screen to my wrist (the latest release does it with a delay of only 2 seconds)
  • Show CallerID of an incoming call and allow the rejection thereof
  • Show CallerID and content of incoming SMS
  • Show content of Twitter mentions and DMs
  • Show content of other apps like Lync, Facebook, Reminders, etc.

The battery lasts for days, and the accelerometer built into the device turns on backlight with a flick of the wrist. (Though for 2 seconds only, which isn’t enough and unfortunately not configurable.)

With the help of watchface-generator.de I can create my own watchfaces (ie. customized screens) within a minute, incl. date and time information and a custom image – I prefer one of my girlfriend. 🙂

The most useful feature of my Pebble when wearing it during a workday is the display of my current and next calendar appointments. I achieve that through the use of 2 apps. On my iPhone, I first download Smartwatch+ from the App Store. Within that app, I can then install 2 Pebble watchapps:

  1. SmartStatus, which displays date, time, current temperature, phone battery percentage, next calendar appointment (or current one if I’m currently in one – which I don’t like, as I prefer to see the next one on my calendar)
  2. Smartwatch+ (same name as the iOS app, which is confusing at first), which gives me comprehensive weather info, a full browsable list of my appointments, and my reminders. Furthermore it does stocks, music, camera (huh?), GPS, and custom HTTP requests to control things like your smart home… Nice, and all I’d really ever need (I think… I’ll let Apple convince me otherwise)

I find myself typically using Smartwatch’s calendar view on my wrist during a workday, as I can see all following appointments at a glance, plus the time. After work, I switch over to seeing my girlfriend smile at me and tell me time & date. 🙂

The Bluetooth connection is still slightly buggy, which can be annoying. To get an update of weather or calendar data I occasionally have to do the following in the Smartwatch+ iOS app, in order to re-establish the connection:

  • Open Smartwatch+ and hit Disconnect
  • Wait 10 seconds
  • Connect again
  • Wait a few seconds
  • Press the right top button on the pebble to re-sync

I can live with that, however, hope that they’ll fix it eventually.

I am happy with the purchase and don’t think I’ll ever need more from a smart watch. But as I said, once Apple releases their iWatch, I’ll be happily corrected.

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/.



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.)