Using In-App Support

Siteimp includes support inside the application so help is available from the screen where you need it. Instead of leaving the app, searching through a manual, and guessing which article applies to the page in front of you, you can open the HelpDrawer and read the support document written for that exact route.

This section explains how the in-app support system works as a complete support workflow: reading page-specific help, contacting technical support, reviewing optional diagnostics, and understanding how support requests are delivered.

What in-app support is for

Siteimp is a local-first Windows application for inspecting websites, monitoring availability, reviewing scan evidence, and understanding the operational health of a site. Many screens are evidence-heavy by design. They are not just lists of buttons; they explain scan results, page structure, links, media, accessibility, monitoring state, and support context.

In-app support exists to make those screens easier to understand while you are using them. Each support document is written around practical questions:

• What is this screen for?
• What information does it show?
• What actions can I take here?
• What should I check next if something looks wrong?
• When should I contact support?

The goal is not to bury users in documentation. The goal is to keep help close to the workflow, close to the evidence, and close to the moment where a question appears.

The main pieces

Siteimp’s in-app support system has three main pieces.

The HelpDrawer is the help panel inside the application. It opens from the Need help? control and shows the support article for the current screen. When you move through the app, Siteimp can load a different support document for the route you are using.

The technical support form lets you contact Siteimp support from inside the application. It collects your message, basic screen context if you allow it, and optional diagnostics if you choose to run and include them.

The web support library mirrors the in-app support content on the Siteimp website. This makes the same guidance available outside the app, useful for sharing links, reviewing workflows, or reading support material before opening Siteimp.

How to open help inside Siteimp

To open in-app help, click Need help? in the lower-right corner of the application. Siteimp opens the HelpDrawer with the support document for the screen you are currently using.

The HelpDrawer is designed to stay out of your way. It does not take over the application like a modal dialog. You can keep the drawer open while you look at the page, compare the instructions to what you see, and decide what to do next.

If the current screen has a dedicated support article, Siteimp shows it directly. If a dedicated article is not available yet, Siteimp shows a fallback message so you still know support is available.

How to contact technical support

From the HelpDrawer, choose Contact tech support. Siteimp opens a guided support form that walks through the request one step at a time.

The support flow is designed to keep consent clear:

1. You decide whether to include basic app context.
2. You describe what you were trying to do, what happened, and what you expected.
3. You provide contact information so support can reply.
4. You can run optional diagnostics and review the results.
5. You review the final report before sending it.

After the request is sent, Siteimp shows a support request ID. That ID helps tie the in-app confirmation to the support message received by the Siteimp team.

What basic app context means

Basic app context is lightweight information about where the support request started. It can include the screen where you opened support, the screen where you submitted the request, the related help document path, and the time the support context was captured.

This context helps support understand where you were in the application without asking you to re-create the route by hand. It does not replace your description of the problem. Your notes still matter most.

How diagnostics work

Diagnostics are optional. Siteimp can run a small local diagnostic check before you send a support request. The diagnostic report can include practical support signals such as app version, platform, operating system version, database reachability, storage availability, connectivity checks, workspace counts, and recent support or scan status.

Siteimp shows the diagnostic results before they are included. Running diagnostics is the first consent step. Including diagnostics in the final support request is a second consent step. You can run diagnostics, review the results, and still choose not to include them.

Diagnostics are meant to answer basic support questions quickly. They are not a full log bundle, and they are not a complete scan investigation. If support needs logs, the support team can ask you to use the dedicated support tools workflow.

How support requests are delivered

Siteimp sends support requests through Formimp, a private support and contact transport used by Greg Hluska Consulting. Formimp delivers support messages to a Slack or Discord channel so requests can become conversations instead of getting stuck in an isolated inbox.

This helps the Siteimp team respond faster, notice recurring issues, and turn support requests into product improvements. It also means messages delivered through Slack or Discord are subject to the privacy policies and handling rules of those services.

For more detail, read About Formimp.

When to use the web support docs

The web support docs are useful when you want to read support material outside the app, share a support page with someone else, or review a workflow before you open Siteimp.

The in-app and web support libraries are meant to reinforce each other. The app keeps help close to the screen. The website makes the same guidance easier to browse, link, and revisit.

Related support guides

• Using the HelpDrawer
• Contacting Siteimp Support
• About Formimp
• In-App Support Library

In-app support is part of Siteimp’s larger design philosophy: keep evidence near the action, keep explanations close to the screen, and make support feel like a natural part of using the application rather than a separate emergency exit bolted onto the side.