Vitally

A platform of some standing with an assistant layer added on top of it. The substance of the product is computation the customer configures: usage events arrive from their own application, a health score is calculated from a weighted model they define, an automation fires when that score crosses a threshold they set, a project advances, a document is shared, a survey goes out on a schedule. All of that is deterministic and all of it predates the model layer.

What sits above it is a named assistant area covering account and meeting summarisation, which reviewers single out as a real time saver and which is genuinely model dependent. Strip it and the platform that five hundred teams are described as running on remains intact, including every scoring, automation and reporting capability.

Two adjacent artifacts show the vendor investing in the surrounding ecosystem rather than in its own model: a published library of skills for a third party assistant, and a prompt guide for practitioners. Both help customers use somebody else's models alongside this product, which is a distribution posture rather than a centrality one. Ask which capabilities stop working without the assistant, and how health scores are computed.

Two published permission constructs, and nothing describing what an automation may do to a customer relationship unattended. The constructs are real and both sit on every plan rather than being reserved for larger buyers. Unlimited read only seats let anyone in the business see an account without being able to change it, which is the right shape for the executives and product managers who want visibility into customers without touching the workflow, and charging nothing for them is a deliberate choice.

Single sign on is included on every plan, which most vendors in this category reserve for their top tier, so identity control does not depend on spend. Against those, automations are unlimited on every plan and fire on score changes, usage drops and lifecycle milestones, reaching the customer's own customers with messages and surveys, and nothing published describes an approval step before an automated touch goes out, a volume ceiling, a suppression mechanism, or what halts a playbook already running against an account that has just escalated.

The assistant layer summarises accounts and meetings, and nothing states whether a summary is reviewed before it informs an automated action. Ask what approval or hold exists before an automated customer touch, and what stops a playbook mid flight.

A named product area, an ecosystem investment, and nothing about the models. The vendor presents its assistant work as its own section of the product covering account summarisation, meeting summarisation and copilot assistance, and reviewers describe the summaries as the most valuable recent addition.

No model provider, family or version is named, no model card exists, and no accuracy, quality or evaluation figure is published for the summaries, which matters because a summary of an account is what a person then acts on without rereading the underlying material. Two published artifacts are unusual enough to record and neither closes the gap.

The vendor publishes a downloadable library of skills for a widely used third party assistant, aimed at customer success practitioners, and a prompt guide for the same audience. Both are investments in helping customers work with models the vendor does not supply, which is a genuine contribution to the practice and tells a buyer nothing about what runs inside the platform.

Publishing skills for somebody else's assistant while naming no model inside its own product is a distinctive combination. Ask which models power account and meeting summarisation, and what evaluation covers them.

Better disclosure practice than almost anything in this category, undermined by arithmetic that inflates both headline figures. The vendor publishes two performance claims with everything a reader normally has to ask for: the figure, the comparison baseline, the units, and an attributed third party source.

It states time to go live of one point nine months against an industry average of two point six, and time to estimated return of eight point six three months against an industry average of fourteen point three eight. Publishing the baseline alongside the claim is exactly what this axis keeps asking vendors to do. The percentages presented above those numbers do not follow from them.

The page labels the first as seventy three percent faster and the second as sixty percent faster, but one point nine is seventy three percent of two point six, and eight point six three is sixty percent of fourteen point three eight. Those are ratios, not improvements. The improvements the vendor's own figures support are twenty seven percent and forty percent, so both headlines overstate the gain by roughly two and a half times.

The error is checkable precisely because the vendor published the underlying numbers, which is why it is recorded rather than assumed. Around it sit five hundred named teams, customer stories identifying the company and the practice, and testimonials linked to their source reviews rather than quoted loose. Without the arithmetic error the disclosure would have supported a higher grade. Ask which figure the vendor stands behind, the percentage or the months.

