Submit a Support Ticket Properly

A good support ticket is specific, calm, and complete. This tutorial shows you exactly what to include — and what not to do after you've filed a report.

Best Practice 5 min read Support Troubleshooting

Know when to use support vs. self-serve

Open support from the correct in-app route

Write a ticket that answers support's first question

Stop experimenting once you've escalated

When to Use Support

Support is the right move when you have moved past a simple self-fix. Use it when:

Use Support When

You already tried the correct workflow and something still failed

A permissions or access issue is not resolving normally

An upload problem is not explained by file type, signs, or duplicates

A formula or structure issue cannot be safely undone

A guest or access problem persists after checking the correct email

Good vs. Bad Ticket

The difference between a fast resolution and a long back-and-forth usually starts with the quality of the first message.

❌ Bad Ticket

"It's not working."

"My upload failed."

"Something is broken."

Support has to ask: what tab, what file, what happened, what did you expect? That adds one full exchange before anything is resolved.

✓ Good Ticket

"I was in the Account Upload Center trying to import a CSV for my Chase checking account. After selecting Traditional Account and uploading, the review screen showed no rows. I expected to see about 45 transactions."

Support immediately knows the tab, the file type, the account type selected, and what the expected vs. actual result was.

5 Steps to a Good Ticket

Open the Support Flow from the Official In-App Route

Use the built-in support route in the workbook rather than sending a vague outside message. Support opened from within the system automatically carries context that a cold outside message does not.

Depending on the build, support may be available from the Access Support menu, Navigation Menu, or other user-facing help entry points.

Describe What You Were Doing

Before you send anything, write down:

What tab or modal you were using
What you clicked
What you expected to happen
What happened instead

Good support messages are specific. Bad ones say only "it's not working."

Include the Useful Details

If relevant, include:

Whether you were in Personal or Business
Whether the file was CSV, Excel, or PDF
Whether the issue happened during upload, move, categorization, reporting, access, or export
Whether you already tried Undo
The exact text of any error message

Add a Screenshot If Possible

If something looked wrong on screen, include a screenshot. This is especially helpful for:

Wrong totals or report mismatches
Duplicate rows in the upload table
Strange formatting or permission prompts
Any visible UI error

Stop Experimenting After You've Escalated

Once you submit a support ticket for a structural or confusing issue, stop trying random fixes. Support works best when the state of the problem is stable — not when five new changes happen after the report was submitted.

Ticket Quality Checker

Use this to practice writing a complete ticket before sending. Check each field to see your completeness score go up.

Support Ticket Builder

Where were you?

Name the tab, modal, or section you were working in.

What did you click or do?

What did you expect to happen?

What actually happened?

Additional details (check all that apply)

Personal or Business is specified File type (CSV / Excel / PDF) is mentioned Mentioned whether Undo was tried Exact error text is included Screenshot is attached

Ticket submitted. Stop experimenting — support will follow up.

Common Mistakes

Waiting too long to document the issue

Capture it while it is fresh. The exact sequence of actions and the exact error text are easiest to remember immediately after the problem occurs. Write it down before you close anything.

Sending no context — "it's not working"

Support should not have to guess whether the problem was access, upload, paste, or categorization. Telling them where you were and what you clicked narrows the problem down in the first response instead of the fourth.

Trying random cleanup before writing in

This often creates a second problem on top of the first. The support team can only work with what they see. If the state of the issue has changed because of additional edits, the original problem becomes harder to diagnose.

What Not to Do

Do not overwrite more cells trying to "show the issue" — preserve the original state.
Do not delete rows to simplify a screenshot — the original data matters.
Do not assume support can infer your last ten clicks without you telling them.

"The fastest support experience usually comes from the calmest report: what you did, where you were, what happened, and a screenshot. That is enough far more often than people think."

What to Do If Upload Fails