Frequently asked questions

bmetric identifies visitors with buying intent in real time and routes them to the right contact option, a callback, a call, or a form, before the moment passes. It reads session behaviour, CRM/CDP data, and marketing campaign origin, then decides which contact experience each visitor should see instead of showing everyone the same default. Sales-ready visitors reach your sales queue. Self-serving visitors are left to complete on their own.

The decisions are made by the Contact Orchestrator, the decision layer behind every bmetric solution.

You could build parts of it, and sophisticated teams sometimes do. What is hard to build, and harder to maintain, is the full loop. bmetric is that loop in a box: deciding who should become a lead, gathering the lead, deciding who should receive the lead, sending the lead with full context, capturing what the outcome of the lead was, and feeding that outcome back into deciding who should become a lead next. Because the loop is closed, the system runs an automated cycle of learning and optimisation, always gathering the best lead, not just the most leads.

Building that internally means years of integration work across website, telephony, CRM, and ad platforms, and it is not on anyone's roadmap because it is nobody's core product. Every quarter without it, sales-ready visitors leave unconverted and the learning never compounds. bmetric is that project, finished.

bmetric connects and communicates with your CDP, it does not replace it. Your CDP holds segments, scores, and customer knowledge, but that data often sits unused at the moment it matters most: while the visitor is on the website. bmetric activates it, reading CDP segments and scores as decision inputs and writing outcomes back, so the full feedback loop collaborates with the CDP rather than running beside it. The data in your CDP stops being isolated and starts generating revenue on the site.

The same applies to an in-house scoring algorithm: its output becomes one more signal the Contact Orchestrator reads at runtime.

Not if suppression is treated as seriously as engagement, which is how bmetric is built. Visitors mid-checkout get a do-not-interrupt instruction, recognised customers completing self-service are protected, and prompts are shown only where signals indicate the visitor will not convert alone. Whether a prompt helps or hurts in a given placement is not assumed, it is A/B tested against contact rate, lead quality, and conversion to sale.

Directly into the workflow you already run. Callback requests are routed to your dialer or contact centre with full session context, so the agent knows what the visitor was looking at before dialling. Form leads flow to your CRM with campaign and session attribution attached. No parallel inbox, no manual export.

A single JavaScript snippet deployed through your tag manager, plus access to the systems the leads should flow into. No core website changes and no engineering project on your side. The script is live in a day; the full loop, decision rules, integrations, and contact designs tuned to your funnel, is typically production-ready within weeks. Configuration happens in the bmetric platform, with bmetric's team doing the heavy lifting during onboarding.

bmetric operates as data processor under a standard DPA, with your organisation as controller, and the script runs within your consent management platform's rules. When a visitor declines tracking, lead capture does not stop: bmetric translates the setup into a privacy-compliant contact option strategy. Contact options are still shown and leads are still gathered, but without session-level tracking and without personalisation. Consent governs how well the experience is tailored, not whether a sales-ready visitor can reach you.

Consumer-facing enterprises in telco, insurance, energy, and pensions, including Telenor, YouSee, Norlys, Tryg, and Vattenfall. YouSee's operations team credits bmetric with maintaining best-possible response times to potential customers and qualifying sales conversations. Clients see lifts in qualified leads from the same traffic, because the system captures visitors who were already sales-ready but would never have reached the team.

bmetric keeps pricing easy and straightforward. The current pricing, and what drives it, is available on the pricing page.

Because the call happens outside their view. Your website analytics, and platforms like Google Ads and Meta, see clicks, sessions, and online conversions. When the visitor picks up the phone instead of submitting a form, the session ends without a conversion as far as those platforms are concerned. bmetric closes that gap by matching every inbound call to the session that preceded it and forwarding the attribution, campaign, keyword, pages read, back to your ad platforms and analytics as the conversion signal each one expects.

The mechanism is Call-Tracking.

It gives them eyes and ears, so spend follows actual revenue instead of unprofitable traffic. Smart Bidding and Meta Advantage+ allocate budget based on the signals they receive, and if calls are not in the signal set, campaigns that drive calls get systematically undervalued while campaigns driving cheap online clicks get scaled. Feeding call conversions back removes that active budget bias.

No. Call-tracking is the only technology that can fully connect first-time sessions and visitors without a login to a given call. CRM matching only works for known customers who identify themselves. Login-based matching only works for users with accounts who are signed in. Post-call surveys rely on the caller's memory. For the anonymous majority of your paid traffic, dynamic call-tracking is the only way to give bidding algorithms visibility into which campaign drove the call.

