Checkout questions still arrive without the payment event that caused them. Zens is publishing a product-event layer so a support thread can carry checkout, payment-failure, and activation marks next to the visitor, instead of a blank chat that asks the customer to reconstruct the bill.

The first-release note is the timeline, not another greeting. A polished draft that cannot name the failed invoice still invents a retry. The workspace already knew how to attach plan and page. The news is that a named product event can sit on that same record before anyone clicks send.

Payment Threads Arrive Without The Failed Invoice

A billing owner on a pricing page can ask whether the last charge went through, then still get a reply that talks about seats. The useful fact lived one hop away: a declined card, an invoice id, a checkout that started and never finished. The agent never saw it. The customer already paid for that description in the product itself. Support then spends the same-day cycle asking for a screenshot of a screen the product already recorded.

Older live-chat stacks store the sentence. They rarely store the event that made the sentence necessary. The first version of the answer looked fine until finance opened the invoice and could not defend the named plan against the failed charge. That single miss would never clear a billing review, and the same-day cycle then becomes an apology instead of a close.

The launch is aimed at that hole. If the event never lands, the identity graph is still a profile card. The thread looks complete and still cannot defend a billing line.

Track Puts Risk Events On The Same Record

The published integration adds a track call for events that show intent, confusion, or risk. The company names the usual set for a SaaS desk: activation, checkout, payment failures, invitations, plan changes, and support-heavy features. Those marks turn the conversation into a scanable timeline instead of a transcript pile.

Zens AI treats the event as product state that helps a human reply, not as a marketing pixel. Plan, role, lifecycle stage, seat count, or feature name are the kind of properties the guide keeps. A password, an access token, a full card number, a private key, or a government id is the kind it tells teams to leave out.

Checkout Payment And Activation Are The First Three

The public examples are narrow on purpose. One call can mark checkout started with a plan and a seat count. Another can mark payment failed with a decline reason and an invoice id. A third can mark activation completed with the milestone the product already uses, such as a first project created.

Those three are enough to test the first-release claim. If a payment-failed event exists and the draft still invents a new billing rule, the knowledge is thin and the send should wait. If the event is absent, the draft should ask which invoice, not invent one. A sentence that invents a second retry path after the decline mark is already on the record should be discarded before a customer sees it.

On a live-ops desk, the check is visual. Open the thread next to the original checkout screen. If the invoice id in the event and the invoice named in the draft do not match, the packet is unreadable as evidence, even when the tone is warm.

Small Properties Beat A Full Card Dump

The event layer is useful only if the properties stay small. A support lead needs the decline reason. A support lead does not need the card PAN sitting in the same payload. The published rule is blunt: send the product state that helps a reply, and stop there.

That stop is the cost control. One extra field that an agent would never use becomes a retention problem the moment the thread is copied into another tool. The first-release note is not �track everything.� It is a short list a reviewer can read without opening a legal hold.

Passwords And Card Data Stay Out

The banned set is named: passwords, access tokens, full payment card data, private keys, government ids, and sensitive health, financial, or legal records. A team that cannot keep those fields out of track should not turn the event layer on for production checkout.

Anonymous browsing and verified identity stay separate around those events. A visit becomes account-aware only after the backend signs a stable user id. Until that signature exists, an event can still mark a page. It cannot pretend the visitor is the billing owner.

Launch Proof Is A Pending To Active Flip

Shipping the snippet is not the proof. The published checklist starts with a network request to the support track route, then a site status change from pending to active. If that flip never happens, the events are not arriving, and the inbox is still guessing.

The same checklist asks for a page loaded with campaign parameters so source attribution appears, a login that calls identify, and a visitor profile that shows email, account, plan, registration time, and lifecycle stage. A test message has to land in the workspace. Switching accounts has to update the profile. Production, staging, and localhost are tested as separate sites when the domains differ. A site that only wants analytics without a visible button can keep the widget off and still fire the same track calls; a custom take-over control can still call the published handoff method. Neither change replaces the pending-to-active flip.

Origin Mismatch Keeps The Site Pending

If identify fails with an invalid identity signature, the backend signed a different user id than the browser sent, used the wrong signing secret, or returned a hash that was not lowercase hex. If tracking fails with an origin error, the domain registered in the workspace does not match the browser origin that fired the call.

Those two failures are the boring launch bugs. They wasted an afternoon of �the widget is up� while the site stayed pending. Zens AI is only doing the announced job if the site can leave pending and the failed invoice can appear on the thread that asked about it.

Desks That Can Name The Failed Invoice

The event layer is for a support or success desk that already knows which product marks belong on a customer thread, and that can keep card data out of the payload. It is the wrong first buy for a site that only wants a night FAQ and has no checkout or activation event it is allowed to send.

Zens AI is available now with that timeline as the first-release note. Keep the first week small: one site, one payment-failed event, one question that should force the draft to name the invoice. If the reply still talks about seats after that mark exists, the knowledge is thin. If it names the decline, the event layer is doing the job the announcement described.

Media and buyers can ask to see the three events on a live thread in any demo that follows. The send button still belongs to a person.