Good support is a partnership. This page sets out how CloudM Product Support engages with you — what you can expect from us, and what we ask of you in return. It exists because we would rather publish our standards than have you discover them ticket by ticket.
What you can expect from us
The ticket is the record. Everything that matters about your issue — findings, decisions, plans, call outcomes — is written in the ticket. You should never depend on remembering a conversation, and neither should we. If you ever feel you cannot tell what is happening from the ticket alone, say so; that is a gap on our side.
Silence is a gap, not a policy. You will hear from us within our published response times, and when your ticket is with our development team we will tell you that is where it is, rather than going quiet. If we are waiting on something, you will know what.
Plain language, honest answers. We explain what we found and what happens next without jargon. If something will take time, we say so; if we got something wrong, we say that too.
One team, in-house. You are dealing with CloudM's own engineers, based in Bulgaria, with a senior team and a published escalation route behind them.
Calls: when we offer them, and when we accept them
Written investigation is usually the fastest route to resolution — it keeps everything in the record and lets the right specialist pick up without re-asking. But a call is sometimes exactly the right tool, and we want you to know precisely when to expect one.
When CloudM will proactively offer you a call
Our engineers offer a call when it will genuinely move your issue forward faster than writing. The typical triggers:
- Speeding up the data gathering process — when we can see that several rounds of written back-and-forth lie ahead, and one screen share would collapse them into thirty minutes.
- The issue can only be understood by seeing it — it is intermittent, visual, or cannot reliably be reproduced in writing.
- Your project is at a critical phase — a go-live, a cutover, a moment where tight alignment matters more than the written cadence.
When we offer a call, we tell you what we want to cover and what we need from you beforehand, and you pick a slot that suits you from the engineer's scheduler.
When we will accept a call request from you
You can ask for a call at any point, and we accept the request when a call is the right tool for the situation:
- Progressing the ticket is time-critical — a deadline, launch or contractual date means the normal written rhythm is not fast enough.
- The impact is significant and moving — the issue has reached senior stakeholders on your side, or the business impact has escalated since the ticket was raised.
- Written communication is not landing — the thread has become tangled and thirty minutes of conversation will reset it.
What we ask before any call is booked
To make the time productive for both of us, we ask for four things first: a clear description of the issue and what you have tried, your latest logs, screenshots or evidence, a one-or-two-sentence statement of what you want the call to achieve, and who will be joining from your side. Once those are in, the call is booked — no back-and-forth on times.
How our calls run
- Focused and time-boxed — 30 minutes by default, with the agenda agreed in writing before the slot is taken. We start on time and finish on time; anything outside the agenda is picked up in the ticket afterwards.
- Recorded, and we tell you so at the start — the recording protects both of us and means nothing said gets lost.
- The outcome is written back into the ticket, so the call is part of the record, not a side channel.
If a call is not the right tool
We will never decline a call because of our own availability. If we do not book one, it is for one of three honest reasons: the information above is not in yet (we will tell you exactly what is missing, and book the moment it arrives), the next genuine step is written (for example your ticket is with our development team), or the topic is not a product support matter (we will point you at the right route). Either way you always leave with a path forward, never a closed door.
What we ask of you
Give us the detail up front. The single biggest factor in resolution speed is the quality of the initial submission — the submit-a-ticket checklist tells you exactly what helps. Thin tickets cost days in fact-finding before real investigation can start, and priority is assessed from the detail you provide (how priority works).
Stay with the ticket. When your ticket is Pending, it is waiting on you — an answer, a file, a confirmation. The sooner you reply, the sooner we move. If we don't hear back, the ticket closes gracefully; replying reopens it while it is still open, and nothing is ever lost.
Keep it in the ticket. Side-channel messages, however well-intentioned, fragment the record and slow things down. If something new happens, add it to the ticket, where every engineer who touches your issue will see it.
One issue per ticket. Bundled issues get bundled attention. Separate tickets get each problem the focused investigation it deserves, and let us prioritise each on its own merits.
Describe impact honestly. Accurate impact descriptions get accurate priorities, and they protect the urgency signal for the times you genuinely need it.
Help us reach the problem. Where an issue needs logs, traces or reproduction steps, providing them quickly keeps your issue moving — and where remote investigation needs access, arranging it promptly does the same.
Why we work this way
This standard came out of a deliberate reset in how our team engages with customers: fewer dead-ends, no silent tickets, calls used where they genuinely help, and everything anchored in a record you can see. Holding ourselves to it publicly is the point — if we fall short of this page, escalate and reference it.