50 First Dates with Support
I’ve dealt with my fair share of SaaS support. The robotic scripts, the helpful agents, and the occasional genius buried behind a chatbot. So when a client claimed they couldn’t raise a support ticket, I didn’t believe them. I asked them to try again, live.
"Hello, I'm your digital assistant", said the chatbot, "I work best with specific questions.".
The user typed: "I need support."
"Happy to help! What's the issue?", queried the bot.
The user typed: "I need support."
After the third repetition, I chose to interrupt and suggest the user type in either the question itself, or the instruction to "open a ticket for live support". It worked. Instantly. Like a charm.
And judging by the client’s reaction, that’s probably how they thought it worked all along – that a ticket wasn’t something you request, it’s something that just happens. If you say the right spell.
That’s not far from the truth. And it’s not just a software problem. You’ve heard the horror stories – IT people speaking in riddles to keep outsiders out. But it’s no different when you’re trying to get answers from accounting.
It really helps to speak a little "accountish". Say "debtor", not "the angry guy in #205". Describe the desired outcome in balances, not what the guest shouted on the phone. And maybe pause to understand the reply before deciding the spreadsheet people are just being difficult and kludging some DIY workaround into your card terminal..
This isn’t just a tech problem. It’s a systems problem — and systems don’t care whether you’re confused by software, healthcare, or your tax declaration.
Communication Debt
That’s what happens when users believe "support" should read minds, but don’t believe they should write sentences. This isn’t about knowing what an API is. It’s about understanding that the person on the other end doesn’t know who you are, what you were trying to do, or what kind of crisis your GM is having over a spreadsheet right now. When something breaks, we assume the error is self-evident. “It just stopped working.” No one wants to reconstruct their intent. We assume support already knows what we were trying to do – because we know.
My story was not even about a technical support request, the objective was merely to raise a ticket with a human agent. The user probably even thought they were being "concise and explicit" in typing that they "needed support" – without giving a thought to the fact they were already communicating with support.
And it’s mutual. Support agents rarely understand the operational reality behind a vague bug report. The client sees red; the agent sees syntax. In hospitality SaaS, vendors try to hire people from operations as their support agents, because they know they have to bridge the gap from their end as much as possible. However, you don't get GMs with experience across various continents and hotel types to apply for junior agent roles. So you have people who did a year on a single front desk, and then you train them up in the only thing you are qualified to train them: your software.
While support agents are becoming expert for the ins and outs of a specific tech, they involuntarily become distanced from operational reality. Sometimes, it is even worse if they retain too much memory of "what worked for us" – in one specific hotel, a couple years ago.
The only way out of communication debt is payment. In clarity. In context. In actual effort. Otherwise, every support interaction is just a rerun of the same failed date.
The Holy Trinity of a Useful Support Request
Intent isn’t obvious just because you feel it.
One would assume that by the time a user has raised a couple support tickets, they would be familiar with the basic recipe that gets things moving most efficiently. Even more, the way to a successful request for support should have entered collective memory, or at least institutional memory. But still, each request begins as if it were the very first time. 50 times over.
It need not be so. Dating sometimes follows some sort of rules, and sometimes not at all, which makes it exciting. When in need of support, however, you don't want things to get exciting. If we all followed a set of rules, we'd achieve our ends with the least possible excitement, and the highest possible efficiency. A bit like in dating, it helps if both sides are clear about their goals. If goals are defined like "it should kinda work" and "please, no more shouting", you will spend hours just probing. Be honest, on date night your goals are much more focused, aren't they? But unlike on date night, it actually helps if you are very upfront about those.
When you have established with the agent – human and digital alike – what you want to achieve, you can even employ a cheatsheet to get you easily through the rest of the conversation, and started on the actual resolution. Every effective support interaction, regardless of tool or vendor, collapses to three inputs:
- What broke? (Specifics. With screenshots if you’re feeling generous.)
- What were you trying to do? (Your intent, not just your button clicks.)
- What did you try already? (So we don’t suggest turning it off and on again.)
Then it's the agent's turn. They will usually ask one or two additional questions which you should be prepared to answer, bearing in mind the agent is not here to judge you, but get you both out of this mess as quickly and thoroughly as possible. Cooperation is the term. Hunting around for the microphone switch when the agent asks for a live session will unnecessarily consume both your and the agent's time. And nerves.
The Guest Experience
When in doubt, flip your POV. Imagine a scene at: The Lobby of the Hotel You Deserve. Time: 3:47 PM. Mood: Confused entitlement wrapped in cologne...
[Guest approaches front desk. They look at the receptionist with mild suspicion, like the front desk once stole their lunch money in grade school.]
Guest: “I’m here.”
Front Desk (smiling politely): “Welcome! How can I help you today?”
Guest: “I need a room.”
Front Desk: “Of course! Are you looking to make a new booking, or do you already have a reservation?”
Guest: “I told you — I need a room.”
Front Desk: “Certainly. May I have your name, please?”
Guest: “It should be there. I booked it.”
Front Desk: “Under what name?”
Guest: “I don’t know. Maybe my company name? Or my assistant? Look it up.”
Front Desk (internally sighing): “…Do you have any confirmation number? Or an email, perhaps?”
Guest (offended): “I literally stayed here two years ago. Why don’t you have me in your system?”
Front Desk: “Well, our system has many guests. If you can help me narrow it down—”
Guest (talking over): “Can I speak to a manager? This is ridiculous.”
Now, remember the guests you loved to check in when you had to work a long queue. Namely, the American business traveller, with their platinum Amex hitting your desktop before you could even say "Welcome". What a difference a little upfront info makes, right?
Write Like It Matters
A support call or ticket is like an AI prompt, because you’re literally writing a prompt to a system that must hallucinate its way into your situation. That’s exactly what support agents (human or bot) are doing: trying to simulate your world with nothing but your half-baked input. You’re not talking to a person with full context – you’re building a query to generate understanding in an unfamiliar mind.
You don’t have to write a novel. But if your message could also be sent to a psychic medium, it’s not a support ticket. Neither do you have to write it up like a tech manual, or in some specialist syntax – just like you should ignore the self appointed AI guru who tries to sell you JSON like they’ve uncovered the Rosetta Stone of AI Prompting. You need basic language, a dash of perspective, and the humility to explain things as if the person reading isn’t psychic.
So here’s your support prompt template, totally free of charge (and you don't even have to comment!):
- I was trying to [goal]
- Using [function or feature]
- When I [describe action], [describe what went wrong]
- I already tried [any attempts to fix it]
Optional: include a screenshot, timestamp, or error message. Bonus points for politeness and brevity.
Support Begins Before the Ticket
But, there’s been a quiet revolution. In the old model, the first step in a support request was calling someone – usually because the software never taught you to do anything on your own. What strikes me as much as open architecture and connective functionalities in modern PMS, is the resources some vendors place at the user's disposal: Structured E-Learnings you can do in your own pace. Sandbox accounts to test what actually works for you. Searchable, well-written knowledge bases. Video tutorials in plain language.
All with one goal: enabling the user.
So when you hit a wall – an error, a limitation, or just uncertainty – you don’t scream “broken system” and pray for deliverance from above. Instead, you take the first real step of an enabled user: you talk to yourself.
Why was I trying to do this?
What outcome was I chasing?
Is there another way? A better one?
You’re not expected to be a sysadmin. But modern systems are designed to teach as you go – not to hide functionality behind support paywalls. That’s the whole idea: you should be able to solve a good portion of your issues before you ever talk to anyone. Anyone except yourself, or the in-system chatbot, if your vendor was smart enough to build one.
And if not? Then at least you’ve done the groundwork. You now know what you were trying to achieve, and how you tried to get there. And that means you’re not writing a plea for rescue – you’re writing a support request that’s already halfway solved.
I say this as someone who deals with a dozen different systems:
I use help centers.
I read documentation.
I poke the chatbot.
And yes — I raise support tickets.
It’s not a failure.
It’s just the last step in a process that starts with you.
Support Tickets Bite
Legacy vendors, of course, still cling to the old idea: that support is part of the product. That without the hotline, you’re lost. That without a ticket, the system doesn’t work. They’ll keep you leaning on a crutch — and then charge you extra for the limp. When support tickets start massing, they will eventually turn around and bite you. Not only will they hurt financially. Not only will you lose track on them, when they clutter your inbox. Not only will they eventually scatter among your teams. Basically, because you simply can't help yourself (but raise one more). Pun intended.
So yes, the perceived “lack of support” in SaaS is very real. They’re here to help. But only if you’re willing to help yourself first.
Help yourself – and support can actually help you. Otherwise, you’re not solving a problem. You’re outsourcing your thinking.
