Getting help

You shouldn’t need to email support often. Most things either work or have an obvious next move. But when something is stuck and you need a person, this is how to reach one.

In-product help

Your first stop should be your AI itself.

“I’m trying to do X and it isn’t working. Help me diagnose.”

Your AI has access to your instance’s logs, configuration, and activity. It can often diagnose a problem (a misconfigured integration, an expired credential, an unintended gate) faster than support could because it has all the context.

When your AI hits its limit, it’ll tell you. (“I see the error, but I’m not sure why it’s happening. This is worth escalating.”)

Email support

The main support channel is support@jootle.com.

What to include in a support email:

What you were trying to do. Short description, plain language.
What happened instead. Including any error messages, exact phrasing.
The timestamp. Roughly when this happened.
A screenshot or copy of the relevant chat / activity log entry if helpful.

We respond within:

24 hours for Starter and Pro plans, weekdays.
8 hours for Business plans, weekdays.
2 hours for Enterprise plans with priority support, weekdays and weekends.

Response times go longer on weekends and holidays for plans without weekend coverage. If something is urgent (the instance is down, security incident), say so in the subject line (“URGENT: …”); urgent issues get triaged regardless of plan.

When to escalate

Cases where you should escalate rather than ride out the regular queue:

The instance is down. You can’t reach it at all.
A security concern. You suspect unauthorized access, you discovered a vulnerability, you got an email that looks suspicious.
Data loss that auto-recovery doesn’t fix. You need a backup restore.
A billing problem that prevents you from using the product.

Escalation channels:

For instance-down or critical: support@jootle.com with “URGENT” in the subject.
For security: security@jootle.com.
For billing: billing@jootle.com.

These reach the same team but route faster.

Feature requests and feedback

Feature requests are different from support. They go to:

The feedback button in the web app (Settings → Feedback).
Or directly: feedback@jootle.com.

We read all of them. We don’t promise to build every requested feature, but the patterns in feedback drive what we prioritize.

If you have a specific use case that Jootle doesn’t fit yet, telling us is worth your time and ours. A short note (“here’s what I wish I could do”) with a real example is much more useful than a feature list.

Public communities

Two public spaces if you want to talk to other customers:

The Jootle community forum (link at jootle.com/community). For asking questions, sharing toolkits, comparing notes. Moderated, friendly.
Discord / Slack (link in your instance’s settings). For real-time chat with other customers and the team.

These are not support channels; we don’t guarantee response time. But they’re often the fastest way to learn something from someone who’s done it before.

The documentation hierarchy

When you’re looking for an answer:

This handbook (docs.jootle.com). Plain-language explanations of how things work.
The Jootle blog (blog.jootle.com). Field notes, design decisions, and announcements.
The developer reference. Linked from the handbook where relevant; technical specs for custom toolkits and integrations.
The white papers. Security, compliance, architecture deep-dives. Available on request.

If something is missing from the handbook, that’s a problem we want to fix. Tell us via the feedback button on any page.

Working with us when something is broken

A few practices that help us help you:

Don’t try ten things in parallel. If something doesn’t work and you’re emailing support, freeze the state of your instance until we get back to you. Multiple parallel attempts to “fix it” usually obscure the cause.
Save error messages. Screenshots, copy-paste of error text, the relevant section of the activity log.
Tell us what you’ve already tried. Saves us from suggesting the obvious fix you already tried.
Reply in-thread. Keeping the email conversation in one thread keeps the context intact.

We aim to be quick, thorough, and honest. If we made a mistake, we’ll say so. If your question is something we don’t know yet, we’ll say that too and tell you what we’ll do to find out.

What support won’t do

A few boundaries:

Support won’t access your conversation content or knowledge graph without your permission. If diagnosing a problem requires us to look at content, we’ll ask. (Data, privacy, and exports covers this.)
Support won’t take destructive actions on your behalf without confirmation. Even when you’ve explicitly asked, we’ll confirm before deleting, restoring, or migrating.
Support won’t promise to keep something confidential that affects other customers. A security vulnerability you report stays confidential as part of responsible disclosure, but it can’t be a permanent secret if it affects others.

A note on cadence

Most customers email support a handful of times in their first few months and then less. The first weeks are when the setup edge cases come up; after that, things settle.

If you’re emailing support every week, something is genuinely off and we’d want to know. Sometimes it’s a misconfiguration, sometimes it’s a use case we’re not serving well, sometimes it’s something we’re about to ship that would fix it. Either way: tell us.