PROOF OF CONCEPT · FOR W DENIS REVIEW ONLY

Confidential demonstration environment. Fictional broker branding and synthetic data. Not for commercial use.

System walkthrough

How WRK works

The whole loop as a 14-chapter reference walkthrough — a deeper reference alongside the short guided presentation — from how a business first finds the broker to how the revenue is attributed back to the activity that created it. Captions are the narration, so this is fully understandable with sound off. Everything shown is synthetic demonstration data.

Reviewer material · inside Broker ViewSynthetic data
1 · DemandChapter 1 of 14

How prospects arrive

Commercial buyers reach a broker in several ways: organic search, paid search, LinkedIn, referrals, direct campaigns, and proactive broker outreach. WRK routes each of them into a sector-specific journey, so the enquiry is already shaped by the world the business actually operates in. Everything shown here is synthetic demonstration data.

What to watch

  • Sector language rather than generic 'business insurance' copy
  • Every journey ends in a structured review, not a quote form
  • Source and campaign are captured from the first click

Voice narration not configured. Add the ElevenLabs secrets server-side to enable it — captions and transcript work without it.

Chapters

WRK Guide presenter

Real-person presenter not configured

Presenter: Ready Preparing WRK Guide…

Checking presenter provider status…

Ask WRK about this demo

Type or speak a question — grounded in this demo only.

Demo knowledge assistant

Speech input not available on this browser — type your question instead.

Questions and answers may be recorded with date/time for proof-of-concept feedback and implementation planning. Please do not enter customer, policy or other personal data.

No regulated advice, suitability recommendation, FCA approval or compliance certification is given or implied. All pricing is indicative and must be verified before procurement. Voice narration not configured. Add the ElevenLabs secrets server-side to enable it — captions and transcript work without it.

Demonstration loop

Ask a question, see it recorded, triage it

This is the review loop itself, running live in the demo. Nothing here changes product code automatically — every implementation decision needs a human approval.

1

Ask WRK

Ask a representative question in the panel below.

2

Grounded answer

Answered only from the curated corpus, labelled by claim type.

3

Recorded

“Recorded for review feedback” confirms persistence.

4

Classified

Category, feedback type and follow-up flag set locally.

5

Triaged

Reviewed, needs answer, or added to the implementation backlog.

Ask WRK about this demo

Ask anything about this demonstration or the proposed production system — capabilities, prospecting, acquisition, data sources, costs, workflow, integration, security, hosting, UK data protection and compliance considerations, deployment, limitations, ROI and attribution. Answers come only from the curated WRK Insurance demo knowledge module in this project. If a question falls outside it, the assistant says what would need to be confirmed instead of guessing.

Demo knowledge assistant

Speech input not available on this browser — type your question instead.

Questions and answers may be recorded with date/time for proof-of-concept feedback and implementation planning. Please do not enter customer, policy or other personal data.

Finding prospects

Data & costs

Prospect journey

Broker workflow

Compliance

Security & deployment

ROI & attribution

WRK platform & value

Technology & integration

Commercials & delivery

Support & roadmap

No regulated advice, suitability recommendation, FCA approval or compliance certification is given or implied. All pricing is indicative and must be verified before procurement. Voice narration not configured. Add the ElevenLabs secrets server-side to enable it — captions and transcript work without it.

Full transcript

The complete narration script for all 14 chapters, identical to the captions above.

Technology & enablement

What runs this proof of concept

The enabling layers actually used in this demo, each shown with its role today and the production approach where the architecture is deliberately provider-agnostic.

WRK application & UI layer

Role in this POC — The demo itself — prospect journeys, broker workspace, walkthrough, Ask WRK and the guide experience, all built as reusable, data-driven modules.

Production approach — The WRK layer is the product. Everything below it is an enabling service and can be swapped without changing the experience.

Lovable build & hosting workflow

Role in this POC — Used to build, preview and iterate this proof of concept rapidly as a hosted web application.

Production approach — A production deployment path would be agreed through IT architecture and procurement review.

Cloud database (PostgreSQL)

Role in this POC — Persists reviewer questions and feedback for the demonstration loop. No customer or policy data is stored.

