Wholesale: catalog, customers, orders, and price lists
Operate as wholesale customer or provider, publish services and networks, and manage orders, options, tickets, and billing.
Last updated: 2026-08-19
Two distinct roles
The provider publishes a catalog, enables customers, receives orders, and manages progress. The customer browses enabled offers, places orders, and follows tickets and states. Every query and action must respect both tenants and relationship role.
Dashboard and starting sequence
The dashboard changes perspective by role. Providers see received-order summaries, active or pending customers, and recent work; customers see their orders and related providers. Counters are navigation aids, not a substitute for filtered lists.
Configure identity, visibility, notifications, services, and price lists first; then approve one customer and simulate a complete order. This makes an empty KPI meaningful rather than a symptom of incomplete setup.
Provider identity and notifications
Configure provider name, payoff, color, logo, SMTP account, and order recipients. These values build the customer-facing wholesale experience and must match the commercial agreement.
General setup, step by step
Open Settings → Wholesale → General. Enter a recognizable trading name, short payoff, primary colour, and a logo that remains clear in documents; very wide images are optimized to a maximum width of 600 pixels. The Wholesale description should explain served networks, delivery model, prerequisites, and contacts without replacing contractual terms.
Select a working SMTP account and enable email, SMS, WhatsApp, and ISP App independently. Enabling a switch does not configure the underlying channel or create valid recipients. Finally select the department for automatic order tickets; with no department selected, that automatic ticket is not created.
Provider visibility and public catalog
Under Settings → Wholesale → Visibility, publish the provider only after catalog, contacts, and handling process are ready. All exposes it to eligible ISPs; Selected ISPs restricts discovery to the comma-separated ISP IDs entered. Review every ID before saving.
Public catalog is independent from provider visibility. Enable it only for offers and prices intended for unauthenticated consultation; otherwise keep the catalog inside the authorized customer relationship and verify it with an eligible customer account.
Status templates and channels
Message Templates provides one template per order status and supported channel. Email accepts formatted content, SMS and WhatsApp should remain concise, and ISP App uses a title and body. A template does not make an unconfigured channel operational.
Available tags include client name, customer/company name, service, order number, order details, previous status, new status, and email signature. Use only listed tags, save channels separately, and test the rendered message with fictitious data for length, signature, and sensitive content.
Publish a service
Set visibility, technologies, prices/cycles, and access networks: Any, proprietary, FiberCop, OpenFiber, Fastweb, OPNet, or Pianeta Fibra. Choosing Any normalizes the network rule but never bypasses technology compatibility.
Configure per-order-type fields as text, number, date, selection, checkbox, or protected PDF/JPG/PNG upload up to 10 MB. Use explanatory labels, require only necessary evidence, and test Activation, Migration, and Termination separately.
Relationship requests and customer states
A customer ISP finds a visible provider and submits a relationship request. The provider reviews it in customers/requests and can move it from Pending to Active or Rejected; an active relationship may be Disabled and later reactivated. Validated transitions remain in history with operator and date.
Activation may create the ticket selected in settings. Verify organization, requesting account, commercial agreement, and service scope before approval. Disabling access hides the usable catalog but does not erase existing orders or history.
Customers and access
Approve the relationship, associate CRM identity where required, and grant services or a shared price list. A relationship alone does not expose every offer. Without an assigned price list, historical per-customer access remains effective.
Customer detail, CRM, and service scope
The customer ISP detail combines Wholesale profile, relationship state, accounts, order summary, recent activity, and CRM link. Search for an existing CRM record before creating one, associate only the correct legal entity, and remove an incorrect link without deleting the Wholesale relationship.
Customer Services assigns a price list or manages individual offers. Toggling access changes only the provider-customer scope, not the provider’s global catalog. After every change, inspect the catalog from the customer side to confirm what is actually orderable.
Catalog and filters
The catalog displays only relationship-, visibility-, technology-, and network-compatible offers. Search, category, technology, network, and billing filters are derived from those visible offers. Do not bypass compatibility through a direct URL.
Create an order
Select service, order type, customer, installation address, and billing cycle. Provisioning-prefilled orders still let the operator choose Activation or Migration. Complete dynamic fields, protected files, compatible options, and provider notes before submission.
Options and billing
An option may support all primary services or a selected set and appears only when enabled for that customer. Primary and option services create separate billing instances with WH-#{order} reference and independent progress.
Provider handling and state
The provider reviews technical data, files, notes, and options, creates the in-progress billing instance, and communicates state. Rejection/cancellation applies before service creation. Internal state, customer-facing state, and message must remain coherent.
Order types and state meaning
Activation requests a new resource, Migration transfers an existing one, and Termination requests closure. Do not use one type as a shortcut for another because required fields, evidence, and commercial consequences differ.
Order states include Pending request, Processing, Completed, Executed, Rejected, and Terminated/Cancelled according to order type. Update them only after the real event, communicate a clear explanation, and confirm that billing services and option states agree.
Order tickets and history
Order tickets keep customer and provider communication inside the authorized order context. Open or continue the linked ticket rather than moving technical decisions to unrelated conversations.
Compare ticket chronology with order history, operator changes, attachments, status messages, and billing-service state. A ticket reply can explain progress but does not change the provider order state unless the supported workflow performs that action explicitly.
Provisioning and coverage
Coverage-driven provisioning proposes a wholesale provider only when the active relationship, access network, technology, customer eligibility, and published offer all match, and no conflicting active order already exists.
Review the installation address, coverage evidence, service, billing cycle, activation or migration type, required custom fields, and options before creating the order. A suggested provider is not proof of reservation, acceptance, or technical delivery.
Tickets, attachments, and automated communication
From an order, users can open a dedicated ticket, browse linked tickets, and continue the conversation. Subject, department, message, attachments, and recipients must stay within that order. Technical custom-field uploads and ticket attachments serve different purposes.
A status change or provider message may create or append to the order ticket and notify configured recipients. Review the status template, linked CRM contact, authorized accounts, and CC addresses before sending. Order history, ticket history, and billing-service state should tell the same story.
Checklist
- Configure provider identity and alerts
- Publish correct networks and technologies
- Configure order fields/files
- Approve customer relationship
- Assign price list or access
- Verify visible catalog
- Review service, address, and cycle
- Select compatible options
- Create primary and option instances
- Update state and message
- Use order tickets