Sluice

Stop paying for seats nobody uses

You are paying for seats
nobody is using.

Rippling knows who works here and what they were given. It does not know whether any of it is being used. Sluice joins those two halves, prices the gap, and reclaims the seat through Rippling — so the de-provisioning lands in the same audit log as the hire.

Read-only against every vendor. Sluice never revokes on the vendor side — only through Rippling.

Three moving parts

1

Read the employment record

Workers, status, termination dates, departments, and the application entitlements Rippling already holds. This half is always available and needs no vendor credential.

2

Ask the vendor what is used

Ten connectors read activity directly from the vendor, read-only. Where a vendor exposes nothing, Sluice says so on the finding rather than guessing.

3

Nudge, then reclaim

The holder is asked before anything is taken away. Revocation goes through Rippling's group exclusion, so the change is executed and recorded where the rest of their access lives.

What it finds

Still provisioned after leaving
A worker is terminated in Rippling and still holds the seat. Provable from Rippling alone — no vendor connection required, and the highest-confidence finding there is.
Belongs to nobody
A seat whose identity matches no worker at all. Usually a contractor, a shared login, or somebody who left before the integration existed.
Never activated
Provisioned and never once used. Only reported where the vendor can actually prove it — an unaccepted invitation, or a licence with no sign-in on record.
Dormant
No activity for 60 or 90 days. Sluice nudges the holder first and reclaims only after they confirm, or after an administrator decides.

What it will not do

Every tool in this category reports a number. The difference is whether you can act on it.

It will not invent a saving

Seven of the ten vendors have seats that cost nothing despite looking provisioned — Slack's fair billing, a free Zoom Basic licence, a Datadog account on a per-host contract, a Salesforce user already deactivated. Those findings still appear as an access risk, priced at zero. The recoverable total is money you can actually stop spending.

It will not guess at dormancy

Where a vendor exposes no activity data, the finding says so instead of inferring disuse. A revocation proposal built on a missing field is how somebody loses access they still need.

It will not act on its own

Auto-apply is off by default and, when enabled, is limited to findings that are provable from Rippling alone. Everything else waits for a person. The copilot stops at a preview and cannot complete a write.

It will not keep its own user list

Roles resolve from Rippling group membership on every request. Remove someone in Rippling and they lose Sluice immediately — a tool built to find orphaned accounts should not create one.

Vendors it reads

Some sources need an enterprise plan on the vendor's side. Sluice reports which, per connector, rather than failing quietly.

Pricing

Metered on seats under management, not headcount — so a customer who acts on the findings meters fewer seats next month. That is the whole shape of it: the better this works for you, the less it costs.

We price per deployment rather than publishing a rate card, because what this is worth depends on how many seats you are carrying and how much of the waste is recoverable. Tell us roughly how many people you have in Rippling and which vendors you pay for, and we will come back with a number and the reasoning behind it.

Ask for a price →

No per-user minimum, no charge for the people Sluice finds nothing wrong with.