Skip to main content
Quartyl
Help & Supportbeginner

Contact Support and Priority Support

How Quartyl support actually works in the product: the standard and priority cards on the Support tab, the feedback form and its webhook, and what the priority_support plan feature really changes.

Quartyl Team

One in-app entry point: Help & Feedback → Support. Every firm gets the standard card; firms whose plan holds the priority_support feature get the priority card in its place. Read the status note below before you treat anything on those cards as a contract.

What is on the Support tab

The tab renders one of two cards, chosen by the plan feature:

Card Shown when Fields it renders
Standard Every firm without priority_support One support email address and a response-time line
Priority The firm’s plan holds priority_support A priority address, an escalation address, a phone line, a WhatsApp line, and four badges: response time, coverage window, named account manager, senior-engineer escalation

The standard card is the only card otherwise. There is no lock panel and no “upgrade for priority” prompt — plan-gated UI in Quartyl is hidden, not locked, so the absence of the priority card is the entitlement state, not an error.

What the card does and does not promise

The addresses, the phone lines and the badge wording on both cards are frontend display defaults held in a constants file (frontend/src/app/core/constants/help.constants.ts). The comment on that file says it plainly: the platform team can change them without a backend deploy. They are configuration, and a fresh deployment ships placeholder values in them.

So, precisely:

  • The card is not a service level agreement. No ticket queue, routing rule, response timer or escalation path is implemented in the product. What you are owed — response times, coverage, a named contact — comes from your engagement agreement, and that document is the authority.
  • The named account manager is a description, not a feature. It appears in the badge list and in the plan catalog’s one-line description of priority_support; nothing in the application creates, assigns, or displays an account manager.
  • Check the card you are shown. Because the values are display config, the Support tab is the current rendering, not a promise about who answers. If the contact on your card is not the one in your agreement, raise it with your Firm Admin.
  • One quirk: accounts with no tenant and no plan signal fail open and render the priority card. Seeing the card is therefore not proof of entitlement; the plan held by your firm is.

The Feedback tab (what it really is)

The Feedback tab is a categorized form, not an inbox:

  • Fields: a subject (120 characters), a category — Bug Report, Feature Request, Product Feedback, Documentation, Billing & Plan, Something Else — and a message between 10 and 2,000 characters.
  • Where it goes: the form POSTs JSON to the deployment’s configured feedback webhook. The payload carries the subject, category and message, your name and email from your session, the page you submitted from, a priority flag set when your plan holds priority_support, and a submission timestamp.
  • What it is not: it does not create a ticket with an ID, it does not open a thread, and the product does not track or display a status for it. There is no portal to check. If the matter needs a response, use the contact route in your agreement.
  • If it fails: a deployment without a webhook URL configured rejects the submission with “Feedback is not configured yet.” That is a deployment setting (feedbackWebhookUrl in the frontend environment), not a problem with your text. Use the support contact instead and tell your Firm Admin.

The tab itself is identical for every firm — same fields, same categories. The only difference the feature makes is the priority value on the payload.

First checks before you contact anyone

Most support tickets in a platform like this are entitlement or state questions, and both are answerable from inside the app:

  1. Is it a role boundary? A 403 on an action means your role does not carry it. Your Firm Admin can see the assignment.
  2. Is it a plan boundary? A capability that is simply absent from your sidebar is gated by a plan feature, not broken. See plan features.
  3. Is it the study’s state? Review, sign-off and archive change what the study accepts. See study lifecycle.
  4. Is it a link or a dump expiry? Presigned download links last minutes, and the working dump has a per-tenant retention window. Both are covered in troubleshooting.
  5. Is it a session? Access tokens are short-lived by default; signing in again is the fix, and a password reset revokes your other sessions on purpose.

Write a submission that moves things

A complete submission gets resolved faster, on either tier. Include:

  1. What you were doing (the screen or the pipeline step).
  2. What you expected to happen.
  3. What actually happened (the exact error text).
  4. The study name, or a screenshot.
  5. Your role, your tenant, and your browser.

See it working in your workspace

Sign in to run the steps above on a real study — or book a demo and we will walk the workflow end to end.

Related docs

Book a Demo

Tell us what you'd like benchmarked

We'll confirm a 30-minute screen-share slot within one business day.

We reply within one business day. Your details are used only to arrange the demo — never shared or sold.