Tuvis

An analysis layer sits on top of what is fundamentally plumbing, and the plumbing is what customers buy.

The analysis layer is recent and named separately from the platform. It is described as turning messages into data and records, monitoring conversations, identifying risks, automating tasks and generating insights in real time. In the security pillar the same technology applies custom rules, detects data breaches and raises alerts while a conversation is happening.

Risk detection during a live conversation is the capability that justifies the layer, because reviewing an archive after a leak has occurred is a different and much weaker product than catching it as it happens.

Beneath it the work is deterministic and unglamorous: capturing messages from seven channels, writing them into the customer's storage system, synchronising them against records in the customer's platform, and connecting the whole thing to firewall, proxy, single sign on and endpoint controls. None of that requires inference and all of it requires reliability.

A customer who disabled the analysis layer would still have capture, archival, governance and record synchronisation, which is the core purchase.

Ask what the risk detection is trained on and what rule types are supported.

Oversight is not a feature of this product, it is the product.

The governance hole this addresses is real and widespread. Staff conduct business on consumer messengers from personal devices, and the organisation has no record of what was said, no ability to detect a leak and no way to satisfy a supervisor asking for the conversation. Tuvis makes that channel observable.

Three mechanisms do it. Capture and archival write every interaction into the customer's storage system. Rule based detection identifies data leakage as it happens, with alerts raised in real time rather than found in an audit months later. And integration with firewall, proxy, single sign on and endpoint systems brings messaging under the same controls governing everything else, rather than treating it as an exception.

The analysis layer adds live risk identification on top.

That combination is a stronger control position than any record built in this session, and it is aimed at the organisation rather than at the individual user.

What two passes could not locate: how the rule engine is configured and by whom, what an administrator can see about an individual employee, and what employees are told about the monitoring.

That last question is the one a works council would ask first.

Ask what employees are told about conversation monitoring and archival.

Risk detection runs on customer conversations and nothing describes what performs it.

Two passes across the home page, the pillar summaries, the analysis layer description and the footer located no model provider, no model name, no version, no statement of where conversation content is processed for inference, no training or retention position and no accuracy figure.

The accuracy gap matters more here than on most records, because both failure directions carry real cost. A missed detection means confidential information left the organisation and nobody knew. A false detection means an employee was flagged for a conversation that was legitimate, in a system their employer uses to monitor them.

Nothing states an error rate in either direction, and nothing describes how a flag is reviewed before it becomes an accusation.

The processing location question is equally live. Conversation content from seven messaging channels being analysed in real time has to be processed somewhere, and the vendor's own architecture keeps the archive in customer storage while saying nothing about where the analysis happens.

A published processing agreement exists and would be the natural place for both answers.

Ask where conversation content is processed for risk analysis and at what accuracy.

A national oil company, a major image platform and one of the largest telecoms operators in its market, shown by logo.

That customer set is the strongest in this batch and among the strongest in the index. A state controlled energy company does not adopt communications monitoring casually, and its presence implies the vendor has passed a procurement and security review of considerable depth. A telecoms operator, a payments company, an insurance broker and a vehicle dealer group complete the named set.

Four testimonials each carry a company logo and describe a specific operational change rather than offering praise. One describes generating active contacts on a messaging channel and the effect on retention. One describes account managers freed to spend more time prospecting brokers, and names the record system integration as adding speed and security. One describes replacing manual logging of message tasks with a single synchronisation action. One describes connecting customers to dealers for instant response.

Each reads as an operator describing their own workflow.

A customer stories section and a blog with press releases sit alongside.

Deductions: no individual is named against any testimonial, and no figure accompanies any of them.

Ask which of the named customers will take a reference call.

This axis usually asks whether a vendor respects the recipient of unsolicited contact. Here it asks something different, because nothing unsolicited is sent.

The product governs conversations that sales and service staff are already having with customers who chose to message them. There is no campaign, no sequence, no list and no cold contact, so the questions that dominate this axis elsewhere do not arise.

What the product does address is the customer organisation's own regulatory obligation. In financial services, insurance, energy and several other supervised sectors, business communications must be captured, retained and producible on request, and the widespread use of consumer messengers has left most organisations unable to comply. Capturing and archiving those channels is the mechanism by which they can.

The vendor writes publicly about failures in that market, including a piece on a competing archiving service being disrupted and what it means for regulated organisations.

What is not addressed: nothing states what the customer on the other end of an archived conversation is told, and in several jurisdictions recording a conversation requires notice to all parties.

Ask what notice is given to the external party in an archived conversation.

A processing agreement published as its own page, and an architecture that keeps the archive with the customer.

The architecture is the substantive part. Interactions are captured and archived directly into the customer's existing data storage system rather than into infrastructure the vendor operates. That means the most sensitive material this product touches, the complete record of business conversations, never becomes the vendor's to hold, lose or be compelled to produce. Residency, retention and access all remain governed by whatever the customer already has in place.

Across this index most vendors answer privacy questions with policy. This one answers a large part of it with design.