The channel and campaign that drove the visitor, the keyword where applicable, the pages they visited before calling, time and duration, repeat-caller status, and, if you categorise calls, the outcome, such as new customer, service, or no sale. All of it lands in your analytics, ad platforms, and CRM, in one dataset alongside your online conversions.

Call-tracking is tracking, so it runs only with consent: declined visitors are not tracked and their calls are not individually attributed. The contact itself is not lost, for these visitors bmetric switches to a privacy-compliant contact option strategy, so leads are still captured, just without session-level attribution. Your attribution is built on consented traffic, within consent limits, not around them.

No. bmetric is the missing data source, not a rival dashboard. Attribution data is forwarded to the platforms where your team already works: Google Analytics, Adobe, Piwik PRO, Google Ads, Meta, and your CRM. Your existing attribution model simply starts operating on the complete picture instead of half of it.

Two buckets. Reallocation value: budget currently flowing to campaigns that look good on online conversions but drive few calls gets shifted to campaigns that drive high-value calls. Bidding optimisation value: the algorithms themselves improve once they optimise on full conversion data, which is where clients see lifts in ROAS. A split-test or proof-of-concept period makes both measurable on your own traffic before any long-term commitment.

bmetric processes session data, and for calls the phone number, which is personal data, as data processor under a standard DPA meeting Article 28 requirements. Tracking activates only with cookie consent through your CMP, personally identifiable data is retained for 60 days by default and then deleted automatically, and numbers are not linked to a name or profile unless you choose to enrich them via your own CRM.

bmetric keeps pricing easy and straightforward. The current pricing, and what drives it, is available on the pricing page.

By reading the signals already present in the session: which pages the visitor is on (billing versus pricing), whether your CRM or CDP recognises them as an existing customer, their behaviour in the session, and where they arrived from. A recognised customer searching "why is my bill high" in the help centre is a service query. A net-new visitor from a paid search keyword comparing plans is a sales opportunity. Each gets the contact option that fits.

Deflection done right improves it, because the goal is not to hide your phone number, it is to get each visitor to the right resolution faster. Service visitors reach service, self-serve, a chatbot, or the service line, instead of queueing for a sales agent who cannot help them. Sales visitors reach sales instead of a busy service queue. Both sides wait less and resolve faster, and your agents stop answering password resets on the sales line.

No, it sits one step earlier. Your IVR sorts callers after they have dialled, and your chatbot helps once the visitor has opened it. bmetric works on the website, before the contact happens, deciding which channel the visitor should be offered in the first place. The wrong-queue call your IVR has to redirect is a call bmetric prevents. Your existing IVR and chatbot become destinations the decision layer routes into, not competitors to it.

The decision layer knows your queue states and opening hours and adapts. When the service line is closed, a billing query is routed to self-service or the chatbot instead of a dead phone number. When capacity is stretched, contact offers can shift to scheduled callbacks. Opening hours and capacity are decision inputs, not afterthoughts.

Every routing decision and outcome is logged: deflections recorded, wrong-queue calls before and after, and the effect on both service resolution and sales capacity. Because the same platform attributes sales contacts, you also see the flip side, whether protecting the sales queue lifted qualified leads. Where the honest answer is uncertain, for example whether a mid-journey prompt deflects or annoys, it is A/B tested rather than assumed.

No. bmetric decides and routes on the website side, your telephony, PBX, and agent workflows stay as they are. Contact options rendered on the site point into the queues and channels you already run, and integrations connect to platforms like Genesys, Puzzel, and Zendesk rather than replacing them.

A better static contact page still shows every visitor the same thing. The problem is not the page design, it is that a high-intent buyer and a customer with an invoice question see identical options, and no static page can tell them apart. Deflection requires a runtime decision per visitor, reading CRM status, behaviour, and queue state, plus a feedback loop that learns which routing actually resolved the contact. That decision layer, not the page, is what you would be building, and it is years of integration work that is not on any internal roadmap.

bmetric keeps pricing easy and straightforward. The current pricing, and what drives it, is available on the pricing page.

It makes sure no conversation ends without a record or a follow-up. Calls are transcribed, categorised by intent and outcome, for example upgrade request, quote, service, no sale, and the structured result is routed to the systems that need it: your CRM gets the log, your marketing platforms get the conversion signal, and follow-up actions are triggered automatically. A four-minute call becomes a structured, actionable data point instead of a note an agent may or may not have written.

The technology behind it is Voice Contact Automation.

No. Voice Contact Automation works on real conversations between your customers and your agents. It listens, structures, and routes, it does not replace the human on the line. If you run bots or self-service channels, they sit alongside it as routing destinations, not as part of this product.

