Chili Piper

A decade old scheduling and routing engine with an agent layer added above it, which is the incumbent pattern this convention was written for. The core is deterministic and always has been: a form submission triggers qualification against stated criteria, a routing rule assigns an owner by territory, ownership or round robin, and a calendar interface offers real availability. None of that requires a model, and the company built its category on it from 2016.

The model layer arrived later and is enumerated separately as named agents for spam checking, meeting preparation, assistance and email composition, plus an automated chat product. The metering settles it: artificial intelligence credits are a distinct allowance consumed by enrichment, agents and agent actions, sold in bundles when exhausted, and a capability the vendor meters apart from the subscription is detachable from it by construction, which is the same reasoning applied to two other records in this index.

Strip the models and a buyer still has the product the named reference customers describe adopting, which is form to calendar booking and lead distribution. Ask which capabilities stop working when the credit allowance is exhausted, and what the platform does with agents disabled.

Four named constraint mechanisms on the automation, published as product features rather than as policy, which is more than most records in this index carry. Meeting limits and weighting cap how much the router will assign to any one representative. Capping rules do the same on record assignment. Booking controls are described as preventing favouritism, which is an explicit fairness constraint on an allocation algorithm and an unusual thing for a vendor to name.

Meeting calibration accounts for no shows, cancellations and spam so that a representative is not penalised or overloaded by outcomes outside their control, and a spam checking agent filters submissions before they enter the routing path at all. Alongside those sit user permissions, activity logs and service level agreement management. Together they describe an automation whose limits are configurable by the operator and visible after the fact.

Held below the top band because the agent layer is not covered by any of it. Nothing published states what the automated chat may commit to in a conversation with a visitor, whether output from the email composition agent passes review before sending, what an agent may spend from the credit allowance unattended, or what halts an agent mid conversation. Ask what the chat agent is permitted to state, whether generated email is reviewed before it sends, and what caps agent credit consumption.

The routing logic is explainable by construction and the model layer is not described at all. This axis asks three things, and one of them is answered better here than almost anywhere in this index: assignment is performed by operator defined rules covering territory, ownership, round robin order, weighting, capping and fuzzy lead to account matching, so a customer can inspect why any given lead went to any given representative without needing a model card.

Rules are auditable in a way a learned score is not, and the published activity logs support that. The other two are unanswered. Six agents are named across spam checking, meeting preparation, assistance, email composition and automated chat, plus a protocol server and a programmatic interface, and no model provider, family or version is stated for any of them, no model card exists, and no accuracy, quality or evaluation figure is published for the chat agent, the spam classifier or the composition agent.

Credit consumption per agent action is not published either, so a buyer cannot tell which agent is expensive to run. Ask which models power the named agents, what evaluation covers chat and composed email before either reaches a visitor, and what each agent action consumes.

Five named customers with named individuals, stated roles and linked case studies, and no method behind any figure. The published claims are specific and attributed to identifiable people: a seventy percent lift in demonstration request form conversion and a fivefold increase in demonstration requests at a revenue intelligence company, eighty five percent of inbound leads converted at a demonstration software company, a twenty five percent improvement in speed to scheduling a kickoff call at a restaurant technology company, and a brand platform reporting ten percent in the first quarter moving to eighty to eighty five percent lead to introduction after a year, with a thirty five percent conversion lift attributed to a named module.

That last one is the strongest single piece of evidence on the page because it states a trajectory over a stated period rather than a bare multiple. Set against that, three headline figures carry the argument at the top of the pricing page, a ten to fifteen percent revenue increase, seventy percent of hand raisers converting instantly and a fifty percent reduction in no shows, and none of the three is attributed to any customer, population or study.

No figure anywhere states what it was measured against or over what period, and eighty five percent of inbound leads converted has no definition of what conversion means. This is the same shape as the inbound agent vendor graded earlier in this project and takes the same grade. Ask what the three headline figures are measured across, and for conversion lift against a stated baseline and period.

Most of what this platform sends is transactional and the part that is not goes to people who did not finish the form. The primary motion is scheduling correspondence to someone who has just submitted a request, which is about as consented as business communication gets and is why this record is not lower. Two published capabilities sit outside that.

