Things go wrong with tech all the time, in fact, "tech is a word that describes something that doesn't work yet" as defined by the great sci-fi author Douglas Adams. We can imagine that there was a time when shoelaces were tech, for example. But now, they just work for us and therefore they're just shoelaces. Not so with just about any piece of software or hardware. These words are still new and most people aren't really interested in learning about them.

So even if tech has a wider and deeper influence on our lives, it's still tech and therefore, by definition, we can't work with it. It comes upon us too fast, forcing us to only pretend like we know what we're doing with it. Ignorance gets mixed in with vanity and anxiety, but also some occasional curiosity. Clients see the potential in tech but are also overwhelmed. We want to believe in the magic, to trust that we don't need to know the thing to do the thing. But inevitably that illusion always falters, predictions fail, and stuff breaks. 

In fact, if we have a problem and we can't work with the tech, we can't really know (and do we even care?) if something is broken. A client reaching for your tech support may be situated between different issues, like for example at some point inside this Venn diagram:

 
What can initially be understood as a bug in the system, may first be a matter of knowledge not getting shared. Maybe you don’t know what the client actually wanted or maybe the client doesn’t know how to take advantage of your solution. And even before some knowledge gap might be found, the bug might instead be the lack of a feature that the client was expecting. Presenting it as a bug might be a negotiation tactic to get a feature developed for free. And finally, another gravitational field pulling on this conversation is the fact that, like Dr. House was found to say when wrestling with a medical diagnosis in his TV show,  "everybody lies". 

People always come before any process and the process always comes before any tech. When there's a problem and usually some stress associated, solutionism might be out of place. Before working to fix anything, people need to vent and to feel they have your attention. They need you to read their minds. Clients exaggerate, make sweeping generalizations, and use the wrong words to describe what's happening. And clients have clients too, so all those messy signals can have multiple intermediaries before getting to you. In fact, it’s possible that the original person never had a real problem but thought they did and this social exercise was still relevant for how they feel about working with you. 

Communication often doesn’t start by factually describing the problem. Adjectives pile up together with generic phrases like “I can’t get it to”, "X doesn't work", “I’m having struggles” or blurry screenshots that almost require forensic analysis. The customer is always right, but that doesn't mean that everything they say is true or useful to them. It means that the importance of their situation needs to be recognized before any solution may be considered. The reasonable meaning behind what they’re first saying is “pay attention to me” and not “fix this issue”. Any welcome change in their process or technical solution may be secondary to knowing that you're committed to making things right for them. 

The client may even realize that there was no real problem after all and just some misunderstanding. The space and time given by some empathic connection have to be there before rushing to land a solution on shaky ground. Are both sides really listening? Is there room for questions or just guessing? Somebody else you could talk to? Could any of this confusion have been prevented in the first place? Can you describe the potential issue back to your client in a way that clears a path toward fixing it? Is it possible to replicate what’s happening? And, if you eventually come to a solution, how can you verify it? Don't forget that "everybody lies" includes you.

And given how remote work is here to stay, this distance that needs to be bridged can also involve people in the same company who are looking for help or offering their support. Asynchronous communication has also become more important and exchanging messages at different times can be challenging if some back-and-forth is needed. Someone looking for help may leave a message venting their frustration and have the expectation that something will be done by the time they get a response. Instead, all they might get is a question back in an attempt to discover what might be the issue or a slow response caused by the need to investigate before responding with something useful. Communicating asynchronously requires both sides to put themselves in the other person's shoes to anticipate what they might need from them and maybe gain some time. 

You can try to standardize tech support, but often that is done by trying to forget that the knowledge gap may be something you yourself should know, that some expected feature may be a good opportunity, or that having trust and empathy is the first step towards a solution. All these issues can be present in these conversations, but customer support flowcharts often optimize for other things like average call time or an immediate evaluation rating of that interaction.

This is only some of the context that allows us to work with tech as it keeps falling apart and getting put back together. It's often tempting to give up on it, but it's also empowering if we get to shape how tech makes sense to us and how it can evolve.