Finance & ops

The customers about to leave over a card, not a decision.

#financepublic channel4 tool calls

Failed charges in the last week, joined to the subscription behind each and the account owner in the CRM — sorted by how close each is to the final retry, so the two calls worth making today are the first two lines.

Try it now Deploy it yourself Tools

financethread

Dan9:40 AM

@attest_tag anyone about to churn on a failed card?

attest_tagApp9:41 AM

http_request · GET api.stripe.com/v1/charges?limit=100 · 7 failed in 7d
http_request · GET api.stripe.com/v1/subscriptions?customer=… · 4 active
hubspot_search · companies · domain match · 4 owners
run_js · retries remaining, monthly value · sorted

Four at risk, two urgent.

Northwind Logistics — £1,000/mo, third failure, final retry Thursday. Card expired. Owner: Dan.
Ledgerly — £240/mo, final retry tomorrow, insufficient funds twice. Owner: Priya.
Two more on a first failure, retrying next week — worth watching, not calling.

I can draft each owner a note with the customer and the retry date, or open a task per account. Neither happens until you say so.

google/gemini-flash21k in560 out$0.011Configure

Names, figures, repositories and customers are changed; token counts and cost are illustrative. The ask, and the shape of the answer, are as they were.

How the turn went

Two connections, one join, and a list ordered by when it stops mattering.

01
A failed charge is not yet a lost customer
Each failure is traced to its subscription, because what matters is how many retries are left rather than how many have failed. The sort is by the date the subscription actually lapses, which is the only ordering that tells you who to ring first.
02
The owner comes from the CRM
Billing knows the customer; the CRM knows whose account it is. The two are joined on the company domain, and an account with no owner in the CRM is listed as having none rather than assigned to whoever looks likely.
03
It stops before doing anything about it
The reply offers the drafts and the tasks and then waits. A turn that reads four things and opens four tasks unasked is a turn nobody can trust with a fifth connection.

What it needs

The setup, in the console.

Connection

The Stripe preset with a read-only restricted key, and the HubSpot preset with a private-app token that can read companies. Either alone answers a smaller version of the question.

Credential

Both sealed in the database; the proxy injects them per request. Neither reaches the model, and neither appears in the audit trail beyond its name.

Writes policy

Nothing to hold here — both keys are read-only. Opening the tasks would be a separate, held write.

What it will not do

Enforced outside the model.

It cannot retry a charge, update a card or cancel a subscription; the billing key carries no write.
It will not guess an account owner. A company the CRM does not know is reported as unowned.

Try it

Say it in a channel it is in.

The sentence as it was typed. It works in any channel the bot has been invited to that carries the connection above — no command syntax, no form, and follow-ups in the thread need no mention.

@attest_tag anyone about to churn on a failed card?

http_request
hubspot_search
run_js

The month-end chores, done before the meeting.

Bring the channel this would live in.

Sign up, connect the service above in one channel, and type this sentence yourself — or run the same binary on your own infrastructure.

Try it now Deploy it yourself

All solutions