Re-engagement flows contact people who abandoned a form, meaning they began an enquiry and chose not to complete it, and an email composition agent generates correspondence. Nothing published addresses either. No consent basis is stated for contacting an abandoner, no unsubscribe or suppression mechanism is described for re-engagement flows, no sender identity requirement appears, and nothing states which obligations the vendor considers to transfer to the customer whose domain the mail leaves under.

The vendor does publish contractual privacy terms and a compliance position for the regulation governing European personal data, so the framework exists at the contract level even though the specific mechanics of marketing mail are absent from the published surface. Ask what consent basis supports re-engagement of a form abandoner, what unsubscribe handling applies to those flows, and whether an objection recorded in the connected record system suppresses them.

The use commitment is tighter than most and the instruments around it are incomplete. What the vendor states is unambiguous and carries no carve out: customer data is used only to provide the subscribed service, it is not shared with any third party, it is not used for marketing, and it is not mined or accessed for commercial purposes.

That last phrasing matters because the common formulation elsewhere in this index permits use for improving the services, which is the opening a buyer would want closed, and this vendor does not take it. Around that sit real controls rather than assurances: access to customer data is described as strictly controlled and logged with sample audits performed by the vendor and by third parties, database access is limited to two named roles reached through a private network with two factor authentication, each tenant occupies its own database instance, and the vendor commits to notifying customers promptly by electronic mail if data is accessed improperly and to announcing security and privacy changes in the product.

Compliance with the European regulation is placed in an exhibit to the published terms, so it is contractual rather than asserted on a page. Held below the top band on three absences that a privacy review will ask for immediately: no subprocessor list was located, no retention period is published, and the transfer position is described as an addendum with model clauses held through the cloud provider rather than as an instrument the vendor executes with its customer, which is ambiguous as published. Ask for the subprocessor list, the retention period, and who the counterparty is on the model clauses.

Two routes to the same capability, one transparent and one not, and the difference decides this grade. The vendor states that account identification for deanonymization requires either a relationship with one of two named intent providers or the use of its own credits.

The first route is exemplary on this axis: the supplier is named, both named suppliers are separately indexed here, and the customer contracts with them directly, so provenance can be evaluated at source rather than taken on trust. The second route is undocumented. Nothing states what data backs identification purchased with the vendor's own credits, which supplier or graph it draws on, on what basis those records were collected, or whether the two routes produce equivalent results.

A buyer choosing the credit path is buying identification of named individuals from a source that is never named. The same split appears on enrichment, where five providers are named as integrations for customers who bring their own contract, while enrichment used for form shortening carries no stated source. No indemnification position was located for either path. Ask what data backs identification bought with credits, whether it differs from the named provider route, and whether provenance is indemnified.

Own infrastructure and sanctioned connectors throughout, with one platform relationship verified by that platform rather than asserted by the vendor. The strongest element is a completed security review administered by the customer record platform this product depends on most, which is a review process run by the platform itself and passed, not a claim the vendor makes about itself.

Around it the integration surface is entirely official: documented connections into two record platforms, both major calendar providers, two messaging platforms, marketing automation systems, intent providers, enrichment providers, sales engagement platforms and a dialer, plus a protocol server, a programmatic interface, webhook triggers and custom outbound calls.

Nothing scrapes a professional network, drives a browser extension against one, automates a user's social account or operates multiple identities, so the exposures that separate this category fastest do not arise here at all. Held below the top band because the review covers one platform among many.

The product reads and writes calendar availability at volume across two major providers and holds authorisation tokens for them, and no conformance position, rate limit observance or contingency is published for either, nor for the messaging platforms it posts into. Ask what conformance position applies to the calendar providers, and what happens to a deployment if a connector's terms or interface change.

A strong general commitment written before the agents existed, and nothing written since. The stewardship position is genuinely good as far as it reaches: customer data is used only to provide the subscribed service, with no third party sharing, no marketing use, no commercial mining, and access strictly controlled, logged and sample audited by the vendor and by outside parties.

Read literally that language would exclude training a model on customer data, and it carries none of the improvement carve out that weakens the equivalent commitment elsewhere in this index. What is missing is any statement addressed to the model layer specifically, and the product now ships six named agents plus an automated chat product that holds conversations with a customer's prospects.

Nothing states whether conversation transcripts, meeting content or routing data train or tune any model, which providers process material when an agent runs, what retention applies to prompts and generated output as distinct from stored records, or whether anything crosses a tenant boundary despite the per tenant database isolation described elsewhere.

