Signed Six Weeks Ago, Never Onboarded

The invoice went out on a Tuesday. Forty-two hundred dollars, annual, paid in full nine days later. The deal appears in every board deck since. The AE moved on to the next quarter, the founder mentioned the logo on a call with an investor, and the customer has, as far as anyone can tell, never logged in.

Nobody noticed for six weeks. Not because anyone was careless, but because noticing required someone to hold two facts in their head at the same time: that this deal closed, and that nothing happened afterward. The first fact lives in the CRM, where it is celebrated. The second fact is an absence, and absences do not show up on dashboards. There is no row in any table that says "this customer received no kickoff email". There is only the missing row where the kickoff email would have been.

At thirty people, this happens more than anyone admits. The AE closes and hands off in a Slack DM. The person receiving the handoff is on a plane, or in the middle of an escalation, or genuinely intends to get to it Thursday. Thursday becomes next week. The deal record still says Closed Won, which is true, and the onboarding stage field still says whatever it said when the opportunity was created, because nobody has touched it since. Three months later the customer does not renew and the renewal conversation is a surprise to everybody.

The instinct everyone has, and why it fails

The first thing a competent ops person does is add a field. Onboarding Status, with a picklist: Not Started, Kickoff Scheduled, Kickoff Done, Live, Stalled. Add a required-field rule. Add a report grouped by that field. Put the report on a dashboard. Send it weekly.

This works for a while, a month or two. Then it stops working, for a completely predictable reason: the field is maintained by the same person who is too busy to do the onboarding. The field is a promise about the work, and the work is the thing that is not happening. A customer nobody has onboarded is precisely the customer whose onboarding field nobody has updated. The field is stale in exactly the cases where you needed it to be accurate.

Everyone who has run ops at a small company knows this. Say the dashboard grouped by Onboarding Status shows four accounts stalled. That number is not wrong so much as incomplete. The four are the ones where somebody was conscientious enough to mark their own failure. The accounts you actually needed to find are still sitting at Kickoff Scheduled from a Tuesday in April.

So the field is not evidence. The field is a self-report. The question you actually want to ask is a question about systems that cannot lie, because they only record what physically occurred: an email was sent or it was not, a ticket exists or it does not, a session was logged or it was not.

What the question actually is

Stripped down, the question is this. For every account with a closed-won date more than fourteen days ago, what is the timestamp of the first real activity that involved that customer, anywhere, after the close? And if there is no such timestamp, say so loudly.

"Real activity" is doing a lot of work in that sentence, and it is worth being precise about what counts:

• An outbound email to someone at the customer's domain, from anyone on the team, that is not the invoice or the receipt.
• A calendar event with an attendee at that domain.
• A support ticket opened by or for that customer.
• A Slack message in the shared channel, if you run shared channels.
• Product activity: a login, an API call, a record created in your own database.

Notice what these have in common. Four of the five live in unstructured places. The email is a body of text with a subject line. The Slack message is a sentence a human typed. The ticket has a comment thread. Only the last one, product activity, lives in a table with a schema, and it is the one signal that is missing for exactly the accounts you care about, which makes it useless on its own. An account with zero product events looks identical to an account that has not been provisioned yet, an account in a pilot that starts next month, and an account that churned quietly.

The answer only means something when you join the CRM close date against the earliest signal from all five sources, and then look at the gap.

Why the tools you already pay for cannot do this

It is worth being fair here, because the reason is more specific than "BI tools are bad at things".

Your BI tool connects to sources it can model. Looker addresses SQL dialects. Metabase ships nineteen official drivers, and every one of them is a database. Power BI reaches further into SaaS connectors, and its Copilot will genuinely answer a question in natural language against a semantic model you have built. None of that is a limitation of the natural-language layer. The limitation is upstream. A Slack thread where the AE wrote "handing this one to Priya, she's got the kickoff" is not a modelled source. It is not a source at all. There is no dimension for it, no measure, no join key. The question is outside what the tool can see, and the natural-language layer does not change that, because it answers against the model, and the model contains what somebody put into it.

Internal-tools builders have a different shape of the same problem. Retool will generate a working app from a prompt, connect to your Postgres and your REST APIs, and let a human take write actions. That is real, and it is genuinely useful. But it builds against the sources you point it at, and the sources it is good at are the ones that return rows. "Show me accounts with no onboarding activity" is a question about the absence of records across five systems, three of which keep their evidence in prose. There is nothing to render and nothing to CRUD.

