September 18, 2026

Enrichment: what the outside world says about an account

Admin

Settings → Data → Enrichment is a third place a profile property can come from. Profiles reads your own tables, Usage measures what people do in your product, and enrichment looks up what exists outside your database entirely — whether their store is live, what it's built on, how much they sell, how long their domain has existed, whether that signup address is a throwaway.

You turn on a probe — one lookup — not its individual properties, because one read of someone's homepage answers six questions at once and paying six times for it would be the obvious wrong turn. Four ship today: Email shape and Domain record (free — they read public records), Site read and Social profile (about a cent per profile). Each probe's card lists exactly what it produces.

Whatever a probe finds lands as an ordinary property. Your rules filter on it, your scoring models take it as a factor, your funnel entry criteria read it. is_disposable and name_plausibility belong on a fit model; product_count_band and follower_count on a size model. They appear in the scoring editor's property picker like any other key, with nothing extra to wire.

Coverage tells you which signup question is worth adding

Admin

Under every probe is the number that matters more than any vendor's: how many of your accounts it can even run on. "Runs on 8,200 of 12,000 profiles (68%)" — or, more usefully, "you don't have a property for this yet; ask for it at signup and this probe becomes useful for everyone."

No lookup can tell you about a customer you have nothing to look up, so if most of your accounts carry only an email address, the highest-leverage change isn't buying data — it's one more question on your signup form. That line works before you turn a single probe on.

Each probe is pointed at one of your own properties — "where their project lives" → your store_url — on the probe's own card, so there's no mapping screen to configure before you can see why it matters. Keep both a store URL and a portfolio URL and you can point different probes at each.

Ask your own question about an account

Admin

When the catalogue doesn't cover it, write the question yourself: "is this an agency, a freelancer, or an in-house team?" It's answered by reading the pages you point it at, and five things keep the answer usable as data: a declared answer type (yes/no, one of a list, a number, a few words — never free prose), a declared input, evidence (the pages it actually read, shown beside the value — no citation means no answer), a confidence floor (below it you get "no result", not a hedge stored as fact), and a preview on five real profiles with the answer, the evidence and what it actually cost, before you save.

"Unknown" is always available on a list question and is always a real answer: an account whose site doesn't say is a different thing from one nobody has looked at.

Enrichment spend has a ceiling, and a wrong value can be corrected

Admin

Set a monthly ceiling under Spend. When the month's spend reaches it the queue pauses — nothing further is charged, and the work that didn't run stays queued rather than being dropped. Before you enable anything, the card shows the estimate and the question preview shows what five real calls cost, which is the more honest number.