The documentation supports it: a data processing agreement on its own linked page rather than available on request, a dedicated software security page, a separate compliance page, plus privacy, terms and cookie policies. Three distinct governance documents rather than one is more structure than most vendors at any size manage.

Deductions: none of the pages was opened in this pass, no subprocessor list was located, and no statement covers where the real time analysis processes conversation content, which is the one flow that must leave the customer's estate.

Ask where analysis processing occurs and what the processing agreement covers.

No data about anyone is supplied, and the flow runs inward rather than outward.

Two passes across the home page, the three pillar descriptions, the channel list and the footer located no contact database, no record count, no enrichment engine, no lead finder, no intent signals and no third party data supplier anywhere in the product.

What the platform handles is conversations the customer's own staff are already having, with people who chose to message that company on a channel they chose to use. The customer initiated nothing based on a purchased list, and the vendor supplies no names to contact.

That direction of flow is worth stating plainly because it inverts the usual position on this axis. Most records here acquire data about people and push it toward sellers. This one captures what those people said and pushes it into the customer's own archive and record system.

The provenance question that dominates this axis, where did these names come from and on what basis, simply has no application.

The one adjacent question concerns retention of the message content itself, and the architecture answers it by leaving that in the customer's storage.

Ask what metadata the vendor retains separately from the customer archive.

Sanctioned on the record system side, unestablished on the messaging side, and the vendor's own blog documents why that distinction matters.

The sanctioned half is genuine and verifiable. This vendor is listed on one major enterprise platform's official application exchange and describes itself as an official partner of another. Its browser extension is published in the official store. More than fifty integrations span security, compliance and productivity platforms, all through published partner interfaces. That is a company operating inside the arrangements rather than around them.

The contrast with a record built earlier in this same session is instructive. Both operate on the same proprietary messaging channel. One is an exchange listed partner of two enterprise platforms. The other runs racks of physical handsets and states it burned through two hundred SIM cards mapping the platform's spam detection.

What remains unestablished is whether the messaging platform operators sanction third party capture of their conversations. The vendor's own blog answers indirectly, publishing a piece on a competing archiving service being disrupted and framing it as a warning for regulated organisations, which indicates the platform operators do act.

Operation is through the browser versions of the messaging applications.

Ask what happens to archival if a messaging platform changes its interface.

The stewardship position is architectural and strong; the model position is undisclosed.

Stewardship first. Archived conversations land in the customer's own storage rather than the vendor's, which removes the largest custody risk by design. Around it sit a published processing agreement, a dedicated software security page and a separate compliance page, all linked from the footer under company policies. Integration with the customer's firewall, proxy, single sign on and endpoint systems means the vendor's product operates inside the customer's existing control perimeter rather than beside it.

For a product whose entire function is handling confidential business communications, keeping the archive out of vendor hands is the right decision and it is not the obvious one commercially.

The model side is undisclosed. Real time risk analysis reads conversation content and no provider, evaluation, accuracy figure or processing location is published. That analysis is the one flow that necessarily leaves the customer's estate, which makes its handling the question the architecture does not answer.

Two passes located no certification confirmed, no vulnerability disclosure route and no named security contact, though the security page was not opened.

Ask what the software security page states and where analysis processing occurs.

Real people have real conversations, and everyone in them is being recorded.

The authenticity half is clean. Two passes located no persona, no synthetic sender, no cloned voice, no generated message presented as human, no rented identity and no automated outreach of any kind. A customer messages a company on a channel they chose, and an employee answers. The vendor's effect is to make that exchange recorded and governed rather than invisible, which if anything improves accountability for what was said.

The disclosure half needs stating plainly. Every party to every conversation on seven channels is captured, archived and analysed for risk in real time. Two passes located no description of what the external customer is told before they message, and no description of what the employee is told either.

Both matter. Several jurisdictions require notice to all parties before a communication is recorded, and the customer base includes markets with specific employee monitoring requirements. The vendor's Brazilian concentration puts it squarely under a data protection regime with defined obligations to data subjects.

The published processing agreement is where those notices would be specified and it was not opened.

Ask what notice is given to customers and employees before capture begins.

More than fifty integrations across four distinct categories, and the channel list reaches markets almost nothing else here covers.

Seven messaging channels are supported, and two of them are the notable ones: the dominant messengers in Japan and Taiwan, and in China respectively. Western vendors routinely ignore both, which makes any company selling into those markets unable to govern the channels their customers actually use. Supporting them alongside the global messengers, voice and text is a deliberate market decision.

The record system list covers two enterprise platforms and three mid market ones, with official partner status on the first two and a listing on one's application exchange.

The security integrations are what make the compliance claim workable: firewall, proxy, single sign on and endpoint, so messaging is governed by the tools the customer already runs rather than by a parallel system nobody maintains.

Compliance integrations connect to the customer's existing storage, which is how the archive stays in customer hands.

A partner programme is published and the browser extension is distributed through the official store.

Ask which storage systems are supported for archival.

The residency question is answered by architecture rather than by policy.

Archived interactions are written directly into the customer's existing data storage system. That single design choice resolves what most records in this index leave open: a buyer does not need the vendor to state a hosting region for the archive, because the archive sits wherever the buyer already keeps its data, under the buyer's own residency arrangements, retention rules and access controls.