Zapier and Make are the third instinct, and they fail on a different axis. They are triggered, which means they run forward from an event. You can build a Zap that fires when a deal moves to Closed Won and posts a reminder. What you cannot do is ask about the deals that closed before you built the Zap. The question here is retrospective by nature: it is about what already happened while nobody was watching, and trigger-based automation structurally cannot look backwards.

Then there is the Airtable answer, which deserves its own paragraph because it is the one most small companies actually reach for. Somebody builds an onboarding tracker base. It is nicer than the CRM field. It has a kanban view, coloured statuses and an automation that pings Slack, and it works, in the sense that it is a genuinely good tracker. But look at what it costs. The base is now the system of record for onboarding, which means every account has to be entered into it, and every state change updated in it, by a person, on top of the CRM and the ticketing tool. You have solved a reporting problem by adding a data entry job. And the same failure returns in a new costume, because the account nobody onboarded is the account nobody added to the tracker.

Asking it instead

Skopx sits on top of the tools you already have. It connects to nearly 1,000 SaaS applications, including HubSpot, Salesforce, Gmail, Google Calendar, Slack, Zendesk and Linear, and it connects directly to Postgres, MySQL, MongoDB, Supabase, ClickHouse and Snowflake. Nothing moves. The CRM stays the CRM. Gmail stays Gmail.

The sentence someone would actually type, on a Monday morning, is close to this:

Build me a page showing every account that closed won more than 14 days ago, with the close date, the deal owner, the date of the first email we sent to anyone at that company's domain after the close, whether a support ticket exists, and the date of their first product session from our Postgres sessions table. Sort by days since close, longest first, and flag any account where all of those are empty.

That is not a query in any single system. It is a question that reads from four places and joins them on the customer, which is the entire reason nobody had asked it before. The join key is fuzzy in the way real work is fuzzy: the CRM knows the company, Gmail knows the recipient domain, Zendesk knows the requester's email, Postgres knows an org id. Making that join is the job, and it is the kind of job that reads sentences rather than rows.

Skopx turns that answer into a screen with its internal apps: it runs the query against what you have already connected, looks at the rows that come back, and renders a console shaped to fit them. A few counters at the top, a table underneath, a chart when the shape of the data warrants one.

What the console looks like

For this question, it lands somewhere close to this.

A row of counters. Accounts closed more than fourteen days ago. Of those, how many have zero signals of any kind. Total contract value sitting in that zero-signal group, which is the number that makes people move.

A bar chart of days since close, bucketed. Fourteen to thirty, thirty-one to sixty, over sixty. The over-sixty bar is the one nobody wants to look at.

A table, one row per account: company, close date, days elapsed, owner, first outbound email date, first ticket, first session, and a plain status derived from all of it. Not a field somebody maintains, but a conclusion drawn fresh every time the page loads, from what the systems recorded.

And on each row that has been silent past a threshold, a button. One button, one action, clicked by a person, with a confirmation before it fires. Post the account into the #customer-success channel with the close date and the elapsed days. Or open a Linear issue assigned to the owner. Or send the kickoff email that should have gone out five weeks ago. The button does exactly one thing in one connected tool, and only when someone presses it. Nothing runs on its own, nothing is scheduled, and nothing is written back into the CRM behind anyone's back.

The honest limits

An internal app in Skopx reads and it acts. It does not store. There is no new table here, no form, no record you are creating in Skopx. The page persists as a question you can reopen, but it holds nothing of its own, because the whole premise is that state lives in the systems that already have it. If you want a permanent onboarding stage owned by a human, you still want that field in your CRM. This console tells you when the field is lying, which is a different and more useful job.

It does not watch. Nothing wakes up at 8am and tells you an account has gone quiet, because nothing runs unless a person opens the page or presses a button. In practice that means putting it in a Monday routine alongside pipeline review, which is where it belongs anyway.

The SQL it runs against your own database is read-only, by design. The only write path is a button somebody presses.

And the join is only as good as the data underneath. If your CRM has the company as "Acme" and their people email from acmecorp.io, that link has to be inferrable from something. Usually it is: the contact records carry the domain. Sometimes it is not, and the honest answer is that a handful of accounts will need a human to confirm the match. That is a smaller job than maintaining a tracker.

The point

The reason this question goes unasked for six weeks is not that it is hard. It is that answering it requires holding a CRM tab, an inbox, a ticket queue and a database next to each other, and nobody has time to do that on a Monday before standup. So instead a field gets added, and the field gets trusted, and the field is stale exactly where it matters.

Ask systems that cannot lie. An email was sent or it was not. That is the whole method.