Getting help

Before you reach out

Three quick checks resolve a fair fraction of incoming questions without needing the team in the loop:

• Find the feature you have a question about in the docs hub and read the canonical page's Common Questions and Troubleshooting sections — the answer to most questions lives in context.
• If the symptom is something not working as expected, check the Common issues index — it groups problems by symptom category and points at the canonical-page troubleshooting section.
• If the issue looks browser-specific or device- specific, scan Browsers and devices — the known platform quirks (HEIC on Chrome on Windows, Safari iOS private-browsing cookies, in- app browser limitations) cover a meaningful slice of the “works for me, broken for them” reports.

How to reach us

The fastest channel today is email. Two addresses, each scoped to a different kind of message:

There's no published phone support line today. The team optimises for written communication so that messages can be triaged, screenshots attached, and the right person can pick up the thread — easier to do well over email than over a phone call.

What to include in a support message

The shape of a useful support message:

• What you were trying to do. One sentence on the goal — “trying to ring up a sale at the POS register,” “adding a new repair on a customer record,” “ running the daily reconciliation report.” The goal frames the conversation faster than the symptom alone.
• What happened. The specific symptom — what did you see, what error message did the page show, what did you expect to happen instead. If a toast or error banner appeared, the exact wording helps; if a button didn't do anything, say so explicitly.
• When it happened. Rough timestamp — “about 11:30 this morning,” or “Tuesday afternoon” — lets us narrow the logs.
• Where in the app. The URL of the page, or the navigation path (“Inventory → Add Item”, “Settings → Team & Roles”). Page URLs are the fastest reference; the path words also work.
• Which tenant. If you have more than one tenant or you work across tenants, name the one this happened on. For most people there's only one and we can resolve it from the email-sender address.
• A screenshot if relevant. A picture of the screen — including the error message and the surrounding context — saves a round-trip on visual issues.
• Browser and device, if it might matter. “Chrome on Windows,” “Safari on iPad,” etc. Often not necessary; useful when the symptom looks like it could be browser-specific (see Browsers and devices).

The most common round-trip-cause is “a screenshot would help here.” If you're reporting a visual or interaction issue, the screenshot in the first message saves us asking and you sending one second-round.

Response timing

Both the contact-form auto-reply and the in-app support chat surface state that we typically respond within 24 hours on business days. That's the target the team works to. It's a typical- response figure, not a contractual SLA — there's no published service-level agreement on response timing today.

What that means in practice:

• Most support emails get a first response within a business day. Bug reports with a screenshot typically get a triage reply faster than vague symptom descriptions because there's less back-and-forth needed.
• Urgent operational issues — POS register down, can't sign in at all, payment processing failing — are triaged faster. If you have a register-down situation during business hours, the right framing in the subject line is “URGENT — POS down” so the message gets picked up at the top of the inbox.
• Out-of-hours and weekend messages get the next business day's first response. The team doesn't guarantee weekend coverage; messages sent Friday evening land Monday morning.
• Feature requests and longer-form product feedback get read but may take longer to reply to in detail. The triage shape there is: a quick acknowledgement on the way in, then a more detailed reply when we've thought through how the request fits the roadmap.

The team is small. The trade-off is that you're getting a thoughtful response from someone who knows the product, rather than a templated first-tier reply that needs escalation; the cost is the 24-hour shape rather than instant. If you'd benefit from a dedicated-account-management shape with faster response targets, that's a conversation — see Contact us.

Which channel for which kind of issue

What you can expect in return

A real reply from a real person on the team, with the information needed to move the issue forward. If we're missing context to triage the message, we'll ask for the specific thing that would help — not a generic “please send more information” reply. If the issue points at a real bug, the response includes the next step (when a fix is expected, what the workaround is in the meantime). If the issue is a feature gap, the response is honest about whether it's on the build list, on the wish list, or unlikely to be built — saying “not soon” clearly is more useful than saying “we'll consider it” ambiguously.