01 / Executive summary
A public business page and a permanent QR link.
Customers select what to share and how to hear from you.
Relevant campaigns, bookings and business interactions.
Loyalty and ongoing relationships with clear preferences.
ViaVib is being developed as a shared digital platform for business discovery, customer relationships and everyday commercial activity. Its purpose is to help businesses manage engagement through one connected environment while giving customers clear choices about the businesses they join and the communications they receive.
The long-term vision is borderless: when fully ready, ViaVib aims to serve businesses and customers across supported international markets through a common platform, with local configuration where necessary. International readiness is a delivery objective, not a statement that every service is available in every country today.
This paper sets out an illustrative £10 million cumulative platform revenue scenario for the first 24 months following full commercial launch. The launch date is not specified. The figures are planning assumptions rather than reported performance, contracted sales or a guaranteed forecast.
02 / The opportunity
Connected workflows around the business and the customer’s choices.
Conceptual comparison of fragmented workflows and the proposed ViaVib approach; not a measured efficiency claim.
Independent businesses often coordinate public profiles, customer updates, bookings, loyalty, social content and payments in separate tools. Repeated data entry and disconnected workflows can make a small team’s operation harder to manage. Customers face a corresponding problem: maintaining useful relationships without losing control of their contact preferences.
ViaVib’s proposed advantage is continuity across these workflows. A business’s public presence can lead to a consented relationship, an appropriate update, a booking or a repeat visit. This is a product thesis to validate through customer adoption and retention; this paper does not assert a measured market size or proven competitive superiority.
03 / Platform & experience
Roles · preferences · consent
Platform architecture overview. Modules and provider integrations remain subject to configuration, testing and approvals; this is not an availability guarantee.
The platform codebase includes business profiles and permanent links, QR-led joining, customer preferences, organisation and branch management, campaign tools, reservations and check-in, loyalty and rewards, reporting and administrative controls. Module availability depends on configuration, testing and operational readiness.
Messaging, email, social scheduling, advertising, creative assistance and payment-related workflows extend the platform through provider integrations. Implemented screens and integration code do not by themselves establish production approval. Social publishing and advertising remain subject to provider permissions, account eligibility and platform switches; availability must be verified before customers rely on them.
A typical business journey begins with account setup, organisation details and team permissions, followed by a public page and customer invitation link. Customers choose to join, select communication preferences and can disconnect. Authorised staff then manage enabled services from a business console, while the platform administrator controls service availability and operational oversight.
The intended customer outcome is a useful ongoing relationship with each participating business. The intended business outcome is less administrative friction and more measurable repeat engagement. Neither outcome is guaranteed; onboarding completion, repeat usage and customer feedback must establish whether the product delivers it.
04 / Architecture & trust
Join, choose channels, change preferences and disconnect.
Staff roles, server-side checks and protected integration credentials.
Audited operations, event verification and append-only ledgers.
Design principles and intended controls. Operational testing and security review are launch requirements.
ViaVib uses a web application backed by a relational database and server-side integrations. Organisation membership and role checks define business access. Sensitive operations such as campaign charging and administrative changes are designed to run through controlled database functions or server actions rather than relying only on visible interface controls.
The design separates provider credentials from customer-facing connection records and uses append-only ledgers for credit and funding movements. Advertising funds and platform revenue must remain distinct. Provider callbacks and payment events require verification and idempotency so repeated delivery does not create repeated charges or actions.
Consent, preference management, suppression and deletion workflows are central to the relationship model. Businesses should reach eligible audiences through authorised workflows without requiring unrestricted exports of raw customer contacts. Retention periods, processor records and incident procedures must be finalised and validated before broader launch.
Security remains an operating responsibility. Role enforcement, auditability, credential handling, recovery testing, monitoring and a reviewed authentication policy are launch requirements. This paper makes no claim of independent security certification, universal regulatory compliance or mandatory multi-factor authentication being active during development.
05 / Borderless by ambition, local in delivery
International expansion framework. The globe represents ambition, not a map of current coverage or committed market launches.
When fully ready, ViaVib intends to be borderless in reach: one product foundation that can support businesses operating beyond a single domestic market. Expansion will be market by market, with services enabled only where commercial, technical and legal readiness has been established.
Readiness requires translated and reviewed interfaces, appropriate time zones and date formats, accessible onboarding and support capacity. Payments require supported countries, currencies, settlement arrangements and eligible providers. Messaging requires local sender rules, consent processes, delivery coverage and provider permissions. Advertising and social features depend on each network’s approvals and policies.
Local privacy, consumer, tax and business obligations must be assessed before entry. International data flows, contractual responsibilities and customer support arrangements require review. A common platform does not remove national requirements or guarantee cross-border settlement, unrestricted transfers or access in every jurisdiction.
The expansion decision should therefore use a market-readiness checklist: customer demand, approved integrations, localisation quality, operating costs, support coverage and legal review. Only markets passing those checks should move from pilot to general availability.
06 / Commercial strategy
72% of the illustrative 24-month total. Built from average paying organisations × realised monthly subscription × 12 months.
28% of the illustrative total. ViaVib fees earned from platform activity, excluding client funds and pass-through expenditure.
Modelled revenue mix; not current trading results. Actual tariffs, recognition and delivery economics require validation.
The illustrative business model combines recurring organisation subscriptions with platform usage and service fees. Actual plans and transaction charges must be defined and tested against delivery costs. The £100 monthly subscription assumption below is a modelling input, not a published tariff or a claim about current customer spending.
Initial acquisition should focus on a limited set of business segments and repeatable use cases, supported by assisted onboarding and measurable activation. Expansion through referrals, local business networks and potential channel partners should follow evidence of retention. No partnership or distribution agreement is implied here.
Growth must be supported by customer success, reliable fulfilment and sufficient working capital. Before scaling acquisition, management should establish gross margins by module, support cost per organisation and customer acquisition payback. Customer funds and pass-through provider expenditure are not a substitute for platform revenue.
07 / The £10 million revenue scenario
Cumulative over the first 24 months of full commercial operation.
Year 2 assumes 5,000 average paying organisations, compared with 1,000 in Year 1. These are annual averages, not year-end account counts.
The target is £10 million in cumulative platform revenue across Year 1 and Year 2, measured from full commercial launch. It is not £10 million annual recurring revenue, profit, valuation or cash raised. The model uses average paying organisations throughout each year, rather than year-end account counts.
| Assumption / revenue | Year 1 | Year 2 | Two-year total |
|---|---|---|---|
| Average paying organisations | 1,000 | 5,000 | — |
| Monthly subscription per organisation | £100 | £100 | — |
| Subscription revenue (accounts × £100 × 12) | £1,200,000 | £6,000,000 | £7,200,000 |
| Usage & service revenue | £800,000 | £2,000,000 | £2,800,000 |
| Total platform revenue | £2,000,000 | £8,000,000 | £10,000,000 |
What must be true
Achieving these averages requires substantial acquisition and retention; 5,000 accounts at the end of Year 2 would not by itself meet the Year 2 assumption. The model assumes 12 billable months per average account at a realised £100 monthly subscription after any discounts. Usage and services imply approximately £66.67 per average paying organisation per month in Year 1 and £33.33 in Year 2, in addition to subscriptions. These volumes and spending levels are unvalidated and need pilot evidence.
Usage revenue means fees earned by ViaVib under a validated revenue-recognition policy. It excludes pass-through advertising budgets, customer payment principal, taxes and other client funds. Subscription and usage categories must not count the same charge twice. Refunds, credits, bad debt, contract terms and principal-versus-agent treatment require accounting review before the scenario becomes an operating forecast.
Sensitivity, costs & cash
- 50% of modelled revenue: £1m in Year 1 + £4m in Year 2 = £5m cumulative.
- Target scenario: £2m + £8m = £10m cumulative.
- 150% of modelled revenue: £3m + £12m = £15m cumulative.
These are simple revenue sensitivities, not probability estimates or independent forecasts. No cost budget has been supplied. Hosting, messaging delivery, payment processing, AI usage, engineering, sales, support, professional services, refunds and tax can materially reduce returns. Revenue does not equal cash collected or profit. A funded operating plan, cash-flow model and validated unit economics are prerequisites for pursuing this target.
08 / A readiness-led 24-month roadmap
These phases are proposed delivery goals, not commitments or claims of completed work. The revenue clock starts at commercial launch; pre-launch readiness comes first.
Before launch / Prove readiness
Complete end-to-end testing, provider permissions, security and privacy review, support procedures, pricing validation, reconciliation and recovery exercises. Pilot with consenting businesses and document defects and operating costs.
Months 1–6 / Establish repeatability
Concentrate on initial supported segments and markets. Measure onboarding completion, first useful action, retention, delivery reliability and paid conversion. Validate the subscription and usage assumptions against real cohorts.
Months 7–12 / Strengthen the operating model
Expand only where service quality and economics support it. Build repeatable support and acquisition processes; track progress toward the Year 1 revenue scenario using earned revenue rather than client funds.
Months 13–18 / Pilot international expansion
Select additional markets using demand, localisation, provider coverage and compliance readiness. Test local operations and support before broad availability. Maintain a clear public list of supported services and territories.
Months 19–24 / Scale demonstrated demand
Extend proven workflows and market coverage while reviewing infrastructure capacity, gross margin and cash needs. Reforecast the £8m Year 2 scenario against actual average paying accounts, retention and realised revenue.
09 / Risks, accountability & measurement
Adoption & retention
Risk: customers do not adopt or renew at assumed levels. Response: validate segments through paid cohorts and track activation, monthly churn, retention and realised revenue per organisation.
Provider dependencies
Risk: approvals, delivery rules or API changes restrict services. Response: maintain explicit service gates, review permissions, monitor delivery failures and publish accurate availability.
Economics & funding
Risk: acquisition and delivery costs exceed contribution. Response: track gross margin by module, acquisition cost, payback, refunds and cash runway; reforecast monthly.
Trust & international operations
Risk: security incidents, compliance gaps or support failures damage trust. Response: review access and audit logs, test recovery, assess each new market and measure resolution times and incident recurrence.
Management should review a monthly dashboard covering average paying organisations, recognised subscription and usage revenue, active businesses, cohort retention, delivery success, booking completion, support workload, gross margin and cash runway. Numerical operating thresholds should be approved after baseline pilot data is available, rather than invented for this paper.
This document should be revised when launch scope, supported markets, pricing or financial assumptions change. The £10m scenario is an ambition to test against evidence. For product and business enquiries, use the website’s Contact us page.