"Do you offer support?" is a question almost no vendor answers with a "no." The useful question is different: what exactly happens when something breaks? A payroll error at nine in the morning, with the month closing that same day, doesn't get solved by "open a ticket, we'll reply within 24 hours" -it gets solved by a design that already assumed things would fail. That's a fair thing to ask any vendor, cloud-based or not, because an outage at the wrong moment can turn a minor hiccup into a missed payroll deadline.

Before signing, it's worth treating support not as a contact channel but as a feature of the product itself: is the system built so a single failure doesn't turn into a bigger problem?

What happens when something is out of your hands

Cantevia's e-signature feature adds an RFC 3161 timestamp, issued by FreeTSA, an independent timestamping authority. That means the timestamp can be verified independently -with the standard openssl ts -reply tool- without depending on Cantevia still being around ten years from now. It's a concrete example of design meant to avoid lock-in: if you ever switch providers, the evidence behind a signature doesn't disappear along with them.

What happens when someone makes a mistake

Mistakes in HR aren't hypothetical: someone clocks in wrong, someone approves a leave request by accident, someone needs to correct a payroll figure after the month is closed. The support question that matters isn't "can I fix this," it's "is there a record that I fixed it, and why." Cantevia's time-clock corrector never deletes an entry: it voids it and logs who did it and why, with the original always still available. That's the difference between support that "fixes the problem" by erasing it and support that corrects it while leaving a trail.

Support also shows up in how exceptions are designed

An expense policy with per-category caps is a good example of design that anticipates real life not always fitting the general rule. In Cantevia, a category cap doesn't block someone from submitting an expense -it surfaces when the report is being decided- and it can be overridden if it's a genuine exception, with the reason on record.

Asking a vendor how they handle exceptions, not just the normal case, says more about the quality of their support than any service-level clause in a contract. A system that only works well when everything goes as planned wasn't built for how a real company actually runs.

Questions worth asking before you sign

  • If your service is briefly unavailable, does the process block, or does it complete and get reconciled afterward?
  • Can I verify a piece of evidence -a signature, a clock-in- without depending on your platform still running?
  • Who sees my data when I open a support ticket, and under what permission?

The support that actually matters isn't the kind that replies fast to an email -it's the kind that means most of those emails never need to be written, because the system was already designed for the failure.