Cost stays down on its own two ways: each probe caches its answer until it goes stale on its own schedule (a domain's registration date never moves; a follower count does), and a dead end — a domain that doesn't resolve, a site that's gone — is recorded as "no result" and left alone for months instead of being re-checked every cycle. You can also narrow an expensive probe to the accounts that matter with the same rule builder the rest of the lifecycle uses.

Each profile gains a Looked up card showing what was found, when, what it cost and the pages it came from, plus Enrich now. If a value is wrong, correct it by hand like any other property — the correction wins and no future lookup overwrites it.

Funnels say why an enrollment left, and can time one out

Admin

An enrollment that ends without converting now carries a typed reason, and each reason has a class. Left the stage (the account went dormant, say) and no longer matched the entry criteria are benign — the funnel correctly stopped bothering someone; until now the second was folded into the first. Funnel archived and removed by hand are neutral. Timed out is diagnostic: the enrollment ran out the funnel's new Max duration (days) without converting, which is the funnel's own signal that it is not working. Set the duration under Edit funnel → Outcomes; leave it empty for no limit. The same card carries Exit when the monitor resolves, which monitors now read.

The funnel Overview gains a Why enrollments left panel — every exit in the window by reason, with its class and share — and the profile page names the reason beside each exited enrollment. Changing either outcome field creates a new funnel version, like a change to the steps.

Monitors: the engine that watches for something being wrong

Admin

A funnel drives an account toward the next stage. A monitor watches for a condition being true of an account — an import failing, a card expiring in nine days, nobody seen for a fortnight, usage down against the account's own baseline. It trips when the condition has held for as long as you say, resolves when it stops holding, and can trip again later. The rule of thumb: you want your funnels full and your monitors empty.

The engine is live now: monitors evaluate in the same cycle as everything else — Settings → Data → Lifecycle → Evaluation history shows a new Monitors pass — and trips land on the profile timeline beside the threshold crossings. Every workspace starts with three, and all three start in observe, where they record what they would have caught and raise nothing: Gone quiet (nobody seen for 14 days), Never invited anyone (still a single seat a week after signup, Activation only) and Usage down against baseline (this week under 40% of the account's own 30-day run rate, Retention and Expansion). They read the same property keys the funnel and scoring templates do, so declaring those keys lights them up with no extra work.

See Monitors for the screens, and the entry below for what landed with them.

Monitors have their own screens

Admin

Monitors is now an entry in the Lifecycle sidebar, beside the four stages rather than inside one. The index is one flat list — type, scope, severity, status, open trips and trips in the window — with filters on status and scope, and the usual 30/90/180/365-day window applied to when a trip opened. An observing monitor's window column reads "N would have been caught".

A monitor's own page carries incidence, time to resolve, repeat trippers and open now, then the trips themselves: open first, with the values the condition read when each one opened, and any fan-out incidents underneath. Promote to active, Pause, Resume, Archive and — for a monitor that never tripped — Delete are all on that page.

New monitor starts from one of the shipped templates or blank, and the editor is the guided builder funnels already use, extended with the two shapes monitors need: Date coming up (a stored date falls within the next N days) and Against a baseline (one property over another, scaled, compared to a number — "this week under 40% of the account's own 30-day run rate"). Beside the condition: stage scope, dwell, severity, fan-out threshold and status. Run preview is a dry run of the next cycle under the draft — how many accounts would be tripped, are holding out the dwell, are fine, or match but are out of scope — writing nothing. Saving a changed condition, dwell or scope bumps the version and re-evaluates every account, restarting any part-way dwell; a rename or a severity change does not.

A profile with open trips now shows an Open trips card above its enrollments, and its timeline names the monitor on each A monitor tripped / A monitor resolved row — with how long it was open, and labelled when the monitor was only observing. Creating, editing and promoting monitors is admin-only; every member can read them.

Funnels can enter on a monitor, and leave when it resolves

Admin

Edit funnel → the entry criteria and any step rule now offer a Monitor condition: "monitor X is tripped" (optionally open for at least N days, or has tripped at least N times) or "is not tripped". That is how you write a funnel that should only start when something has been wrong for a while, rather than on a single bad reading.

A monitor still in observe is offered in the picker and labelled so — it reads as never tripped until you promote it, so nothing enrolls by surprise. When an enrollment entered on a trip and that trip closes, the enrollment exits Monitor resolved (a benign outcome on the Why enrollments left panel) if the funnel's Exit when the monitor resolves is on. Dunning wants that on: the card is fixed, stop. An expansion funnel wants it off: the resolution is the completion.

The Activation and Reactivation stage pages show a stage conversion rate

Admin

A funnel's conversion counts the enrollments its entry criteria admitted. The stage page for Activation and Reactivation — the one with the funnel list, reached from the breadcrumb — now shows Stage conversion: every account that entered the stage in the window and how many reached where it leads, whatever funnel carried them. For Activation that is signups in the window and the share that activated; for Reactivation, accounts that churned or went dormant in the window and the share that came back. It is the business number beside the program number. Retention and Expansion have no end state and so no stage conversion.

Intent is now Momentum, and every funnel has its own

Admin

The score that describes how a signup is moving through a funnel is now called Momentum. It measures the same three things it always did — how far through the funnel's required steps, how fast against the expected days, and whether the account is still moving — and "intent" never described that. High fit and low momentum is the corner to work.

Every funnel now has exactly one momentum model, created with the funnel whether you start from a template or blank, and it always drives the quadrant's y axis, the second score column on the List and the order of cards on the Board. A funnel can no longer be without one, and the Create from the Activation intent template shortcut is gone because there is nothing left to create. Funnels that already existed get theirs on the next evaluation.

The model lives with the funnel rather than under Settings. Edit funnel → Scores now has one picker — the x axis, from your profile models — beside a card naming the funnel's momentum model with its version and an Edit momentum model link. That opens the same editor as any scoring model, under the funnel: factors, weights, bands, a preview, and save-and-recompute. A momentum model cannot be duplicated or deleted on its own; archive or delete the funnel, or pause the model.

Settings → Data → Scoring is now profile models only — fit, size, engagement and risk — and the New model form offers those four categories and no funnel picker. Existing shipped models are renamed from Activation intent to Momentum; a model you renamed keeps its name.

The Retention and Expansion pages are now "overviews"

Admin

The two Lifecycle stages that are not funnels — Retention and Expansion — were described as monitors in the docs and in a few hints in the admin. They are now stage overviews. Nothing on either page changed; the word was freed for monitors, which are a different thing entirely. The docs page moved to Retention and expansion overviews and the old address redirects.

The Overview shows your lifecycle, not a shop

Admin

The workspace Overview no longer shows placeholder sales figures. It now reads from your synced profiles: how many there are, how many are Active, Dormant and Churned, how many data sources are connected, and when the last sync finished — stamped "as of" the last sync like every other page. Underneath, the four lifecycle stages are listed with a one-line description each and open straight into their funnel or stage overview. A workspace with no data source yet opens with a Connect a data source prompt instead of empty numbers.

The commerce entries leave the sidebar

Admin

Orders, Catalog, Customers, Discounts, the Channels group (Storefronts, Inventory routing, Point of sale) and the Insights group (Analytics) were inherited scaffolding that opened onto empty pages, and the product catalog behind Catalog was a worked example rather than part of Uptend. All of them are removed, along with their routes. The sidebar is now Overview, Profiles, the four Lifecycle stages and Settings. The corresponding View / Manage orders, products, customers, inventory and View analytics permissions are gone from the role matrix and from OAuth consent; the Profiles and Lifecycle permissions now carry their own labels there.

⌘K reaches every stage and settings page

Admin

The Go to group in quick search now lists the four lifecycle stages and the Data sources, Usage, Lifecycle and Scoring settings pages beside the entries it already had, and the product results group is gone.

Products are removed from the API, SDK and MCP server

API

GET, POST /v1/products and GET, PATCH, DELETE /v1/products/{productId} are removed, together with the Product schema, the products tag, the listProducts / getProduct / createProduct / updateProduct / deleteProduct SDK functions and the products MCP toolset. /v1/search no longer accepts or returns a product type; its results carry workspaces only. The workspace:orders, workspace:products, workspace:customers, workspace:inventory and workspace:analytics scopes are no longer issued or accepted — the workspace scope vocabulary is now settings, developer, members, data-sources, profiles and lifecycle, each :read and :write.

Webhooks subscribe to lifecycle.evaluated

API

The product.created, product.updated and product.deleted webhook event types are removed. The catalog now carries lifecycle.evaluated — sent once per evaluation cycle after lifecycle states, monitors, funnel enrollments and scores are recomputed — with a workspace subject that resolves at GET /v1/workspaces/{id}. Its payload gains a monitors summary (monitors evaluated, trips opened and resolved, incidents opened), null until that pass succeeds. The product.created notification type is removed from notification preferences as well.