Under the hood
How Sploot works
The front page says “just say @sploot.” This page is what happens between the mention and the receipt: what a plan is, who approves it, what starts an automation, what a loop does with a bad row, and what gets logged. Nothing here is automatic without being visible first.
a mention in · a plan, an approval and a receipt out
The thesis
Why show the plan first?
One rule drives the whole design: you see what will run before it runs. Everything on this page follows from it.
- You should not have to break a job into steps to ask for it. Say the whole thing in plain words, in the channel where the work already happens, and Sploot works out the steps.
- Nothing should run until you have seen what will run. Sploot drafts the plan first and shows every step, and if a step is wrong you change it before you say yes.
- The ask you make once is often the ask you make every week. A plan can become a standing automation, on a schedule or on a trigger, without being asked for twice.
- Big decisions belong to a person. You pick who signs off on what, and Sploot gathers the context they need before it asks them.
- An exception explained once should stay explained. Sploot picks up how your company works as it goes.
- Every run leaves a receipt: what ran, who asked, and who approved it.
One ask
What happens after you ask?
One ask, start to finish. Each step is visible in the thread, and nothing moves to the next one until a person says so.
Ask
Mention @sploot in Slack, in the channel where the work already happens, and say the whole job in plain words.
- There is no flow to build first. Ask for the whole job and Sploot breaks it into steps and works out the logic.
- It works with the apps you already use: Stripe, Gmail, HubSpot, Notion and more.
- Sploot lives in Slack. The plan comes back in the thread you asked in.
Plan
The job comes back as a plan, one step per action in one of your apps, shown in the thread.
- Every step it will take is shown before it acts on anything.
- The plan waits there for approval. If a step is wrong, change it before you say yes.
Review
Teammates can suggest changes on the thread before anything runs.
- A teammate suggests the change and Sploot keeps every version of the plan.
- The team compares the versions and approves one.
Sign-off
A big decision waits for the people you named.
- Sign-off is set per decision, so a large refund can wait on a manager, or on more than one person.
- Sploot gathers the context they need to decide and asks them. Nothing runs until they answer.
Run
Once approved, Sploot carries the plan out across your connected apps.
- Every run happens in its own sandbox, walled off from your other systems.
- Run a plan across a whole list and it flags the items that need a second look, like an account with no billing email, instead of running blind.
Receipt
Every run leaves a receipt.
- What ran, who asked for it, and who approved it. Every action Sploot takes is logged.
- Tell Sploot about an exception, say a processing fee that is never refunded, and it carries that into later runs rather than asking again.
Signals
What does Sploot make of what you say?
The phrasings from the front page and what each one becomes. The rule is the one from the hero: ask in plain words, and Sploot works out the steps.
- refund Acme’s last charge and email them a receipt
- a plan · Stripe, then Gmail
- every Monday at 9:00 AM, post unpaid invoices in #finance
- a standing automation · on a schedule
- the moment a deal closes
- a standing automation · on a trigger
- for every account renewing in October, send the renewal notice
- a loop · one run per item
- an account with no billing email
- flagged for a second look · the rest keep going
- a refund big enough to need a manager
- waits for sign-off · from whoever you named
- a teammate’s edit on the thread
- a new version · every one kept
- the $2 processing fee is non-refundable
- kept for later runs · explained once
Automations
What runs without you watching?
Ask once and say when. The same plan can run on a schedule, on a trigger, or once for every item in a list.
- A one-off ask runs once, after you approve it.
- Say when and it keeps happening: every Monday at nine, or the first of the month, and the same plan runs again each time.
- Say the moment a deal closes and it runs when that happens.
- Run one plan across every item in a list. Sploot marks the items that need a second look, an account with no billing email for instance, and keeps going with the rest.
Control
What if the plan is wrong?
The plan is a draft until someone says yes. Here is who gets a say, and where.
- Change a step before you say yes. Sploot drafts the plan first and nothing runs until you approve it.
- A teammate suggests a change on the thread. Every version is kept, so the team can compare them and approve one.
- You pick who signs off on what, per decision, so a large refund can wait on a manager or on more than one person.
- A loop flags the items it cannot handle and keeps going with the rest, so you look at the flagged ones rather than the whole list.
Trust
What is the security model?
The section to forward to whoever has to say yes. Every claim here is also on the front page.
- Every run happens in its own sandbox, walled off from your other systems.
- Your data is never used to train a model, ours or anyone else’s.
- Sploot picking up your exceptions is not the same as training on your data. It never does that.
- Nothing runs until someone approves it, and sign-off for a big decision goes to the people you named.
- Every action Sploot takes is logged: what ran, who asked for it, and who approved it.
Afterwards
What does Sploot keep?
A run is over in minutes. These are the things that stay.
- A receipt for every run: what ran, who asked, who approved it.
- Every version of a plan, so the team can compare them before deciding.
- The exceptions you explained. An exception you explain today is one Sploot already knows next time.
- A standing automation, once approved, keeps running on its schedule or its trigger.
Scope
Where does Sploot stop?
The honest half of the pitch. Knowing where a tool stops is how you trust where it starts.
- It does not act before approval. A plan is drafted and shown first, every time.
- It does not train on your data, for its own models or anyone else’s.
- It lives in Slack. You ask in the channel where the work already happens, and the plan comes back in that thread.
- It is not open yet. Sploot is in private beta, and there is nothing to log into today.
Questions
The follow-up questions.
What people ask once they have read this far: what a plan is, what starts an automation, what a loop does with a bad row, and who can sign off.
What actually happens after I ask?
The job comes back as a plan, one step per action in one of your apps, shown in the thread. It waits there for approval. Once you approve, it runs the steps and logs a receipt for the run.
Do I have to build a flow first?
No. Ask for the whole job in plain words and Sploot breaks it into steps and works out the logic. You review the plan it comes back with.
What can start an automation?
A time or an event. Say every Monday at nine, or say the moment a deal closes, and the same plan runs again each time it happens.
What does a loop do with an item it can't handle?
Flags it and keeps going with the rest. Run one plan across a whole list and Sploot marks the items that need a second look, an account with no billing email for instance, rather than running blind.
Who can sign off on a step?
Whoever you say. Sign-off is set per decision, so a large refund can wait on a manager, or on more than one person. Sploot gathers the context they need and asks them, and nothing runs until they answer.
Can a teammate change a plan before it runs?
Yes, on the thread. A teammate suggests the change, Sploot keeps every version, and the team compares them and approves one.
What does "explain it once" mean in practice?
Tell Sploot about an exception, say a processing fee that is never refunded, and it carries that into later runs. It picks up how your company works as it goes rather than asking again.
Is that the same as training on our data?
No. Sploot picking up your exceptions is not the same as training a model on your data, which it never does, for its own models or anyone else's.
How is a run kept apart from everything else?
Every run happens in its own sandbox, walled off from your other systems. Every action it takes there is logged: what ran, who asked, and who approved it.
Does it work outside Slack?
Sploot lives in Slack. You ask in the channel where the work already happens, and the plan comes back in that thread.
Something missing? hello@sploot.sh
Convinced enough to try it?
Private beta, soon. Leave your email and you'll be in the first group we let in.
One email when it's live. Nothing else, ever.