For an organisation in a market with data localisation requirements, that is a materially better answer than a vendor promising to host in the right place.

Operation on the messaging side is through the browser versions of the applications, so no device provisioning, no managed handsets and no separate infrastructure for the customer to accept.

Three language markets are served, with a translation layer visible in the page.

What two passes could not locate: any hosting provider or region for the vendor's own platform, any tenancy or isolation model, any encryption statement, any continuity position, any uptime commitment and any status page. The real time analysis is the flow whose location remains unstated.

Ask where the platform itself runs and where analysis processing occurs.

Three governance documents published separately, which is more structure than most vendors manage at any size.

The footer carries a section headed company policies containing a data processing agreement, a compliance page and a software security page as three distinct links, alongside terms, privacy and cookie policies. Splitting security, compliance and data processing into separate documents rather than folding them into one indicates a vendor that has been asked about each independently.

None was opened in this pass, so no certification, auditor, scope statement, report request process or subprocessor list is recorded here, and a buyer should read the security page first.

The customer base implies something substantive sits behind them. A state controlled energy company, a major telecoms operator and an insurance business do not deploy a system that reads and archives their staff's customer conversations without completing a full security and compliance assessment. That the vendor holds those accounts is indirect evidence of what it has already passed.

What two passes could not locate: any vulnerability disclosure route, any named security contact and any status page.

Ask which certifications the software security page lists and their renewal dates.

No figure anywhere, and three separately marketed pillars with no indication how they are packaged.

Two passes across the home page, the pillar summaries, the channel page reference and the footer located no price, no tier, no seat rate, no usage metric, no minimum and no indicative range. There is no pricing page in the navigation at all. Every route terminates at a demonstration request.

The form collects a first and last name, email address, company, telephone number, job title, a company size band and which of the three solutions is being sought, before anything is offered in return. The size bands run from under fifty employees to over a thousand, which confirms an enterprise sales motion.

The packaging question is the one a buyer cannot answer from outside. Security, compliance and productivity are presented as three distinct solutions with their own pages, and the form asks which one is wanted, so they are evidently sold separately or in combination. Whether a customer wanting only record system synchronisation pays for the governance apparatus, and whether channels are priced individually, is unstated.

More than fifty integrations are claimed with no statement of which are included at any level.

Ask how the three pillars are packaged and whether channels are priced separately.

The most valuable thing this product produces never belongs to the vendor in the first place.

Interactions are captured and archived directly into the customer's existing data storage system. That means the complete record of business conversations across seven channels, which is the accumulated asset and the thing a regulator would ask for, sits in the customer's own infrastructure from the moment it is written. A customer who leaves keeps all of it, in a system they already control, without an export, a migration or a request.

Across this index that is the strongest position on this axis. Several records built this session describe no export mechanism at all, one reserves programmatic access for its most expensive tier, and several hold years of correspondence with no stated route out. This vendor sidesteps the question by never taking custody.

Record system synchronisation compounds it, since message history against contacts and accounts also lives in the customer's own platform.

What would not travel: the rule configuration, the security integrations, the channel connections and whatever metadata the vendor holds separately. Two passes located no deletion commitment or retention position covering that residue.

Ask what the vendor retains after termination and for how long.

Almost nothing on this axis applies, because the product governs conversations rather than starting them.

There is no campaign engine, no sequencer, no mailbox provisioning, no warm up, no rotation and no sending reputation to protect. Traffic consists of individual employees replying to individual customers who messaged them first, which is the lowest risk sending profile in this index and needs none of the apparatus this axis usually measures.

What is adjacent and real: the productivity layer lets a seller start a conversation from a record without leaving the platform, and one customer testimonial describes generating active contacts on a messaging channel as having improved retention and engagement. So outbound initiation does occur, at individual scale.

Voice and text are among the supported channels, both regulated in ways the messaging channels are not.

What two passes could not locate: any sending limit, any guidance on initiating contact, any reference to messaging or telephone regulation on the channels supported, and any opt out mechanism for a customer who no longer wishes to be contacted on a messaging channel.

Ask what governs outbound initiation from the record system.

Segmented precisely on three dimensions at once, and each is evidenced rather than claimed.

By obligation. The product targets organisations that must capture and retain business communications, and the vendor writes directly about regulated organisations and the consequences of archiving failures. The named customers fit exactly: energy, telecommunications, insurance and payments are all supervised sectors where communication records are producible on demand.

By geography. Three languages with Portuguese primary, a customer base concentrated in Brazil including a state controlled energy company and a leading telecoms operator, and channel support extending to the dominant messengers of two Asian markets that Western vendors routinely ignore. That combination addresses regions where messaging applications carry business that email carries elsewhere.

By buyer. Three pillars address three functions inside the same organisation: a security team worried about leakage, a compliance function facing a supervisor, and a revenue team wanting the conversation in the record system. The demonstration form asks which one applies.

Company size bands run from under fifty to over a thousand, though the named customers sit firmly at the top.

Ask which regions the channel coverage is strongest in.