Onboarding orchestration
A process that cannot lose its place.
Onboarding that takes six weeks and touches a dozen people across three companies is not a form. It is a long-running process that has to survive waiting, chasing, restarts and people going on holiday.
The engine behind our own onboarding, available without the finance products on top.
The problem
Nothing fails. It just stops.
Ask an operations lead where a stalled case is and you get a person's name, not a status. It is in someone's inbox, or waiting on a document that was requested three weeks ago by someone who has since moved teams, or blocked on an approval nobody realised was needed.
The reason is that most onboarding runs on tools built for short interactions. A form submits. A ticket closes. A scheduled job either completed or it did not. None of them are built to wait three days for a customer, send a reminder, and then resume exactly where they stopped, a thousand times, without dropping one.
That waiting is the actual work. So the engine is built around it: every step has an owner and a clock, the process survives restarts and failed integrations, and the answer to where is it is a screen rather than a person's recollection.
- The process holds its own state, not someone's inbox
- Deadlines run on business hours and local holidays
- Automated steps are tasks too, so nothing happens invisibly
How it works
Design once. Every case walks it.
Three altitudes on one spine, which is what keeps the process on the whiteboard and the case in front of you from disagreeing.
- 01
Lay out the process
Stages in order, each with an owner, a deadline, what gates it and what it produces. Different client types, countries and partners get different routes through it. This is configuration, so operations change it without waiting for a release.
- 02
Cases walk the version they started on
A case keeps the process it began with even after the template changes underneath it. Nothing in flight is disturbed by an edit, which is what makes people willing to edit.
- 03
Work arrives as tasks
Each stage becomes a task with an owner, a deadline and the screen needed to finish it, routed to a queue or a named person. Automated steps are tasks as well, with the system's result recorded on them.
- 04
Evidence sticks to decisions
Documents, extracted fields and external check results attach to the task that produced them. A decision carries a reason, an author and a timestamp, so the case explains itself later.
What the engine gives you
- Weeks long
- Processes that wait on people and survive doing so
- Per case versioning
- Live cases keep the process they started on
- Business hours
- SLA clocks that know your week and your holidays
- Row level
- Tenant isolation enforced by the database
Stages are arranged from a catalogue of step types. Conditional branching beyond stage gating and parallel batches is a development change, not configuration, and we will tell you which side of that line your process falls on.
What you configure
Yours to change, without a release.
These are the things operations can alter directly. Being honest about the boundary matters more than claiming there isn't one.
- 01 Stages and order
- Which steps exist, what sequence they run in, and which run concurrently as a batch.
- 02 Owners and queues
- Who picks a step up: a named person, a team queue, or a system. Reassignment and escalation included.
- 03 Deadlines and escalation
- How long each step may take, measured in business hours per region, and who hears about it when it does not.
- 04 Gates
- What has to be true before the next stage opens: a document approved, a check returned, an external signal received, a person's sign-off.
- 05 Document requirements
- What each client type in each jurisdiction must provide, and when a document is too old to rely on.
- 06 Roles and visibility
- Permission bundles by role, so operations, credit, the client and a partner each see only their slice of the same case.
Questions
The questions that decide fit.
Is this a BPM tool?
No, and we would rather say so than let you find out in month three. There is no visual branching designer, no expression language and no user-defined record types. You arrange a catalogue of step types into a process.
Can we use it for something other than trade finance?
The engine is domain-neutral: stages, tasks, gates, evidence, SLAs. The domain records around it are not. For a different vertical we would be adding the record types, which is real work, and the honest conversation is about how much.
What happens to a case when we change the process?
Nothing. Live cases keep a frozen copy of the process they started on, and new cases pick up the new version. That is deliberate: a team that fears breaking live cases never improves the process.
How does it handle an integration that fails?
It retries with backoff, and the step stays open with its history rather than the case dying. A bureau that times out is a retried step, not a dropped case. A person who does not respond gets reminded without anyone noticing they had not.
Can it drive our existing UI?
Yes. Everything is behind an API, so the engine can sit under a front end you already own while your team keeps working in the task queues.
How is it priced?
Per tenant plus per active case. Not per seat, because seat pricing punishes you for putting the whole operations team in the tool, which is exactly where the value is.
Next
Bring your worst process.
The one with six handoffs and a spreadsheet holding it together. Forty-five minutes, laid out as stages, owners and gates, with an honest answer on what would need building.
- Mapped against your own process, not a demo
- A clear line between configuration and development
- Named gaps rather than a feature list