It closes loops that are otherwise open. The call outcome flows to your CRM as a structured record, to Google Ads and Meta as a conversion signal with actual value attached, sale versus no sale, and back into the Contact Orchestrator's decision model so the next visitor decision is sharper. Combined with Call-Tracking, this completes the chain from campaign click to call to what the call was worth.

Call recording and transcription are regulated and the rules differ by country, which is why this is configured per deployment with your legal and privacy teams. Recording can happen through bmetric's routing layer or through your own telephony with bmetric processing the audio, whichever fits your setup. bmetric operates as data processor under your instruction and DPA, and caller notification is set up to meet the requirements in each of your markets, handled by bmetric or through your own telephony, whichever fits.

All EU languages. Whether your calls are in Danish, Swedish, Norwegian, Dutch, German, or any other EU language, transcription and categorisation cover them, with one setup across every market you operate in.

Yes. Categories are defined with you during onboarding and refined against real call data in the first weeks, so classifications reflect how your business actually talks about outcomes. Every record is auditable, you can see the transcription and classification behind any outcome, and the category model stays under your control as your business changes.

Transcription is the easy 20%. Off-the-shelf speech-to-text gives you text, it does not give you outcomes wired into your revenue loop. The value is in what surrounds it: category models tuned to your business, outcome delivery formatted for each destination, CRM, Smart Bidding, analytics, and the feedback into website decisioning and attribution. Building that pipeline internally means owning telephony integrations, ad platform APIs, and model maintenance indefinitely, for a system that is not your core product. bmetric ships it as a working loop.

bmetric keeps pricing easy and straightforward. The current pricing, and what drives it, is available on the pricing page.

When a visitor lands on your site, the script replaces the phone numbers on the page with a unique tracking number tied to that visitor's session. The visitor dials it, the call is forwarded to your real number, and your call centre receives it exactly as normal, no PBX changes, no agent retraining, no difference for the caller. Behind the scenes, the call is matched to the session, so the campaign, keyword, and pages that led to it are recorded and forwarded to your ad platforms, analytics, and CRM within seconds.

Because each of those sees only its own half. GA4 sees the session but loses the visitor the moment they dial. Your call centre reporting sees the call, volume, duration, queue, but has no idea which campaign created it. Your CRM sees the customer once an agent logs them, with the marketing origin already gone. Call-Tracking is the join between the halves: it is the only technology that can fully connect a first-time visitor, with no login and no prior identity, to a given call. That connection is what gives your bidding algorithms eyes and ears on call conversions.

No, they operate on different layers and typically become integrations rather than overlaps. Conversation analytics tools like Capturi analyse what was said on the call; Call-Tracking establishes where the call came from, they complement each other. Salesforce native telephony handles the agent-side workflow of the call; Call-Tracking supplies the marketing attribution Salesforce cannot see. Form tracking covers forms; calls remain invisible to it by definition.

No. It is a single JavaScript snippet, deployed via Google Tag Manager, Tealium, Adobe Launch, or directly, loaded asynchronously and page-speed safe. The number replacement activates once the page has loaded, so nothing blocks rendering. Single page applications are supported through a virtual pageview signal. We recommend loading bmetric after your analytics scripts and before third-party advertising tags.

Two legal bases apply. The script's session tracking requires the visitor's cookie consent, delivered through your consent management platform, bmetric documents the cookie category and your CMP loads the script conditionally. The data processing itself happens on your instruction, with bmetric as data processor and your organisation as controller, under a standard DPA that meets Article 28 requirements. Phone number and IP address are personal data and are handled accordingly, numbers are not linked to a name or profile unless you enrich them via your own systems.

Call-Tracking is tracking, so it operates only when consent is given. For visitors who decline, no session tracking runs. Lead capture can continue for those visitors through bmetric's privacy-compliant contact option strategy, just without session-level attribution.

Per call: the tracking number dialled, the session and campaign context, time and duration, and outcome if categorised. Personally identifiable data is retained for 60 days by default and then deleted automatically, with session-level attribution data retained per your instruction as controller.

No. Your published numbers stay yours, the swap happens dynamically in the browser, only for tracked sessions, and only for the numbers you whitelist for forwarding. Offline placements, print, directories, keep working unchanged, and static tracking numbers can be added for offline channels if you want those attributed too.

An ongoing connection, not a one-off configuration. Included means bmetric sets up, configures, and operates the integration so data flows automatically: conversion events to Google Ads and Meta, call events to GA4, Adobe, or Piwik PRO, and records to your CRM. bmetric can also retrieve the outcome of sales and forward outcome events to the same platforms, so the loop closes on what each call was actually worth.

