Ordinatus is the back-office for companies selling paid, scheduled support sessions. Customer submits a request → it routes only to qualified engineers → first one available claims it → customer books a slot and pays at checkout, through your own Stripe/Shopify. No admin dispatching, no invoice chasing, no no-show risk. Calendar invites, reminders, and per-engineer payout splits happen automatically. Your processor, your customer relationship — we never touch the money or take a cut.
No reviews yetBe the first to leave a review for Ordinatus
Maker
📌
Hey everyone 👋
I built the first version of this for a client who had engineers fighting over a shared calendar every time a paid support request came in - whoever saw it first grabbed it, someone else double-booked the same slot, and the customer paid... eventually, sometimes, after a few email chases.
I figured that was a one-off integration job. Then a second, unrelated client described almost the exact same problem: multiple people in the office, one queue of paid requests, no clean way for someone to just claim one without stepping on a teammate or waiting on an admin to assign it.
Two different businesses hitting the same wall made me think it's not a one-off. So I generalized it into Ordinatus: customer submits a request, it routes to whoever's actually qualified and available, first one to claim it owns it, and payment is collected at booking through your own Stripe/Shopify/etc - not chased down after the session.
Still early and I'm building it in the open. If "who gets this one" is a fight your team has every week, I'd love to hear how you're handling it today.
Report
Maker
How routing decides who sees a request
A quick deep-dive on the Skills and Routing setup, since a few of you asked how the matching actually works.
Every team member gets assigned Skills. Skills control which requests they can see and claim.
When you build a Form, you can attach a skill to individual answer options. Say you run a home services company and your intake form asks "What do you need help with?" with options Plumbing, Electrical, and HVAC. Make each option its own skill. A customer who picks Plumbing is only visible to your plumbers. Electrical goes to your electricians, HVAC to your HVAC techs. One form, sorted automatically.
If a question lets customers pick more than one option at once, a team member with any one of those skills is eligible.
The Default Skill is a floor, not a fallback. Each Form also has an optional Default Skill, and this one is additive: it applies to every request off the form, on top of any option skills. So if you set Default to "Licensed" and tag your options, a plumbing request needs someone who is both Licensed and a plumber. That is the point: a baseline everyone must clear, plus the specialty. If you want the option to fully decide routing on its own (the clean Plumbing-to-plumbers story above), leave the Default Skill empty and tag only the options.
One thing to watch when you set this up: if a customer picks an option that no active team member has the skill for, the request is not lost, but it will not auto-notify a specialist, because none exists. It stays open, and any admin can see and assign it from the dashboard. The fix is simple: make sure every skill you attach to a form option is held by at least one active team member.
How routing decides who sees a request
A quick deep-dive on the Skills and Routing setup, since a few of you asked how the matching actually works.
Every team member gets assigned Skills. Skills control which requests they can see and claim.
When you build a Form, you can attach a skill to individual answer options. Say you run a home services company and your intake form asks "What do you need help with?" with options Plumbing, Electrical, and HVAC. Make each option its own skill. A customer who picks Plumbing is only visible to your plumbers. Electrical goes to your electricians, HVAC to your HVAC techs. One form, sorted automatically.
If a question lets customers pick more than one option at once, a team member with any one of those skills is eligible.
The Default Skill is a floor, not a fallback. Each Form also has an optional Default Skill, and this one is additive: it applies to every request off the form, on top of any option skills. So if you set Default to "Licensed" and tag your options, a plumbing request needs someone who is both Licensed and a plumber. That is the point: a baseline everyone must clear, plus the specialty. If you want the option to fully decide routing on its own (the clean Plumbing-to-plumbers story above), leave the Default Skill empty and tag only the options.
One thing to watch when you set this up: if a customer picks an option that no active team member has the skill for, the request is not lost, but it will not auto-notify a specialist, because none exists. It stays open, and any admin can see and assign it from the dashboard. The fix is simple: make sure every skill you attach to a form option is held by at least one active team member.