Help paths for evaluation, setup, and troubleshooting.
Support is a core part of the site foundation. Start with compatibility, FAQ answers, or feedback depending on where you are in the workflow.
Help should feel operational, not buried.
Compatibility, FAQ, guides, and feedback now sit together as one product support path.
Support is part of the product experience
Support is where users should confirm the next move when product and download pages do not fully answer their question. In the current first phase, the fastest path is usually compatibility first, FAQ second, blog guides third, and structured feedback last.
Support is intentionally placed early in the information architecture because global users need confidence and direction before and after download, not only marketing pages. It also repeats the privacy and feedback boundary so the site stays consistent under both search and support traffic.
The support page now answers the first routing questions directly
These short answer blocks make the page more useful to both users arriving from search and AI systems summarizing the help surface.
Start here if
You need to confirm fit, solve setup issues, or understand product boundaries.
Support is treated as a core page, not a footer-only afterthought.
Fastest self-serve path
Check compatibility, then scan the FAQ, then read a guide if needed.
The page now mirrors how real users evaluate and troubleshoot ScopeDock.
Feedback boundary
Structured feedback and anonymous analytics stay separate.
That distinction is repeated here so support language stays consistent across the site.
Current language scope
English first, with localized support-ready structure reserved for later.
The support architecture is already prepared for future high-value translations.
Choose the fastest help path
The site should help users self-serve when possible, then move cleanly into feedback or contact when needed.
Compatibility and known limits
Confirm platform support, protocols, storage assumptions, and current limits before deeper debugging.
FAQ for ScopeDock basics
Get direct answers to common questions about uploads, supported cameras, RTSP, source count, and file locations.
Guides and onboarding posts
Use the blog for setup walkthroughs, workflow explanations, and product updates that may answer edge questions faster.
Contact and structured feedback
Send bug reports, feature requests, compatibility questions, or business inquiries through the website feedback path.
Start here before writing in
The best support page helps users choose the right self-serve lane first, then escalate cleanly when needed.
Step 1
Re-check compatibility
Confirm platform scope, protocol coverage, and known limits before assuming the product should match every camera path.
Step 2
Identify the source type
Decide whether you are troubleshooting USB UVC, RTSP manual input, ONVIF discovery, or local file and capture behavior.
Step 3
Review permissions and storage
Camera permissions, local storage, and network reachability are common root causes in early evaluation workflows.
Step 4
Escalate with context
If self-serve guidance does not resolve the issue, use Contact and include camera type, protocol, platform, and expected behavior.
Support priorities in this first phase
The support page focuses on orientation and next steps. Deeper standalone FAQ, changelog, and help-center pages can grow from here.
Clear troubleshooting entry points
Users should quickly know whether to re-check compatibility, read a guide, or send feedback.
Privacy boundary stays clear
Anonymous analytics and structured feedback remain separate systems, even when support interactions are measured.
Multi-language ready structure
First phase is English-only, but the support content model is already prepared for localized high-value pages later.
Common troubleshooting lanes
These are the first diagnosis tracks the support page should make obvious.
USB camera or microscope not showing up
Re-check USB UVC compatibility, camera permissions, and whether the device behaves like a standard local video source.
RTSP or ONVIF path does not behave as expected
Review network reachability, discovery support, credentials handling, and then compare your case to the documented lightweight workflow.
Snapshots, recordings, or local files feel unclear
Check local storage assumptions, file handling expectations, and whether the workflow needs more product guidance rather than protocol debugging.
Platform expectation mismatch
Confirm whether the question is actually about current release scope, especially for planned platforms such as Windows or Linux.
Support can use temporary screenshots until the real capture batch lands
These mock screenshots make the support page feel more practical now and are designed to be replaced directly by the future real help captures.
Virtual source setup help
This mock makes the support page feel closer to a real setup guide while we wait for the final capture batch.
Virtual RTSP and ONVIF troubleshooting
This keeps network-source troubleshooting visual now and will later swap cleanly to the real RTSP and ONVIF capture.
Virtual capture and file-path help
This mock gives the support page a better visual anchor for file, recording, and history questions before real screenshots arrive.
Guides that solve common setup questions
These posts should sit close to support because they answer the most common evaluation and onboarding questions.
How ONVIF discovery differs from manual RTSP in ScopeDock
ONVIF discovery and manual RTSP solve different setup problems. ONVIF can make camera onboarding lighter, while RTSP is the direct path when you already know the stream endpoint.
How to troubleshoot camera permissions on macOS for ScopeDock
If a camera is not showing up in ScopeDock on macOS, the first checks are usually permissions, source type, and whether the device behaves like a standard local camera path.
Where ScopeDock saves snapshots and recordings
Users evaluating ScopeDock often want a plain answer about local files. The key question is not only where files go, but whether the workflow stays local-first and understandable.
ScopeDock essentials
Support starts by clearing up the most common questions before users have to write in.
Does ScopeDock upload my video by default?
No default cloud upload flow is part of the product positioning. ScopeDock is presented as a local-first tool, and the website keeps that boundary clear in both product and support copy.
What cameras are supported?
The current site explains support around USB UVC devices, RTSP manual input, and ONVIF discovery workflows. Exact compatibility can still vary by device implementation, especially for network cameras.
Does ScopeDock support RTSP?
Yes. The current first-stage product messaging includes RTSP manual input as one of the core connectivity paths for lightweight inspection workflows.
How many sources can I connect at once?
The website currently describes ScopeDock as supporting up to four sources in a lightweight multi-source layout. That limit is part of keeping the product focused on practical inspection work rather than dense surveillance-style grids.
Is ScopeDock available on Windows?
Not in this first website phase. Windows is represented as planned so users do not mistake the current support scope.
Still blocked?
Tell us what camera, protocol, or workflow you are trying to use and we can route that into the website feedback loop.