Trust and transparency
ISPbills editorial standards
How we research, write, review and update technical guides, product claims, customer evidence and software comparisons.
Useful evidence before search volume
We publish when the material helps an ISP evaluate, configure or operate a real workflow—not simply to create another page for a keyword.
Technical guides
Guides should identify prerequisites, supported scope, operational risks, verification steps and the current documentation path.
Product statements
Capability claims must reflect the current product. Device, firmware, provider and country-dependent behavior is qualified where relevant.
Comparisons
Comparisons are vendor-authored. We link official public sources, show the review date, distinguish unknowns and recommend direct validation.
Customer evidence
Named facts are attributed to the customer or an available record. We do not publish modeled performance gains as measured customer outcomes.
AI assistance
Automation may assist research, drafting and publication. The editorial workflow supports human approval or publisher-authorized automatic publication after source and content validation. Automated checks are not a claim of human technical review or hardware testing.
Corrections
Material changes should update the visible content and modification date. Readers can report an error through the contact or support channel.
A repeatable check before publication.
Each substantial guide is checked for a clear audience and search intent, original operational value, readable structure, relevant internal links, crawlable references and consistency with current product documentation.
Comparison pages receive an additional source review. Customer pages receive an evidence-boundary review so product imagery, customer-supplied facts and measured outcomes are not confused.
Make technical advice reproducible
Use this checklist for new and substantially revised implementation guides. It is a publishing standard, not a claim that every archived article or device has been tested.
Problem and architecture
State the audience, failure or operating goal, system boundaries and prerequisites. Include an architecture diagram when it clarifies the data or control path.
Versions and evidence
Identify relevant software, model and firmware versions. Distinguish documentation-based instructions from lab or customer verification. Publish a tested version and date only when a test record exists.
Configuration and explanation
Show ordered steps, explain commands and expected outputs, and use relevant screenshots with safe example data. Never publish credentials or customer identifiers.
Safety and recovery
Describe access permissions, production risks, common failures and troubleshooting. Include success checks, rollback steps and the conditions that require operator approval.
Sources and next steps
Link current vendor references, product documentation and the relevant topic hub. Keep buying advice separate from configuration instructions; refresh an existing guide before creating a competing URL.
Accountable attribution
Use the actual author identity. Add professional credentials, a technical reviewer or a last-tested date only with supporting records and consent. An updated publication date does not establish a new technical test.
Show how an outcome was measured
A before-and-after claim needs the metric definition, baseline and comparison periods, sample size, measurement source, relevant operating changes and customer approval. Label estimates separately and explain missing data or limitations.
Customer quotes, screenshots and architecture details require permission. We do not invent savings, uptime, migration results, reviews or endorsements. A deployment size alone does not prove a performance improvement.
See something that needs updating?
Send the page URL, disputed statement and supporting source. The team will review the correction against current product and public evidence.