The recipients are the customer's own paying customers, which lightens this axis considerably, and the mechanics are unpublished. Automated messages, satisfaction surveys and custom surveys reach users of the customer's product under an existing contractual relationship, so the consent question is materially different from cold contact and the volume patterns that make this axis bite do not arise. That is why this sits mid band rather than lower. What is absent is the detail beneath.

Nothing published describes how a recipient declines further automated messages, whether a preference expressed against a survey carries across to lifecycle messaging, how frequently a given person can be surveyed, or what obligations the vendor considers to sit with the customer whose brand the messages carry.

Survey contact is worth separating from service communication, because research outreach is regulated differently in several jurisdictions and a satisfaction survey sent on an automated cadence to a large user base is closer to the former. Ask what unsubscribe and frequency controls exist for automated messages and surveys, and whether a preference propagates between them.

One real user facing control published site wide, and the processing instruments out of reach. The control is a privacy choices mechanism in the footer of every page, offering the opt out that state privacy law provides for, which is a working control rather than a policy paragraph and more than most vendors in this category surface.

A privacy policy and terms sit alongside it, and a dedicated security page exists in the footer that was not retrieved on this pass, so material may sit behind it and nothing here asserts otherwise. What could not be established: no processing agreement, subprocessor list, retention period, transfer mechanism or data protection contact. The corpus deserves stating because it is more granular than an account record.

This platform ingests event level product usage for the individual end users of its customers' software, either through connections to analytics tools or through a script the customer embeds in their own application, and holds it alongside survey responses, satisfaction scores and years of health history. Those end users are two steps removed from this vendor and are unlikely to know the platform exists. Ask for the processing agreement and subprocessor list, the retention period for event level usage data, and what end users are told about it.

No third party data enters the product and the grade records the scope. The vendor supplies no contact database, no firmographic corpus, no intent feed and no enrichment, so there is no purchased dataset whose origin a buyer needs to trace. Everything held arrives from the customer's own systems: usage events from their application, records from their customer platform, tickets from their support tool, invoices from their billing system and responses to surveys they sent.

That is a clean position and worth stating plainly. Two questions are open rather than absent. The vendor publishes industry benchmark figures for time to deployment and time to return, attributing them to a third party review platform rather than to its own customer base, and nothing states whether any benchmark shown inside the product draws on aggregated customer data.

And the assistant layer summarises accounts and meetings, with nothing published about what reference material it draws on or whether anything from one customer's tenancy informs another's. Ask whether any in product benchmark uses aggregated customer data, and what the assistant draws on beyond the customer's own records.

Official routes throughout, and the full connector set is included on every plan rather than sold upward. Named integrations span customer record platforms, support desks, product analytics tools, a data warehouse, team messaging, calendars, billing and issue tracking, each through that product's own documented interface, and the vendor states the complete integration library is available on all three plans.

That last point matters more than the count: a customer on the entry plan is not cut off from the systems their data lives in, which is the opposite of the usual pattern and removes the most common reason a deployment underperforms. Nothing scrapes a professional network, drives a browser extension against one or automates a social account, so the exposures that dominate this axis elsewhere do not arise. Held below the top band for two reasons.

No conformance position is stated in the vendor's own words for any connected platform. And the ingestion path runs the other way as well: usage events can be sent through a script the customer embeds in their own application, which puts this vendor's code in front of the customer's end users, and nothing published describes what that component collects, how it is versioned, or what happens if it fails. Ask what the embedded ingestion script collects and how failures in it are contained.

An assistant operating over customer relationship data, and a published invitation to route that data somewhere else entirely. On the first, the summarisation layer processes account histories, meeting content, usage patterns and survey responses covering the customer's own customers, and nothing published states whether any of it trains or tunes a model, which provider processes it, what retention applies to prompts and generated summaries, or whether anything crosses a tenant boundary.

No governance document, evaluation record or independently audited management standard for artificial intelligence was located, and the security page that might address some of it was not retrieved here. The second point is particular to this vendor and worth a buyer's attention. It publishes a library of downloadable skills for a widely used third party assistant, aimed at its own users and at their customer success work.

