Troubleshooting
When support behavior breaks, the hardest part is usually not the fix. It is knowing where to look first. Random changes across settings, routing, and knowledge can make a small issue much bigger.
A calmer way to troubleshoot is to follow the same flow Jardine uses in production: message ingress, context quality, policy decision, ownership, and delivery outcome. If you debug in that order, root cause is usually clear quickly.
A Reliable Triage Sequence
Start with one affected conversation and walk layer by layer.
First, confirm ingress. Did the message actually arrive from the channel and appear in Conversations? If not, the issue is likely channel setup: webhook URL and secret handling, email forwarding/domain verification, or integration connection state.
Second, confirm context quality. If the message arrived but the answer is weak, inspect knowledge and validation evidence. Check whether relevant documents are indexed and active, and whether retrieved evidence matches the question.
Third, confirm policy decisions. If behavior escalated unexpectedly or failed to escalate when it should, inspect routing behavior and conditions. In manual routing mode, verify tag, destination, and rule logic. In default mode, verify whether the scenario should be explicitly constrained by manual controls.
Fourth, confirm ownership state. If conversation handling seems stuck, check whether the thread is assigned to AI or human and whether handover controls were used as intended.
Fifth, confirm delivery expectations. A correct internal decision with failed external delivery can look like “no response.” Separate decision correctness from channel delivery mechanics.
Using this sequence prevents guesswork.
Common Problems and Practical Fixes
One common issue is “connected channel, but no inbound conversations.”
In Email, this often means domain verification or forwarding is incomplete. In Zendesk, it often means OAuth is done but webhook URL/secret setup is incomplete. In Intercom, it may be connection state drift or misconfigured routing profile behavior if advanced controls are enabled.
Fix this by validating channel setup end to end, not just checking one status badge.
Another frequent issue is “answers are too generic.”
This usually points to knowledge quality, not routing policy. Check whether the relevant content exists, is current, and is indexed. Then run the same scenario in validation and inspect evidence. If evidence is weak, improve the source content first. Adjusting policy before fixing source quality tends to hide symptoms, not solve causes.
A third issue is “too many escalations.”
That can happen when source context is weak, when routing conditions are too strict, or when account-specific requests lack runtime context. If connector-backed data is required for a request type, validate connector health and template behavior before loosening escalation policy.
A fourth issue is “wrong conversations escalated to the wrong place.”
In manual routing mode, look for overlapping tag definitions, broad message-contains conditions, or unintended rule priority effects. Simplify first. Cleaner rule sets outperform clever rule sets.
A fifth issue is “connector tests fail intermittently.”
Start with credentials and provider availability. Then inspect template parameters and result expectations. Keep template behavior narrow and explicit. Intermittent connector behavior often comes from over-broad templates, schema drift, or unbounded test assumptions.
How to Recover Without Creating New Problems
When incidents are active, make one focused change at a time. Then re-test the same scenario. If you change multiple layers at once, you lose causal clarity and cannot be sure what actually fixed the issue.
It also helps to classify fixes as either immediate containment or long-term prevention.
Containment might be explicit handover to humans for a risky scenario or temporary policy tightening. Prevention is the structural correction: better source content, cleaner routing logic, safer connector templates, or stronger channel setup validation.
Teams that separate those two move faster and avoid repeated incidents.
Signals Worth Capturing During an Incident
Even a short incident note is valuable if it captures the right signals:
- affected channel and conversation examples
- observed behavior versus expected behavior
- layer where root cause was found
- exact fix applied
- follow-up action to prevent recurrence
You do not need a huge postmortem for every issue. You need enough clarity that the next similar issue is faster to resolve.
A Calm Default for Edge Cases
If behavior is uncertain and customer trust is on the line, route to a human and investigate. That is not a failure state. It is a safe operating choice.
The point of troubleshooting in Jardine is not to force automation in every edge case. The point is to restore predictable service quality quickly and improve the system so the same issue is less likely next time.
When your team follows a consistent triage sequence and keeps fixes layered and intentional, troubleshooting stops feeling chaotic. It becomes normal operational maintenance, which is exactly where you want it.
If you want quick answers to recurring launch and operations questions, continue with FAQ.