Production approach — A hardened, tenant-isolated managed database with agreed residency, encryption, audit and retention controls.

ElevenLabs voice synthesis

Role in this POC — Gives WRK Guide its natural spoken voice for narration and conversation.

Production approach — Provider-agnostic by design — the voice layer sits behind an adapter and can be replaced or self-hosted.

LiveAvatar presenter layer

Role in this POC — Supplies the visual presenter you see on screen. WRK keeps the reasoning, script and voice; the provider supplies the face only.

Production approach — Interchangeable presenter adapter — an alternative avatar provider or none at all changes nothing else.

LiveKit / WebRTC media transport

Role in this POC — Carries the presenter's live audio and video stream to the browser in real time.

Production approach — Standard real-time media transport; a production choice would be validated for scale, regions and security.

Browser Web Speech API

Role in this POC — Provides the opt-in, push-to-talk and continuous-conversation voice input where the browser supports it. Typed questions always work as a fallback.

Production approach — Browser-native capability; no third-party speech service is used for input in this demo.

Local synthetic assets

Role in this POC — The office backdrop and all imagery are local, synthetic project assets — no live data feeds or external content.

Production approach — Production environments would use approved brand and content libraries under the same compliance workflow.

Technology choices shown here support the proof of concept. A production implementation would be confirmed through security, compliance, residency, procurement and IT architecture review.

Compatibility & readiness

Integration Compatibility & Readiness

WRK is designed to sit alongside existing broker, CRM, lead-generation and telephony systems. Compatibility depends on the interface the current platform exposes — API, webhook/event feed, supported connector, or structured export/import.

Platforms are named as common market examples and integration candidates only. Nothing here states which systems any brokerage uses, and publicly documented vendor capability is not the same as a WRK integration being built or certified. No system is connected in this proof of concept.

Broker management / CRM

WRK is designed as the demand and pre-bind layer, so the broker management system stays the system of record. These are common market examples, not a statement of what any brokerage uses.

Acturis

Strong integration candidate · vendor/API confirmation required

Acturis publicly describes its platform as API-enabled and able to exchange data with internal and external systems. No WRK connector exists today; interface availability for the specific product and version would need vendor confirmation.

Open GI

Integration candidate · vendor interface confirmation required

Open GI has a broad partner and integration ecosystem. The exact interface available for a given product and version must be confirmed with the vendor before any scoping.

Salesforce

Standard API integration pattern

Well-documented REST API and event capability; the practical work is field mapping, permissions and ownership rules.

HubSpot

Standard CRM API integration pattern

Documented CRM API with webhook support on eligible tiers; source and campaign fields usually carry through cleanly.

Microsoft Dynamics 365

Standard Dataverse/Web API integration pattern

Dataverse/Web API with tenant-controlled authentication; permissions and environment strategy are the main scoping questions.

Other CRM / BMS

Assess per system

Assess via API, webhook, supported connector, CSV/SFTP or a controlled manual handoff — in that order of preference.

No broker management system or CRM is connected in this proof of concept.

Lead generation / data / marketing

Sources that carry demand, provenance and enrichment into the workflow. Lawful basis and vendor terms govern what may actually be used.

Website forms / landing pages / paid-media attribution

Straightforward where webhooks/forms/UTM/source fields are available

Source, campaign and UTM capture at the point of enquiry is what makes attribution defensible later.

Companies House / public corporate data

Useful for company verification and enrichment

Subject to lawful-use rules and the published terms of the source. Corporate data is not the same as personal data.

Licensed business-data providers (Cognism, Apollo, ZoomInfo, FullCircl)

Possible where the customer's licence includes API/export rights

Vendor terms, licence scope and lawful basis must be checked before any use. Named here as common market examples only; none is connected here and no partnership is claimed.

Salesforce / HubSpot marketing sources

Can carry source, campaign and lead data through their APIs where enabled

Useful where marketing already lives there and attribution needs a single source of truth.

CSV / SFTP imports

Fallback for systems without suitable APIs

Scheduled structured files still connect the workflow end to end, with clear expectations about latency.

