Siteimp includes a built-in support flow so you can contact technical support without leaving the app, hunting for a separate form, or trying to describe the screen you were on from memory.

The support form is available from the Help Drawer. It lets you explain what you were trying to do, what happened, what you expected, and how Siteimp support should contact you. When useful, you can also run a small diagnostics report and review it before deciding whether to include it.

The goal is simple: make support requests easier to send, easier to understand, and easier for Siteimp to turn into useful follow-up conversations.

What in-app support is for

In-app support is for situations where you are stuck, something does not look right, or Siteimp behaved differently than expected.

Use it when:

  • a scan did not work the way you expected
  • a page shows confusing or missing information
  • monitoring results look wrong
  • you are not sure what a status means
  • a support article does not answer your question
  • you want to report a bug or rough edge
  • you need help understanding what Siteimp is showing

The support form is not meant to replace the in-app help documents. It works beside them. The Help Drawer gives you the relevant support article first, and the contact form is available when you still need help.

Where to find support in the app

To contact Siteimp support:

  1. Open Siteimp.
  2. Go to the screen where you need help.
  3. Open the Need help? control in the lower corner of the app.
  4. Choose Contact tech support.
  5. Complete the support form.
  6. Review the report.
  7. Send the report when you are ready.

Starting from the screen where the issue happened is helpful. Siteimp can include basic screen context, such as the page where the support request started and the page where it was submitted.

What the support form asks for

The support form is split into clear steps.

Privacy

The first step explains what Siteimp can include with the request.

Siteimp can include basic app context, such as:

  • the screen where the support request started
  • the screen where the request was submitted
  • the help document connected to that screen
  • the report time

This context helps support understand where the request came from without asking you to manually describe the app location.

Problem

The problem step asks what happened.

You can describe:

  • what you were trying to do
  • what actually happened
  • what you expected to happen
  • any urgency or deadline

You do not need to write a perfect bug report. A plain description is enough. For example:

I was trying to run a scan for a website I just added.
The scan looked like it started, but then the page did not update.
I expected to see scan progress or a clear error message.

Contact

The contact step asks how support should reach you.

It includes fields for:

  • name
  • email
  • special contact instructions

Contact instructions are useful if you prefer a specific reply method, have a deadline, or want to add context such as your time zone.

Diagnostics

The diagnostics step is optional.

Diagnostics run a small local check and show the results before they are included. This gives you a chance to review what Siteimp found before deciding whether to attach the diagnostics to your support request.

Diagnostics are useful when the issue may involve:

  • network access
  • local app storage
  • database access
  • support delivery
  • scan or monitoring state

You can run diagnostics, review the summary, and then decide whether to include them.

Report review

Before anything is sent, Siteimp shows a final report preview.

This preview is the important consent step. It lets you see the message, contact details, screen context, and optional diagnostics before sending the request.

If something does not look right, go back and edit the form before sending.

What diagnostics include

Diagnostics are designed to be small and practical.

They may include information such as:

  • Siteimp app version
  • operating system platform
  • system architecture
  • operating system version
  • whether the temporary directory is available
  • whether the app data directory is writable
  • whether the local database is reachable
  • whether the internet is reachable
  • whether the support endpoint is reachable
  • how many websites are in the local workspace
  • whether scans are active or queued
  • whether monitoring targets are enabled
  • whether recent support requests failed

Diagnostics are not meant to collect everything. They are a quick support check, not a full log export.

Siteimp does not attach logs to the standard support request. If support needs logs, we will ask you to copy them from the support tools page.

What diagnostics do not include

The standard diagnostics report is intentionally limited.

It does not include:

  • full scan logs
  • full application logs
  • website content
  • full database contents
  • passwords
  • browser history
  • unrelated local files
  • screenshots
  • private documents

The diagnostics report is there to answer basic support questions quickly. For example, it can help confirm whether the app has local storage access, whether the database responds, and whether the support endpoint can be reached.

How Formimp sends the request

Siteimp uses Formimp to deliver in-app support requests.

Formimp is the lightweight message delivery system used by Siteimp support. When you send a support request, Siteimp prepares the report and Formimp sends it to the Siteimp support channel.

For Siteimp support, that channel is currently connected to Slack.

