The Support Model Behind Rexfin: Honest SLAs, Not Aspirational Ones

Most vendor support pages read the same way: 24/7 coverage, formal uptime guarantees, a tiered escalation matrix implying a large team behind every ticket. Rexfin’s support page does not read that way, on purpose. We would rather publish numbers we can actually keep than numbers that sound better in a sales deck.

Every number is sized against real availability

A support ticket, wherever it lands, resolves to a small team: triage, response, and escalation happen sequentially, not across a rotating bench. So the governing rule behind every SLA figure we publish is simple: never commit to something operational reality can’t back.

That shapes two decisions. First, the tool: a heavy, workflow-automated helpdesk platform is overhead when there’s no ticket volume to justify it, so support starts as a shared, labeled inbox and only moves to a proper shared-inbox tool once volume demands it. Second, the SLA tiers. Our pilot tier publishes no uptime language at all: same-day response for ordinary issues, best-effort under four hours for close-blocking ones, no service credits, stated plainly rather than implied. The paid tier publishes only the commitments we can genuinely stand behind today, with an explicit note where our own measurement tooling has a known gap. Ask why there’s no formal SLA at pilot stage, and the honest answer is we won’t commit to a number we can’t yet measure reliably.

The GCC calendar, defined precisely

Support hours follow the business week and public holidays of your own jurisdiction, not a generic assumption. UAE and Saudi customers sit in different time zones, and the work week itself has drifted differently across the two markets in recent years, so we confirm the actual week shape per customer rather than hardcoding one. Ramadan gets a named, communicated exception with reduced hours rather than a silent slowdown, and holidays reference the real government-gazetted calendar for your jurisdiction rather than a fixed date list that would be wrong within a year.

Every ticket gets sorted into one of four buckets before a reply goes out: a technical issue affecting the service, a wrong or suspicious number in an answer, an ordinary how-to question, or a feature request. That sorting matters more than it sounds like it should.

Why “a wrong number” is not a normal support ticket

An outage is forgivable. Every SaaS product has one eventually, and customers largely accept that. A wrong figure that quietly made it into a customer’s signed board pack is a different category of problem entirely, because it strikes at the one thing Rexfin exists to guarantee: that every number traces to its source. Treating that report the same way as a “page is loading slowly” ticket would be the single most damaging mistake our support process could make.

So a wrong-number report never goes into the ordinary incident queue. It routes to a dedicated data-integrity protocol: detect the error, determine before saying anything whether it’s isolated to one workspace or could recur wherever the same mapping rule or connector is in use, disclose to the customer proactively (before they notice, where possible), correct the figure and reissue any export with a visible revision marker rather than a silent overwrite, and feed the root cause back into our verification tests so the same error class gets caught automatically going forward. If the issue turns out systemic, every affected customer gets told, even the ones who haven’t noticed yet: “no one else has complained” is never treated as equivalent to “no one else was affected.” See how verification works for the checks that catch these errors before they ship, and the answer audit log for how every cited figure keeps a trail to source.

We’re honest about the current gap here too: confirming which other customers might share the same affected mapping rule or connector is still a manual check today, not an automated query, so our disclosure target bundles two different jobs into one number. We’d rather tell you that than imply tooling exists that doesn’t yet.

What this means if you’re evaluating us

If you need a formal 24/7 support commitment with contractual uptime credits from day one, we’re not that vendor yet, and we won’t pretend otherwise. What we do offer is a support model where the response times we publish are the ones we actually hit, and a clear, dedicated path for the one failure mode that would actually damage your trust in our numbers. For the verification and provenance layer every cited number runs through, see security architecture overview and the broader inside the Rexfin platform pillar.

If a wrong number is expensive enough to build a whole protocol around, it’s worth asking any vendor, including us, exactly what happens the day one slips through.