Quick answer: Open one clear support request with exact device/revision and firmware, actual topology, symptom/timestamps, impact, recent changes and the results of approved checks. Share only the relevant permitted evidence through the agreed private channel; exclude passwords, QR/device-add secrets and unnecessary footage. The ten-item list helps support assess the next step, but does not guarantee a first-reply fix or a response deadline.
On this page
What are the 10 items technical support asks for?
Support delays can have several causes, including missing facts, reproduction, outside dependencies or a model-specific issue. Use this checklist to make the request useful without delaying an urgent fault while you collect every item. State impact, preservation needs and missing information; agree priority and the next update with support.
| # | Information | What to record/share |
|---|---|---|
| 1 | Full SKU, lens, hardware revision and supplied identity | Copy label and reported model; flag any mismatch rather than choosing firmware by a similar name |
| 2 | Device and client versions | Full camera/NVR firmware and app/platform build strings; not just latest |
| 3 | Actual device/view/port mapping | Recorder, logical channel, physical PoE/switch port and stable site ID; no assumed one-to-one mapping |
| 4 | Topology and approved access path | Camera-to-recorder-to-client route, interfaces, power and relevant network boundaries |
| 5 | Symptom and timing | Exact error/function, first known occurrence, frequency, time zone and observed clock offset |
| 6 | Recent changes | Authorized firmware, account, network, cable, power or environment changes; separate reports from verified facts |
| 7 | Relevant images/screens | Readable permitted label/status/error evidence, with secrets and unnecessary people/site details removed |
| 8 | Available logs | Supported relevant export and time basis; no promise that a particular menu or fault log exists |
| 9 | Checks and outcomes | Approved steps in order with actual observations and anything left untested |
| 10 | Case/account and contact | Business/project reference and relevant serial privately, authorized site contact, impact and agreed session availability |
Use the list as a request structure, not proof that support can resolve the fault in one exchange. Missing or inconsistent details are worth stating explicitly. Keep one case reference and document the agreed next action, responsible person and update time; no response or repair commitment follows from checklist completeness. Use the partner support workflow to agree case ownership and the next update.
How do you read the full SKU and firmware version from the device?
Use the complete SKU, suffix/lens and actual revision. For example, CS-I8XQ I-2.8mm and CS-I8XQ II-2.8mm have different catalog IR/white-light and media rows: the former lists 30 m IR, 15-20 m white light and 512 GB; the latter 50 m IR, 30 m white light and 1 TB. Those rows are not performance guarantees or proof of firmware compatibility. Send label/reported-name differences to support before choosing any update or replacement.
Where the SKU is printed
- Use the safely accessible unit/box label and permitted purchase or camera-schedule records.
- Copy the exact model/revision string reported by the actual device or supported client where accessible; menu names and exposed fields vary.
- Keep relevant serial/order details in the private case, not a public screenshot or general blog comment. Never send credentials, recovery codes or device-add QR secrets.
Where the firmware version is shown
Use the exact model’s supported information screen or current manual to locate full firmware/build details. A recorder may not expose every camera field through its channel list. Do not bypass isolation or permissions to reach a camera directly. Where information is unavailable or label/reported strings differ, include both known values and the missing field so support can reconcile it.
How do you sketch the topology in five lines?
Describe the actual camera-to-recorder and recorder-to-client paths. Five short lines are a useful template, not a requirement to disclose the entire customer network or a guarantee that the path is understood. Redact unnecessary site/identity details while retaining enough structure for the agreed review. The camera network planning guide explains the topology terms.
- Camera/view: exact device, physical power/data path, actual logical mapping and relevant route condition.
- Recorder: model/firmware, interfaces and required recording/client workload.
- Network: approved subnets/routing/VLAN/firewall/DNS/address policy and responsible IT contact; use permitted redacted details.
- Client: actual software/platform/version and approved local/remote connection method.
- Power: actual source/variant, relevant peak budget, UPS and symptom timing; do not substitute daytime load for peak evidence.
CS-N220 P16H-AI lists a gigabit Ethernet interface plus sixteen 100 Mbps PoE interfaces; CS-POE33024PF lists twenty-four gigabit PoE ports and two gigabit SFP interfaces. These rows do not establish the installed subnet, automatic mapping or path. Record actual configuration and approved reachability. Camera network basics explains terminology; NVR not showing cameras covers power, link, addressing and integration checks without assuming every offline event has one of two causes.
Which logs, screenshots and “recent changes” actually help?
Use focused, readable images of relevant status, supported information screens and exact errors. Obtain permission and remove passwords, keys, access QR codes, unnecessary footage and sensitive site details before sharing through the agreed private route. Label each image with device, time basis and observed context. A screenshot helps explain a symptom but is not a complete recording or diagnosis.
Logs are one possible record; they can be missing, incomplete or use an incorrect clock. Export only by the supported method, retain relevant originals and record time zone/offset and any changes. If recordings may be evidence, follow the approved preservation process before changing the clock/settings or resetting equipment. The NVR time and date guide covers planning a documented correction, not a silent retroactive timestamp fix.
Ask the authorized site and IT contacts about recent power, network, account, cable, firmware and environment changes. Mark what is reported versus verified and keep the chronology neutral. A recent change is a diagnostic lead, not proof that the person or component caused the fault; do not promise it will end the call.
How do you describe the symptom precisely?
Describe the failing function and what remains working. A short structured paragraph can give support a useful starting point without a speculative root-cause claim:
- Which device, by full SKU and channel.
- What you see: no link, no video, video but no recording, wrong image, no remote access.
- Since when, with the first timestamp, and how often: constant, every night, after rain, after a reboot.
- Where it shows: local monitor, camera web page, CASE Connect, all three.
- What changed just before it started.
- What you tried, in order, and what happened each time.
Illustrative report: CS-I8XQ II-2.8mm, current firmware strings in the private case, mapped to channel/port 7 of CS-N220 P16H-AI. The recorder reports offline on the listed nights; other views remain available. Relevant clock offset/logs and authorized cable/port/power checks are attached with their actual results. A bench test did not reproduce the fault under its recorded conditions. This narrows the next checks but does not prove the cable is bad or the camera is healthy under site/night/peak-load conditions. See the intermittent disconnect guide for controlled checks.
Separate observed facts, customer reports and untested hypotheses. For a feature question, name the complete task and required device/client versions and request written confirmation where needed. For a required ONVIF conformance claim, verify the full model and firmware in the official ONVIF database. Then test the required streams, recording, playback and events with the actual client/version. A profile list or brand name is not a complete integration statement.
Why does support go through your business account, not the end user?
Anabon supports installers, integrators, dealers and approved business accounts through its B2B channel. The supplying/service company normally leads the end-customer case. Agree who is authorized to participate, what information may be shared and who owns each next action; do not turn that channel policy into a blanket promise that no customer/IT contact can join an agreed technical discussion.
Start with the technical support page or agreed business-account route and keep the same case reference. For service/warranty, the end user normally starts with the installer or supplying company. Agree any additional authorized participants. A possible hardware fault does not automatically create an approved replacement: the warranty and RMA process and how Anabon supports partners describe the information and authorization steps.
What to tell your customer
We will coordinate the product support request and keep you informed about verified findings and the agreed next step. We will share only authorized relevant information. A support case is not yet approval for warranty coverage, replacement or a repair deadline; those depend on the actual fault and written terms.
FAQ
Why does support insist on the full SKU when I have already said which camera it is?
A suffix, lens or revision can change the hardware, supported firmware and relevant specifications. CS-I8XQ I-2.8mm and CS-I8XQ II-2.8mm illustrate different printed light/media rows; that difference is not permission to use one firmware on both. Provide label/reported identity and exact versions so support can resolve the actual model before advising a change.
Can my customer call Anabon technical support directly?
For service and warranty, the end user normally contacts the installer or company that supplied the system; Anabon works through its installer/dealer/business-account network. The responsible parties can agree authorized customer or IT participation for a specific case. Confirm that arrangement rather than promising universal direct access or universal exclusion.
What should I export from the NVR before I open a request?
Collect permitted relevant model/firmware, exact error/channel status, topology and available logs with their time basis. Menu/export options differ by model/firmware. Redact secrets and unnecessary footage and use the agreed private route. If evidence may be at risk, state that immediately and follow the approved preservation process before configuration changes. Use the NVR time and logs setup guide for the supported status and time-basis checks.
Is a warranty replacement part of the same request?
It may be coordinated under the case reference, but eligibility, diagnosis, authorization, replacement and shipping follow the exact item’s written terms and RMA process. General category policies are a starting point, not a warranty for every SKU. Confirm the term, exclusions and claim process for the exact model and revision in writing. Project Series items, intercoms, powered accessories and model-specific exceptions need their own confirmation; hard-drive claims follow the applicable drive-manufacturer terms. Do not ship or promise a replacement before instructions and approval; agree the authorized customer/service route for the case.
References
- Anabon Technical Support
- Current device manuals and documents
- ONVIF authoritative model/firmware conformance database