Skills of that kind operate by giving an external assistant access to material a practitioner is working with, so the vendor is actively encouraging its customers' relationship data to be handled by a system neither party to the subscription controls, and nothing published addresses what that implies for confidentiality or for the customer's own commitments to their end users. Ask whether platform data trains any model, and what data the published assistant skills expose.

The people contacted are the customer's own users, which is the lightest position this axis records, and machine authorship goes unmentioned. Automated messages, satisfaction scoring and custom surveys reach individuals inside accounts that already pay the customer, arriving under the customer's brand from a company those people already deal with, and there is no persona, no synthetic voice and no agent presenting itself as a person anywhere in the product.

Shared documents bring customers into a collaborative surface openly rather than observing them covertly. What is unaddressed sits at the newer edge. The assistant layer summarises accounts and meetings, and nothing published states whether content it generates is reviewed before it reaches an end user through an automated message, or whether anything indicates machine authorship.

The setting gives that slightly more weight than it would carry elsewhere, because a message arriving inside a customer success workflow is read as coming from a named person who owns the relationship rather than from the software. Ask whether generated content can reach an end user without human review, and whether anything marks it.

The full connector library on every plan, including a data warehouse connection and a direct ingestion route. Named integrations cover customer record platforms, support desks, product analytics tools, team messaging, calendars, billing, issue tracking and a cloud data warehouse, which is a broader set of system categories than a customer success platform strictly needs and reflects the product's premise that health depends on data from everywhere the customer touches.

Two elements give it real depth. A scripting interface lets a customer send product events directly rather than depending on an analytics tool the vendor happens to support, which removes the usual dependency chain and means a product with unusual telemetry is not excluded. And a library of prebuilt workflow templates gives new deployments a starting configuration rather than an empty system. Documentation sits on its own subdomain alongside a training academy.

Held below the top band because no general programmatic interface was located beyond the event ingestion route, so a customer wanting to read data out or drive the platform from their own systems has no documented path, and no partner marketplace or directory was found. Ask whether a documented interface exists for reading data out, and for the enumerated connector list.

Nothing on hosting, region, tenancy or recovery was established on this pass, and a dedicated security page exists in the site footer that was not retrieved, so this records the limit of the pass rather than a finding of absence. Two adjacent facts are published and neither answers the question. A cloud data warehouse connector exists, which tells a reader the platform can exchange data with a warehouse rather than where the platform itself runs.

And review platform recognition spans the Americas, Europe, the United Kingdom, Canada, Latin America and Asia Pacific, which evidences customers in those regions without saying anything about where their data is held. The gap has weight for this product because of what it ingests.

Event level usage data describing what named individuals did inside a customer's software, held alongside survey responses and health history, is the kind of material a European or United Kingdom buyer's data protection review examines closely, and no region, residency election, tenancy model or recovery objective is published in either direction. Ask which provider and regions host the platform, whether a regional option exists, and what the recovery objectives are.

A dedicated security page exists in the site footer and was not retrieved on this pass, so what it holds is unestablished rather than absent and nothing here should be read as asserting that no programme exists. What could be confirmed from the pages read is one substantive control and one gap.

The control is that single sign on is included on every plan rather than reserved for the largest buyers, which is a deliberate choice with real consequences: identity governance is where most breaches of a shared workspace begin, and a vendor that puts it behind its top tier makes its cheapest customers its weakest. Publishing it as included across the board is worth crediting and is not the norm in this category.

The gap is everything verifiable: no certification is named, no audit period, auditor or report request route appears on the pages reached, no penetration testing statement was found, and no trust portal was located. The corpus behind the question is event level behavioural data about the end users of the customer's software, which sits a step further from the buyer than their own records do. Ask which attestations are held with their audit periods and auditors, whether penetration testing is performed and a summary is available, and what the security page states.