It reads session behaviour, CRM/CDP data, and marketing campaign origin in real time. Concretely: page, device, scroll depth, and exit intent from the session; lead status and segments from your CRM and CDP; campaign UTM from your marketing stack; and operational context such as queue capacity and opening hours. Every signal lands in one place and is evaluated at runtime, per visitor, per moment.

It evaluates the signals against your decision rules and emits one decision per visitor, and every decision is logged with the full set of inputs that produced it. You can replay any visitor's journey and answer "why did this visitor see a checkout rescue prompt instead of a callback offer" by reading the input log, the rule, and the priority rank. It reads like a decision tree, not a black box, which matters when you need to explain behaviour to legal, brand, or the board.

Different layer, different job. Personalisation tools change content, headlines, banners, recommendations. A CDP stores and segments customer data. The Contact Orchestrator decides contact: which contact option each visitor sees, in which format, at which moment, and where the resulting contact routes. It reads your CDP as an input and activates that data on the website, and it hands its decision to the Contact Builder for rendering. It replaces neither system, it is the decision layer between them.

Your team together with bmetric, and no developer is required. Rules live in the platform, not in your website code, so anyone on the team can read what is happening, propose an adjustment, and see the impact within hours. Variants can be split-tested directly in the platform before rolling out.

A single script via your tag manager gets session signals flowing immediately, which is enough for behaviour-based decisions. CRM, CDP, and ad platform connections are added to enrich decisions and write outcomes back, Salesforce, HubSpot, Genesys, Puzzel, Google Ads, Meta, GA4, Adobe, Piwik PRO, and more. Each connection you add makes decisions sharper, none of them is a prerequisite for going live.

Your website is unaffected. The script loads asynchronously and the site never waits on a decision: if no decision is emitted, visitors simply see your default experience, exactly what they would see without bmetric. Contact prompts fail silent, not broken.

Session and decision data are processed with bmetric as data processor under a standard DPA, and the script activates through your consent management platform. Consent changes the depth of the decision, not the existence of a contact strategy. With consent, decisions draw on session-level tracking and personalisation. Without it, the Contact Orchestrator translates the setup into a privacy-compliant contact option strategy: contact options are still delivered and leads still gathered, but no session-level tracking and no personalisation runs.

The Contact Orchestrator is the brain, the Contact Builder is the delivery layer it calls from. The Orchestrator decides which contact experience a visitor should get; the Builder holds the content units, callback offers, forms, phone prompts, chat handoffs, and renders the matching one. Decision logic on one side, reusable content on the other, so the same decision can render different content per locale, brand, or test variant.

Callback requests routed to your dialer with session context, call-in prompts, lead capture and service forms, chat and bot handoffs, and content units such as retention or self-service nudges. Every unit it generates is attributed: callbacks, call-ins, and chat handoffs are all traced back to their campaign and session origin automatically.

No. Contact flows are built and managed in the platform without an engineering dependency: no release windows, no website deployments, no waiting on the roadmap. Marketing or CX teams create a unit, the Orchestrator decides when it shows, and changes go live in hours rather than sprints.

Yes. bmetric's team builds the styled units to your design guide during onboarding, and the point of decoupling content from decision logic is precisely that brand variants are manageable: one decision, different rendering per brand or market. Your core website code and design system are not modified, units render on top of the page.

With full context attached. A callback request lands in your dialer or contact centre with the visitor's session context, so the agent knows what they were looking at. Form leads flow to your CRM with campaign and session attribution. Chat handoffs carry the session origin through to the outcome. Nothing arrives as an anonymous row in an inbox.

Units are delivered by the same asynchronous script as the rest of the platform, so they do not block page rendering. Rendering happens after page load, and if anything is unavailable, units fail silent: visitors simply see your default page. Rendered units are built to conform to WCAG accessibility requirements, so adding contact experiences does not lower the accessibility standard of your site.

It turns conversations into structured data your systems can act on. A call is transcribed, the content is analysed for intent, product, and urgency, for example "upgrade, fibre 1 Gbps, this week", the outcome is categorised, sale, quote, service, no sale, and the structured result is routed: a record to your CRM, a conversion event to Google Ads and Meta, and a signal back to the Contact Orchestrator's decision model.

Call-Tracking captures where the call came from; Voice Contact Automation captures what it was worth. Together they form the full attribution chain from campaign click to structured conversion event. Conversation analytics tools like Capturi focus on agent performance and conversation quality; VCA's job is the revenue loop, getting the outcome into marketing, CRM, and decisioning automatically. They can run side by side.