This means your support request appears where the Siteimp team can see it, discuss it, and follow up. The goal is not just to receive a message. The goal is to turn support requests into useful conversations and product improvements.

Why support requests go to Slack

Slack is useful for support because it keeps requests visible and discussable.

A support request can become:

  • a direct reply to the user
  • a bug report
  • a documentation improvement
  • a product polish task
  • a future support article
  • a better error message
  • a clearer workflow in the app

This is especially important during early releases. A confusing support request may point to a confusing part of the product. A good support system should help the team fix the cause, not only answer the message.

What happens after you send a support request

When you send the report, Siteimp attempts to deliver it through Formimp.

If delivery succeeds, Siteimp shows a confirmation with a support request ID.

The support request ID is useful if you need to refer to the request later. It also helps Siteimp connect a support conversation to the original report.

After the request is sent, the Help Drawer returns to the support article for the current screen. This keeps the help system available without leaving the support form open after submission.

If sending fails

If Siteimp cannot send the request, the report is not lost.

The support form keeps the report available so you can copy it and send it by email instead.

This fallback matters because the most frustrating support failure is losing the message you already wrote. Siteimp is designed to keep the report visible when delivery fails.

If sending fails:

  1. Review the error message shown in Siteimp.
  2. Use Copy report.
  3. Email the copied report to Siteimp support.
  4. Include any extra detail that may help explain what happened.

When to include diagnostics

Including diagnostics is helpful when the issue may involve the app environment, local database, support delivery, networking, monitoring, or scan state.

Good reasons to include diagnostics:

  • support requests are failing
  • scans are stuck or not starting
  • monitoring does not seem to run
  • the app cannot save data
  • the app reports a database issue
  • something works on one computer but not another
  • Siteimp support asks for diagnostics

If your question is simple, you can skip diagnostics.

For example, you may not need diagnostics if you are only asking what a label means or where to find a feature.

Reviewing diagnostics before sending

Siteimp shows diagnostics before sending them.

The diagnostics view is designed to summarize the important parts first. It can show whether key checks passed and whether any problems were found.

A technical details section may also be available for deeper inspection. This is mainly useful for support or for users who want to see the exact diagnostic payload.

You control whether diagnostics are included in the final support report.

Privacy choices

The support flow is built around review and consent.

Before sending, you can review:

  • your problem description
  • your contact details
  • the screen context
  • whether diagnostics are included
  • the diagnostics summary, if diagnostics were run

This makes the support request explicit. Siteimp should not surprise you with a hidden bundle of support data.

Tips for writing a useful support request

A useful support request does not have to be long.

The most helpful details are usually:

  • what you were trying to do
  • what happened instead
  • what you expected
  • whether it happened once or repeatedly
  • the website or scan involved, if relevant
  • whether there is a deadline

Good example:

I was trying to run a scan for example.com.
The scan started, but the progress area stopped updating after the mapping step.
I expected Lighthouse results to appear.
This happened twice after restarting the app.

Less helpful example:

It broke.

Even then, send the request if you are stuck. The support flow exists because real problems are not always easy to describe neatly.

Troubleshooting

I do not see the Help Drawer

Look for the Need help? control in the lower corner of the app.

If the control is not visible, try resizing the window or navigating to another screen. If it still does not appear, contact support through the website.

The support article does not answer my question

Use Contact tech support from the Help Drawer.

The support article gives the first layer of help. The support form is there for questions the article does not answer.

Diagnostics failed

If diagnostics fail, you can still send the support request without diagnostics.

A diagnostics failure may itself be useful information. Mention what happened in the problem description if the app shows an error.

Sending failed

If sending fails, use Copy report and send the report by email.

The report should remain available in the support form so you do not have to rewrite it.

I sent the request twice

If you accidentally send more than one support request, that is okay.

The support request ID helps separate requests. If you follow up by email, you can mention which request should be ignored or which one has the better details.

Where to go next

To learn more about the support system, read:

  • Using the Help Drawer for how screen-specific help works
  • About Formimp for how Siteimp delivers support messages
  • In-app support for the full list of app support articles

The support form is one part of the larger Siteimp support system. The Help Drawer explains the current screen, the support form lets you ask for help, and Formimp delivers the request so Siteimp can respond and improve the product.