Public website, module catalog, and sales ISPINO

Purpose of the public website

The public website presents ISP Billing to visitors and prospective customers. It explains outcomes, functional areas, and modules without exposing administration tools, internal routes, database tables, scheduled commands, credentials, or tenant operations.

Public content must answer what the product can do and which ISP problem it solves. Detailed operating procedures belong in the manual and can be linked when appropriate.

Information pages and ISP APP identity

The Home page takes visitors from the overall value proposition through operating flows, the Dashboard, functional areas, customer experience, integrations, and offers. Desktop captures retain a landscape presentation, while the six native ISP APP captures use one consistent iPhone 15 Pro frame without changing the original application interface.

The ISP APP page retains the official logo and explains how the same application serves customers, ISP staff, and resellers according to role. FAQ, Contact, Privacy, Compliance, and Social share the public visual system. Privacy preserves the complete official legal text and adds a navigable index; Compliance separates standards, process, and controls; Social explains the purpose and destination of each official channel. Every page exposes its language and active navigation state.

The System in action page

The System in action replaces the former Screenshot gallery and presents the product through seven operating journeys: Dashboard, CRM and services, administration, support and communications, network and provisioning, customer experience, and integrations. It is neither a second module catalog nor a replacement for operating instructions.

Its fifteen images come from the official manual, use demonstration data, and can be opened at full size. Each area summarizes the outcome, identifies principal capabilities, and links to the relevant article. The page provides Italian and English versions, canonical and hreflang metadata, social metadata, and structured data; when a manual screen is replaced, its use in this showcase must also be reviewed.

Module catalog

The catalog is generated from modules explicitly marked for public exposure and hides internal-only packages. It separates included and paid modules and uses official names, prices, plan rules, and images rather than a manually duplicated list.

A module active for one tenant is not automatically available under every plan. Public pricing and commercial conditions remain authoritative and must be updated together with the product configuration.

Module information page

Each public module page needs a verified title, human description, real benefits, principal capabilities, relevant prerequisites, and an official responsive image. Explain the business result without promising behavior that is planned, inactive, or dependent on an unconfigured provider.

Use consistent terminology with the bilingual manual so visitors, search engines, and ISPINO can connect the commercial description with the operational guide.

Correct commercial writing

Write in plain language and start from the operator’s need. Distinguish a built-in capability from an optional integration, and distinguish module activation from external-account setup and technical provisioning.

Avoid internal IDs, permission errors, test-account limitations, implementation jargon, unverifiable superlatives, and artificial filler. Mention security or compliance support accurately without presenting the software as automatic certification.

ISPINO for visitors

The public ISPINO widget answers product questions from publishable knowledge and never receives tenant data, customer records, billing information, or administrator permissions. It should explain module differences, prerequisites, and supported workflows.

The invitation appears after approximately 3.5 seconds, remains for 11 seconds, repeats at most three times in a session with at least two minutes between invitations, and stops after the visitor opens the assistant.

From answer to sale

When a question depends on customer volume, external providers, migration complexity, contractual terms, or custom integration, ISPINO should state the dependency and direct the visitor to a trial or commercial contact.

The handoff must preserve the visitor’s intent without inventing prices, availability, delivery dates, or compatibility. Product claims should be traceable to the public catalog or manual.

Public manual indexing

Every Italian and English manual page publishes a title, description, canonical address, alternate-language address, and structured data. The sitemap is generated directly from the current articles: newly documented features enter the search-engine inventory automatically, while excluded modules remain omitted.

After deployment, verify that robots.txt and the sitemap are reachable on the final domain, then submit the sitemap through Google Search Console. A missing or unpublished URL cannot be indexed; canonical metadata and internal links must always use the actual public path.

Updates and quality control

When a module changes, review its catalog card, information page, screenshots, Italian and English manual, related comparison pages, structured metadata, and ISPINO knowledge source. Remove stale links and images.

Test category, included/paid state, price, selected navigation, image crop, accessibility text, language switch, canonical links, and layout on desktop and mobile. Search for the old name after every rename.

Checklist

• Expose only intentionally public modules
• Separate included and paid offers
• Use official names, prices, and images
• Maintain one authoritative page per module
• State real benefits and prerequisites
• Distinguish activation from configuration
• Keep internal details and secrets private
• Keep public ISPINO outside tenant data
• Limit invitation frequency per session
• Hand custom cases to trial or contact
• Align website, manual, metadata, and knowledge
• Test both languages and responsive layout