Submitting a support ticket

Watch the 3-min walkthrough above, then come back here when you hit a wall and need PropQuest engineering to look at your account.

Self-serve checks before filing

Before opening a ticket, two quick checks knock out 30% of "is this broken?" worries:

• Status page — /app/status (or status.propquest.ai) shows live uptime for search, reports, contracts, dialer, and skip trace. If something's red, we're already on it; sit tight.
• Hard refresh — cmd+shift+R (Mac) or ctrl+shift+R (Win/Linux) clears the stale JS bundle. A surprising number of "buttons don't work" reports resolve here, especially right after we ship.

If both look clean and the issue persists, file the ticket — your data is more useful than another retry.

Ticket vs. community

If you're stuck on workflow — "what's the right margin for a BRRRR in Tulsa?" — that's the community Discord. Other investors answer faster than we do and the back-and-forth is the value.

File a ticket when:

• Something is broken for your account specifically (payment failed, a credit didn't post, a contract won't send)
• You're hitting an error message with a stack trace or 500 page
• A report is wrong in a way we can verify (owner name doesn't match county records, ARV math looks off by 30%)
• You want a refund, plan change, or invoice outside what the billing page lets you self-serve

If it's a feature request, the Feedback button in the sidebar routes to the product backlog instead — that's the right channel for "I wish PropQuest did X."

Ticket categories

Pick the right category so the right person sees it first:

• Bug — something used to work or clearly shouldn't behave this way
• Account / billing — credits, wallet, subscription, invoices, refunds
• Data quality — a specific property's report is wrong
• Question — "how do I do X" when community didn't answer
• Feature request — punted to the backlog, but we read every one

Mis-categorized tickets get re-routed internally — it doesn't lose your place in the queue, but the first response is faster when the category is right.

What to include

The slowest tickets to resolve are the ones we have to ask three follow-up questions on. Front-load:

• What you did — the exact clicks or URL, not "I tried to skip-trace"
• What you expected — "I expected 1 credit charged and a phone back"
• What actually happened — error text, screenshot, the property ID
• When — within the last hour vs. "sometime last week" changes how we pull logs
• Account email — if you're emailing from a different address than your PropQuest login

Screenshots are gold. The little 📎 in the ticket form takes images, PDFs, and short screen recordings (under 25 MB).

Privacy and what we see

When you file a ticket from inside the app, we attach minimal diagnostic context automatically: your account email, the URL you were on, browser + OS, and the last 5 client-side errors from the session. No passwords, no payment info, no contact data from your CRM.

If you'd rather we not look at a specific property or contact during debugging, say so in the ticket body — we route to a privileged-access workflow that needs your explicit consent before opening that record. Default is hands-off your data; we only look at what's needed to fix what you reported.

What happens after you send

Every ticket goes through the same flow:

1. Triaged within one business hour during US weekday hours — categorized, prioritized, assigned
2. First response with either an answer, a fix ETA, or a clarifying question
3. Resolution — fix shipped, refund issued, or workaround documented
4. Closed with a one-line summary you can search later

You'll get email updates on every state change. Reply inline to add more context — the thread stays one ticket, no duplicates.

Following along

Open /app/tickets to see every ticket you've filed with current status. Click any one for the full thread including our internal notes (the ones we've chosen to share).

You can also filter by status (open / waiting on you / resolved) and search by subject — handy when you're sure you've reported something before and want to reference the resolution.

Response SLA

Soft targets, not contractual — we publish them so you can plan:

• Pro plans — first response within 4 business hours, fix or workaround within 2 business days for bugs
• Enterprise plans — first response within 1 business hour, dedicated Slack channel, named CSM
• Free / Starter — first response within 1 business day, community-first triage

Production-down outages (the whole app is unreachable, payments failing for everyone) skip the queue and page the on-call engineer regardless of plan.

When to escalate

If a ticket sits past the SLA without a first response, reply with the word escalate and the subject. That kicks it to a manager's inbox.

We'd rather you do this than stew — silence on our side is almost always a notification we missed, not us ignoring you. Two escalations in 30 days triggers an internal review of how the ticket queue is being run, so it's also feedback we genuinely use.