No live data feed, provider licence or scraping is present in this proof of concept.

Telephony / VoIP / UC for Caller Intelligence

Caller Intelligence needs one thing from telephony: an inbound-call event carrying a caller identifier, before or at answer time.

3CX

Strong caller-lookup integration pattern

3CX documents CRM integrations built on REST APIs with caller-number and contact lookup. That is a documented platform capability — a WRK connector is not built or certified today.

RingCentral

Strong event/webhook integration pattern

RingCentral exposes event notifications and webhooks, including call events. Again, publicly documented capability rather than an existing WRK integration.

8x8

Event/webhook capable on supported products

Exact call-event entitlement, product tier and version would need to be confirmed before scoping.

Microsoft Teams Phone

Candidate via approved Microsoft/telephony event and Graph/contact architecture

Confirm exact event availability and tenant permissions before scoping; this is an architecture question, not a switch.

Other hosted PBX / SIP / UC

Suitable if it can emit an inbound-call event

Requirement is a webhook or API payload containing a caller identifier at or before answer time. Where that does not exist, Caller Intelligence would run as manual lookup instead.

Caller Intelligence in this demo is a simulation you trigger yourself. No telephony provider is connected and no compatibility is guaranteed.

How easy is it to integrate?

Green — straightforward

Documented REST/GraphQL API and/or a signed webhook/event feed, OAuth2 or service-account authentication, stable record identifiers, and a sandbox or test environment available.

Amber — workable

An API exists but events are limited, exports are batch-only, vendor approval or an additional licence is required, or field mapping is complex enough to need a scoping workshop.

Manual fallback

No usable API. A structured CSV/SFTP export/import or a controlled handoff can still connect the workflow, without pretending it is real time.

What WRK needs from an existing system

  1. 1Vendor, product and versionWhich platform, which edition, and whether API, webhook or export access is actually enabled on the licence.
  2. 2Sandbox or test tenantTest credentials supplied through secure project secrets — never pasted into a demo or application UI.
  3. 3Authentication methodOAuth2, service account, API key or SSO as applicable, with the owning administrator identified.
  4. 4Stable identifiers and data ownershipDurable record IDs plus agreed source-of-truth rules so nothing is overwritten by the wrong system.
  5. 5Field and event mappingOrganisation, contact, telephone, opportunity, renewal, activity and campaign/source fields mapped explicitly.
  6. 6Telephony specificsInbound caller identifier (normalised E.164 preferred), call event type/status, user or extension, call/session ID, and a signed or authenticated webhook where supported.
  7. 7Permissions, lawful basis and retentionWhere personal data is involved: lawful basis, retention, DPA, subprocessor and residency review before connection.
  8. 8Operational termsRate limits, support ownership, change control, and agreed failure/retry behaviour.

Demo only · no data sent

Integration discovery checklist

A local, illustrative checklist for a scoping conversation. Nothing is submitted, stored or sent anywhere — the result is calculated in this browser from the answers selected.

Optional modules

Add-ons, without cluttering the core workspace

Everything above is the core demonstration. Add-ons are optional modules a brokerage can switch on separately — they are not core functionality and are not live integrations in this proof of concept.

First sample add-on — WRK Caller Intelligence

When an inbound call is recognised, WRK can surface the relevant organisation, contact, opportunity, renewal and recent activity before the broker answers.

Optional WRK Voice + WRK Intelligence add-on — caller recognition can pre-load context before answer, reducing search time and improving call handling.

Demo today vs production design

In this proof of concept the incoming call is a scenario you trigger yourself, drawn from synthetic records. No telephony provider is connected or claimed as compatible.

In production this could be triggered by an authorised telephony event/webhook and matched against the broker/customer record before presenting context to the user.

Demonstration dataSynthetic data only

This is a concept demonstration built by JDNetworks for the WRK ecosystem. All organisations, figures, scores and performance metrics shown are synthetic and illustrative. Nothing here constitutes insurance advice, a recommendation, a statement of policy suitability or confirmation that any cover exists. A qualified, appropriately authorised broker should assess actual insurance needs.