No governance document, evaluation record, red teaming artifact or independently audited management standard for artificial intelligence was located. Ask whether the no other use commitment is understood to exclude model training, which providers process agent workloads, and what retention applies to chat transcripts.

The person on the other side has usually just raised their hand, which is a materially different starting position from the rest of this cohort, and the agent layer is still undisclosed. The main motion engages someone who arrived at the customer's own website and submitted a form, so they know they are in a sales conversation and are expecting contact.

The product does not present an agent under a human name, does not sell itself as replacing a person, and produces no synthetic voice or video. Those are real distinctions and they are why this sits mid band rather than lower. Three things are unaddressed. The automated chat product engages visitors around the clock and nothing published states whether it identifies itself as automated, or what it says if asked.

An email composition agent generates correspondence that leaves under a representative's name with no stated marking. And the upper tier adds account identification for deanonymization, which reaches visitors who did not identify themselves at all, with no disclosure position accompanying it. Ask what the chat agent says at the start of a conversation and when asked whether it is a person, whether composed email is marked as generated, and what a deanonymized visitor would be told.

One of the widest named integration surfaces catalogued in this index, with a programmatic layer that is current rather than legacy. Published by name: two customer record platforms, both major calendar providers, two messaging platforms, three marketing automation systems, two intent providers, four enrichment providers, three sales engagement platforms, a dialer, a review platform, a professional network and a demonstration tool as scheduling sources.

Around them sit a protocol server for programmatic scheduling, an edge interface, webhook triggers, custom outbound calls to external systems and stored authorisation keys, which together let the platform act as a component in an automated stack rather than only as an application. Several of the named integration partners are separately indexed here, so a buyer can evaluate the pieces independently. Two things hold it below the top band.

The routing depth is asymmetric: routing any standard or custom object, fuzzy lead to account matching, duplicate merging and record creation are described under one record platform specifically, and no equivalent depth is stated for the other. And the per tier availability of the programmatic layer did not render in the comparison table on this pass, so whether the protocol server and interface are included at the entry tier is unestablished. Ask which routing capabilities exist on the second record platform, and at which tier the programmatic interfaces are included.

Recovery objectives are published as numbers, which almost nothing in this index does, and the architecture around them is named rather than gestured at. The vendor states a maximum recovery time objective and recovery point objective of twelve hours, with backup and disaster recovery processes described as tested and certified, and that is the specific commitment this axis exists to surface.

The rest of the architecture is stated with equal directness: operations run on a named cloud provider with a named orchestration layer, backups sit in that provider's storage, each tenant occupies its own separate database instance rather than sharing one, transport is encrypted at a stated strength, and sensitive data is encrypted at rest. Per tenant database isolation is a stronger statement than the logical segregation most vendors offer and it is worth naming as such.

Held below the top band on residency. The vendor states that servers are hosted across the United States and describes no European or other regional option, while also claiming compliance with the European regulation and citing named European customers, so a buyer with a residency obligation of their own has no election available. No sub region detail, failover architecture or single tenant option beyond the database separation is described. Ask whether any regional processing option exists, and what the twelve hour objectives cover.

Two certifications, a genuinely detailed control narrative, and nothing a buyer can verify before a sales conversation. Published are a service organization control type two audit with its scope stated as security, availability and confidentiality, certification of the information security management system, and a completed security review administered by the customer record platform.

The control detail behind them is better than most records at this grade: database access limited to two named roles through a private network with two factor authentication, per tenant database separation, encryption at stated strengths in transit and at rest, secure coding practice named by framework, access strictly controlled and logged with sample audits by the vendor and third parties, a breach notification commitment, a status page and published support metrics.

What is absent is the verifiable layer, and it is absent completely. No audit period, audit date, auditor, certificate number or scope statement accompanies either certification, no penetration testing statement appears anywhere, and no formal vulnerability disclosure programme exists, with incidents directed to a general support address instead. A security portal is referenced in the first paragraph and no link to it rendered on this pass, so it was not reached.

Two enterprise vendors earlier in this project named the same certifications with the same absence of verifiable detail and took this grade; a third named its auditor and its scope unprompted and took a higher one. Ask for both reports with audit periods, auditors and certificate numbers, a penetration test summary, and a disclosure route that is not a support inbox.