Either works, depending on your setup: bmetric can record through its own routing layer, or your telephony records and bmetric ingests the audio. In both cases bmetric acts as data processor under your DPA and instruction, audio and transcripts follow the same retention and access rules as the rest of your bmetric data, and caller notification is configured per market, handled by bmetric or through your own telephony announcements, whichever fits, because consent and notification requirements differ by country.

All EU languages are supported for transcription and categorisation. That covers every market bmetric serves across the Nordics, Benelux, and DACH, and any additional European market you operate in, with one setup.

Category models are defined together with you during onboarding and refined against real calls in the first weeks, so classifications reflect how your business actually talks about outcomes. Every structured record is traceable to its underlying transcription, so any classification can be reviewed rather than taken on faith, and the category model stays under your control as your business changes.

Any loop you want closed. A missed call triggers a callback prompt for that visitor. A completed sale updates the CRM and fires a valued conversion to Smart Bidding. A no-sale on a retention call can flag churn risk in your CDP. The outcome is not a report, it is an event your stack reacts to.

No changes to your agents' setup. VCA consumes calls through the routing layer bmetric operates for Call-Tracking, so calls need to flow through bmetric routing, which they already do in any Call-Tracking deployment. The recording itself can come from bmetric's layer or from your own telephony, whichever fits your setup, and VCA connects to contact centre platforms such as Genesys and Puzzel.

Visitors are divided into a control group, which sees the current experience, and an impression group, which sees the challenger, deterministically and consistently across sessions, so a returning visitor stays in their group. Both run side by side against the same audience, and both are measured on the metrics that matter: contact rate, lead quality, and conversion to sale.

Any element the Contact Builder can deliver: engagement designs, contact formats such as callback versus direct number, trigger timing, channel options, copy, placement, and suppression versus show. The consequential questions most contact strategies never test, does a mid-checkout prompt help or cannibalise, does 30 seconds beat 60, are exactly what this is for.

Tests run until they reach statistical significance, not until someone gets the answer they wanted. The winner rolls out, the loser retires, and the result is recorded against the hypothesis rather than a dashboard impression.

Generic testing tools measure on-page events: clicks, sign-ups, page goals. bmetric's A/B Testing measures contact outcomes across the online-offline seam, including calls, callback quality, and conversion to sale, outcomes generic tools cannot see because they end at the browser. And results do not just sit in a report: every learning feeds the Contact Orchestrator's next decision automatically, so the system compounds. If you already run a site-wide testing tool, they coexist, this one owns the contact layer.

No. Tests go live directly in the platform: the Contact Orchestrator handles the split, the Contact Builder serves both variants, and results land in the dashboard your team already uses. No release windows, no engineering coordination.

Testing costs a fraction of what a wrong assumption costs permanently. The exposure is bounded, half the traffic, for a defined period, until significance, while an untested assumption runs at 100% of traffic indefinitely. The alternative to testing is not safety, it is not knowing which of your current assumptions is quietly losing money.

The visitor's browsing context at the instant the line opens: pages visited, products viewed and time spent on them, campaign origin, and behaviour signals from the session. The agent starts the call knowing the visitor spent ten minutes on the pricing page comparing fibre plans, instead of asking qualifying questions the visitor already answered with their behaviour.

Through the same session-to-call connection that powers Call-Tracking: the visitor calls a session-tied tracking number, so when the call arrives, the preceding session is identified and its context is delivered to the agent's interface at call-connect, not minutes later.

No. Webview is platform-agnostic and drops the session context into the interface your team already runs, Salesforce, HubSpot, Pipedrive, Genesys, Puzzel, Zendesk, Enreach, or your in-house agent desktop. No parallel system, no separate login, no platform migration.

It is processed under the same legal framework as the rest of bmetric: the session data comes from consent-based tracking through your CMP, bmetric acts as data processor under your DPA, and the agent sees session context for the purpose of serving the customer who has chosen to call, not a profile compiled across unrelated activity. What is shown is the visitor's own current journey on your website.

Then there is no session context to show, and the agent takes the call as they do today. Call-Tracking operates only when consent is given, and Webview only surfaces what consent-based tracking has captured. Nothing is inferred or reconstructed for visitors who declined.

Shorter time-to-relevance on every matched call: less qualifying, faster resolution, and higher conversion because the opportunity built during browsing is not handled from zero. Because campaign origin is attached, the same context also confirms for marketing which investments drive the conversations that close.