Customer Experience vs Process Design

Why is customer experience so poor when it comes to process design? Regardless of the product or service, it can be so frustrating when having to deal with on-boarding, product upgrades, billing, payment, account updates and customer service. Banks, telcos, utilities and government services are particularly bad, but I am seeing more and more examples in on-line market places and payment solutions.

Often, it feels like the process design is built entirely according to the providers’ internal operating structures, and not around the customer. The classic example is when customers have to talk to separate sales, product, technical support and finance teams – and none of them talk to each other, and none of them know the full customer or product journey end to end.

Even when you do manage to talk to human beings on the phone, rather than a chat bot, as a customer you have to repeat yourself at every stage in the conversation, and you can end up having to train front line staff on how their products actually work or what the process should be to upgrade a service, pay a bill or trouble-shoot a technical problem.

You get the impression that many customer-facing team members never use their own services, or haven’t been given sufficient training or information to handle customer enquiries, and don’t have adequate authority to resolve customer problems.

On many occasions, I get the customer experience equivalent of “computer says ‘no’…” when it appears impossible to navigate a particular problem. The usual refrain is the “system” means things can only be done a certain way, regardless of the inconvenience to the customer, or the lack of thought that has gone into the “process”.

As I always remind these companies, a “process” is only as good as the people who design, build and operate it – and in blaming the “system” for a particular failing or inadequacy they are in effect criticising their own organisations and their own colleagues.

Next week: App Overload

 

 

No-code product development

Anyone familiar with product development should recognise the image below. It’s a schematic for a start-up idea I was working on several years ago – for an employee engagement, reward and recognition app. It was the result of a number of workshops with a digital agency covering problem statements, user scenarios, workflow solutions, personas, UX/UI design and back-end architecture frameworks.

At the time, the cost quoted to build the MVP was easily 5-6 figures – and even to get to that point still required a load of work on story boards, wire frames and clickable prototypes….

Now, I would expect the developers to use something like a combination of open-source and low-cost software applications to manage the middle-ware functions, dial-up a basic cloud server to host the database and connect to external APIs, and commission a web designer to build a dedicated front-end. (I’m not a developer, programmer or coder, so apologies for any glaring errors in my assumptions…)

The growth in self-serve SaaS platforms, public APIs and low-cost hosting solutions (plus the plethora of design marketplaces) should mean that a developer can build an MVP for a tenth of the cost we were quoted.

Hence the interest in “low-code/no-code” product development, and the use of modular components or stack to build a range of repetitive, automated and small scale applications. (For a dev’s perspective check out Martin Slaney’s article, and for a list of useful resources see Ellen Merryweather’s post from earlier this year.)

There are obvious limitations to this approach: anything too complex, too custom, or which needs to scale quickly may break the model. Equally, stringing together a set of black boxes/off-the-shelf solutions might not work, if there are unforeseen incompatibilities or programming conflicts – especially if one component is upgraded, and there are unknown inter-dependencies that impact the other links in the chain. Which means the product development process will need to ensure a layer of code audits and test environments before deploying into production.

I was reflecting on the benefits and challenges of hermetically sealed operating systems and software programs over the weekend. In trying to downgrade my operating system (so that I could run some legacy third-party applications that no longer work thanks to some recent systems and software “upgrades”), I encountered various challenges, and it took several attempts and a couple of workarounds. The biggest problem was the lack of anything to guide me in advance – that by making certain changes to the system settings, or configuring the software a certain way, either this app or that function wouldn’t work. Also, because each component (the operating system, the software program and the third party applications) wants to defend its own turf within my device, they don’t always play nicely together in a way that the end user wants to deploy them in a single environment.

App interoperability is something that continues to frustrate when it comes to so-called systems or software upgrades. It feels like there needs to be a specialist area of product development that can better identify, mitigate and resolve potential tech debt, as well as navigate the product development maintenance schedule in anticipation of future upgrades and their likely impact, or understand the opportunities for retrofitting and keeping legacy apps current. I see too many app developers abandoning their projects because it’s just too hard to reconfigure for the latest system changes.

Next week: Telstar!

 

 

 

Monash University Virtual Demo Day

Last week I was invited to participate in a Virtual Demo Day for students enrolled in the Monash University Boot Camp, for the FinTech, Coding and UX/UI streams. The Demo Day was an opportunity for the students to present the results of their project course work and to get feedback from industry experts.

While not exactly the same as a start up pitch night, each project presented a defined problem scenario, as well as the proposed technical and design solution – and in some cases, a possible commercial model, but this was not the primary focus. Although the format of the Demo Day did not enable external observers to see all of the dozen-plus projects, overall it was very encouraging to see a university offer this type of practical learning experience.

Skills-based and aimed at providing a pathway to a career in ICT, the Boot Camp programme results in a Certificate of Completion – but I hope that undergraduates have similar opportunities as part of their bachelor degree courses. The emphasis on ICT (Cybersecurity and Data Analytics form other streams) is partly in response to government support for relevant skills training, and partly to help meet industry requirements for qualified job candidates.

Industry demand for ICT roles is revealing a shortage of appropriate skills among job applicants, no doubt exacerbated by our closed international borders, and a downturn in overseas students and skilled migration. This shortage is having a direct impact on recruitment and hiring costs, as this recent Tweet by one of my friends starkly reveals: “As someone who is hiring about 130 people right now, I will say this: Salaries in tech in Australia are going up right now at a rate I’ve never seen.” So nice work if you can get it!

As for the Demo Day projects themselves, these embraced technology and topics across Blockchain, two-sided marketplaces, health, sustainability, music, facilities management, career development and social connectivity.

The Monash Boot Camp courses are presented in conjunction with Trilogy Education Services, a US-based training and education provider. From what I can see online, this provider divides opinion as to the quality and/or value for money that their programmes offer – there seems to be a fair number of advocates and detractors. I can’t comment on the course content or delivery, but in terms of engagement, my observation is that the students get good exposure to key tech stacks, learn some very practical skills, and they are encouraged to follow up with the industry participants. I hope all of the students manage to land the type of opportunities they are seeking as a result of completing their course.

Next week: Here We Go Again…