A buyer can compute their own multi year contract on this page without speaking to anyone, which is the test this convention sets. Two tiers publish full annual prices at fifteen thousand and forty two thousand dollars, each stating the seats included at fifteen and thirty, the price of every seat beyond that at forty five and fifty dollars a month, and the artificial intelligence credit allowance at forty five thousand and one hundred and fifty thousand per year.

A live calculator takes a tier, a seat count and a contract length and returns the blended monthly and annual figure. The multi year ladder is published rather than negotiated in the dark, at fifteen, twenty five and forty percent off for two, three and four years, and the vendor states plainly that volume and term discounts stack and that the calculator already reflects both. Annual billing only is stated with the reason rather than discovered at contract.

A standalone scheduling product carries its own published rate and its two hundred seat minimum. A feature comparison runs to nine groups. Three qualifications belong on the record and none of them prevents a buyer budgeting the purchase. Credit consumption per agent action is not published and neither is the price of additional credit bundles, so overage exposure cannot be modelled.

The comparison table states that annual credit details are coming soon on every tier while the tier cards above it give specific allowances, which is the page contradicting itself. And the third tier is announced without a price. Ask what each agent action consumes and what a credit bundle costs.

The most complete exit position recorded in this index, and the first record here to take the top band on this axis. Four things combine, and each is published rather than implied. The vendor states that the customer owns the data and retains all right, title and interest in it. It states a post termination window, that during the subscription and for thirty days after it a customer may migrate their data at any time and for any reason.

It states that this requires no assistance from the vendor, which removes the gatekeeping that makes most export rights theoretical, since a customer who must ask is a customer who can be delayed. And it commits not to delete data within an account without informing the customer and giving them time to export it first.

Underneath sits an architectural point the vendor makes itself: the calendar and the customer record system remain the systems of record, so the operational history of every meeting booked and every lead routed already lives in platforms the customer owns and keeps regardless.

What is not stated is the shape of the export rather than the right to it: no format is named, and nothing enumerates whether routing rules, chat transcripts, funnel analytics, agent configuration and re-engagement flows are included or only the records. Thirty days is also short for a team rebuilding elsewhere. Ask what the export contains and in what format, and whether the window can be extended.

The platform sends on the customer's behalf and publishes nothing about how. Meeting invitations, confirmations, reminders, handoff correspondence and re-engagement sequences all leave through this product, and an email composition agent generates further correspondence, so mail volume attaches to the customer's domain by way of a system they do not administer.

Nothing published states which infrastructure sends, whether mail leaves from the customer's own connected mailbox or from vendor systems, who configures sender authentication records, what bounce or complaint handling applies, or whether any threshold pauses a flow. The exposure is structurally lower than for the outbound products in this cohort because most of the volume is transactional correspondence to someone who just requested a meeting, and recipients of that mail are expecting it.

The exception is the re-engagement flows, which are marketing mail to people who abandoned a form or missed a meeting, and those carry the ordinary reputational risk with none of the ordinary controls described. The spam checking capability that does exist runs on inbound form submissions rather than outbound sending, and should not be read as sending discipline. Ask which infrastructure sends, who owns the authentication records, and what bounce or complaint rate pauses a re-engagement flow.

The new tier structure is itself a market statement, and it moves the product materially upmarket in a way a returning buyer needs to notice. Seats are bundled rather than counted from one, at fifteen included in the entry tier and thirty in the upper, so the pricing assumes a revenue team of that size before a single additional seat is bought, and the entry commitment is fifteen thousand dollars a year.

Under the structure being replaced, a smaller team could buy a single module at a per user rate plus a platform fee starting in the low hundreds monthly, so a team of five had a viable path that no longer exists. The standalone scheduling product is not that path either, since it carries a two hundred seat minimum and is described as being for enterprise teams.

The result is a product that made its name with fast growing software companies and now addresses established revenue organisations, and the vendor is open about the transition rather than quiet, stating on the page that tiers are rolling out and that existing customers will be contacted. Named reference customers are consistent with that position. Multi language support in chat and contract terms running to four years both point the same way.

Held below the top band because two coverage questions go unanswered: no minimum inbound lead volume is stated at which the economics work, which is the number that actually decides fit for a scheduling product, and no geographic or industry coverage statement appears. Ask what monthly inbound volume the entry tier assumes, and what happens to a customer on the previous pricing at renewal.