A page headed as simple and flexible pricing, carrying three plan names and no prices. Verified at the instrument: the pricing page presents three tiers named for customer success operating models, each with a request pricing button and no figure, beneath a heading promising plans that scale with the buyer's needs and a description calling the pricing simple and flexible.

What is published is the feature story rather than the cost: every plan carries the core feature set, unlimited automations, unlimited read only seats, single sign on, the full integration library and unlimited documents, with the top tier additionally marked as carrying unlimited full seats. So a buyer can establish exactly what they get and nothing about what they pay, and the tiers differ on scale limits that are themselves unstated.

The external record is worse than absent, it is contradictory. Independent sources give a starting figure around three hundred dollars a month, another around one hundred and fifty, and a procurement data service describes list pricing of fifteen hundred to two thousand dollars a month for an entry tier, under three tier names that do not match the vendor's own.

That last is worth recording plainly: a widely used procurement source attributes published list pricing to a vendor that publishes none, using a plan structure the vendor does not use. Ask for the rate at the buyer's account volume and seat count, what limits distinguish the tiers, and the minimum commitment.

Nothing published on leaving, and the accumulated asset is unusually configuration heavy. No export scope or format, no post termination access window, no retention or deletion timeline and no notice period was located on any surface reached. What a departing customer would leave behind is worth setting out, because the raw records are the smallest part of it.

A working deployment holds a health scoring model built around how that specific business defines a healthy customer, automation playbooks tuned over time, workspace and project structures, document templates, survey instruments and their response history, and the accumulated event level usage history that gives every score its meaning. The scoring model and the playbooks are the parts that took longest to get right and are the least likely to be portable to anything else.

A second consideration follows from the ingestion route: usage events can arrive through a script embedded in the customer's own product, so leaving involves removing code from shipped software rather than disconnecting an integration, and nothing describes that process. Ask what exports and in what format, whether scoring models and playbook definitions are included, what happens to usage history at termination, and what removing the embedded ingestion component requires.

The platform sends on the customer's behalf across three channels and publishes nothing about the mechanics. Automated lifecycle messages, satisfaction scoring requests and custom surveys all reach the end users of the customer's product, and unlimited automations on every plan means the volume is bounded by configuration rather than by licence.

Nothing published describes which infrastructure sends, whether messages leave from vendor domains or the customer's own, who configures the sender authentication records, what bounce or complaint handling applies, or whether any threshold pauses an automation.

The exposure is genuinely lower than for outbound products, because every recipient is a user of software the customer already sells them and the relationship supplies its own basis for contact, so complaint rates should be structurally low. It is not nil.

Satisfaction surveys and win back sequences reach users who are already disengaged, which is the population most likely to mark a message as unwanted, and the sending domain is typically the customer's own so the reputational consequence lands there. Ask which infrastructure sends, who owns the authentication records, and what complaint rate pauses an automation.

The plan structure is the segmentation statement, and it is a better one than company size would give. Rather than tiers named for scale, the three plans are named for customer success operating models, covering one to many and product led motions, mixed models, and one to one white glove work, which means a buyer selects on how they actually run the function rather than on how many employees they have.

Two organisations of identical size running opposite models land in different plans, correctly. Roles are named separately for individual managers, leaders, operations staff and account managers, and the vendor publishes comparison pages against five named competitors, four of which are recorded in this index, so a buyer can triangulate.

Coverage evidence is real rather than claimed, with more than five hundred named teams, identifiable customer logos, and review platform recognition spanning the Americas, Europe, the United Kingdom, Canada, Latin America and Asia Pacific. Two things hold it below the top band. No minimum account volume, team size or budget is stated anywhere, so a buyer cannot tell whether they are too small before entering a sales process, and the limits that separate the three plans are unpublished.

And no language or regional availability statement was located despite the geographic spread of the recognition. Ask what account and seat limits define each plan, and which languages and regions are supported.