Speedoz
By AIGEO Insights
Turn an AI request into a confirmed booking
Speedoz connects assistants to the booking and CRM systems you already use. Every action is scoped, approved and logged, so customers can act without your systems being exposed.
Worked booking workflow
One request. One confirmed appointment.
A bounded example showing the two actions a clinic approves and the outcome the customer sees.
Without a connector
Can you book me in with Bli Bli Physio on Thursday afternoon?
I can see Bli Bli Physio in Queensland. I am not able to check their availability or make a booking. You can call them on 07 5448 XXXX or use the contact form on their site.
The customer opens a new tab, gets distracted, or books with whoever answers first.
With Speedoz
Can you book me in with Bli Bli Physio on Thursday afternoon?
They have 2pm and 4:15pm free on Thursday. I have held the 2pm under your name and emailed you the confirmation. Reference BBP-4192.
check_availabilitycreate_bookingthe two actions the clinic approved
Why this comes up
Why service businesses call us
Nobody arrives asking for a protocol. They arrive because of one of these.
A customer tried to book through ChatGPT and could not
The model knew who you were, described you well, then hit a wall. It could give out your phone number and nothing else, so the customer rang whoever was reachable.
A competitor got there first
When one business in a category becomes callable, the assistant starts routing to it. Being described accurately stops mattering as much as being the one that can be actioned.
Your team answers the same question fifty times a week
Opening hours, availability, order status, stock. Every one is a lookup a machine could do, and every one costs a person ten minutes.
Your product data never reaches the answer
Prices, service areas and availability sit behind a login. A model cannot read them, so it guesses or omits you.
What it actually is
A safe doorway between an assistant and your system
There is a standard for this, called MCP. It is the way assistants like Claude and ChatGPT call outside tools. You do not need to know anything more about it than that, because we build and run that part.
You decide what it can do
You approve a short list of actions. Check availability, yes. Delete a record, no. The assistant cannot ask for anything outside that list.
You can see every call
Which agent asked, what it asked for, whether it was allowed, how long it took. Nothing happens invisibly.
Your system does not change
We sit in front of your existing API. No migration, no rewrite, no plugin inside your software.
What we connect
If your team can call it, we can expose it
We build against whatever you already run. These are the systems we see most.
Booking and scheduling
Cliniko, Calendly, SimplyBook, custom booking tables
CRM
vTiger, HubSpot, Salesforce, Zoho, anything with an API
Inventory and orders
Shopify, WooCommerce, ERP endpoints, warehouse systems
Practice and case management
FlowLogic, NDIS platforms, allied health systems
Support desks
Zendesk, Freshdesk, internal ticket tables
Anything with an API
If your team can call it, we can expose it safely
Security and permissions
Control every action before it reaches your system
✓
Read and write actions are scoped separately, so a connector can look things up without being able to change anything
✓
Write actions can require confirmation before they commit
✓
Each agent gets its own token, revocable on its own
✓
Rate limits per key, so no agent can hammer your system
✓
Every call logged with the agent, the action and the outcome
✓
Metadata stored, not payloads, unless you turn capture on to debug
✓
Australian hosting, and nothing used to train a model
The assistant only ever sees the door, never the building
It cannot browse your database, discover endpoints you did not expose, or reach anything the approved action list does not name. Revoke the token and it stops, immediately, without anyone touching your software.
What the four weeks look like
Scoped, built, tested, live
One workshop from you, a test endpoint you can try yourself, then it goes live.
1
With you
Scoping
One workshop on what agents should be able to do, and what stays closed. Nothing is built yet.
Week 1 ends withTool list, auth plan, fixed price
2
We build
Build
Nothing changes inside your system. We sit in front of it.
Week 2 ends withA connector against your existing API
3
You test
Test
Call it from Claude or ChatGPT yourself and see what it does before anything is live.
Week 3 ends withStaging endpoint and a token
4
We run it
Live
We watch it, and we fix it when your upstream changes.
Week 4 ends withProduction URL, scoped token, monitoring on
Model the business case
What could Speedoz save your team?
Use your real request volumes, handling time and staff cost to estimate the labour capacity Speedoz could return.
Bring your workflow volumes and quote, and we can pressure-test the assumptions together.
Method. Monthly tasks × minutes ÷ 60 × automatable share gives hours returned. Labour saving uses your loaded hourly cost. First-year net and ROI subtract the quoted investment.
Planning estimate. This calculator is indicative, excludes tax and does not guarantee realised savings. Validate task suitability, adoption and costs against your own operations and Speedoz quote.
How it is priced
Custom to the workflow, clear before build
Every engagement is scoped around your systems, approved actions and operating volume before a build is committed.
Scoping
Fixed fee
quoted before the workshop
A week of discovery that ends in a written scope and a fixed build quote.
✓Workshop on the actions worth exposing
✓Auth and permission model agreed
✓Written tool list and schema
✓Fixed-price build quote
✓Credited in full against the build
Build
Quoted from scoping
one-off
We implement the connector against your service and hand it over working.
✓Connector built against your existing API
✓Hosted on your own subdomain
✓Staging endpoint before production
✓Token scopes per action
✓Handover documentation and a walkthrough
Hosting and support
Monthly fee
per connector, per month
We run it, watch it, and fix it when your upstream changes.
✓Hosting and uptime monitoring
✓Usage and error alerting
✓Token rotation on request
✓Upstream change fixes included
✓Named contact for escalations
Speedoz is delivered as a build rather than a subscription. Rates are confirmed in writing at scoping before anything is committed.
A worked example
A physiotherapy clinic wants two actions exposed: check availability and create a booking. Scoping is a fixed fee, credited against the build. The build is quoted from that scope, and a two-action connector against an existing booking API sits at the lower end. Hosting is a monthly fee for the one connector. If the clinic later wants order status added, that is a change quote against the same connector rather than a second build.
Straight answers
What people ask before they commit
Is it safe to let AI touch our system?
It never touches your system. Speedoz sits in front of your service and only exposes the specific actions you approve, one at a time. The model cannot ask for anything outside that list, cannot see your database, and cannot reach an endpoint you have not signed off. Every call is logged with the agent that made it.
What if it does something wrong?
Read actions run freely. Write actions can be set to require confirmation before they commit, so a booking or an order is proposed rather than executed. Rate limits cap how often any agent can call, and revoking a token stops everything immediately without touching your service.
Do we need developers?
No. We do the build. Your team’s involvement is one scoping conversation about which actions are worth exposing, then access to a test environment. If you have developers they can review the tool list and the auth model, but nothing is required from them.
Will it break when we change our software?
That is what the hosting fee covers. We monitor the connector, and when your upstream system changes we fix it. You are not left maintaining an integration you did not write.
Who can see our data?
Only the agent holding a valid token, and only the fields the approved actions return. We store metadata about calls, not payloads, unless you switch payload capture on for debugging. Nothing is used to train a model, and hosting is Australian.
How is this different from a chatbot?
A chatbot is a window on your site that a customer has to find. This works the other way around: the customer stays in ChatGPT or Claude, where they already are, and the assistant calls your system on their behalf. You are not competing for their attention, you are reachable inside the tool they chose.
Why not just build it ourselves?
You can. The protocol is open and documented. What takes the time is the auth model, the permission scoping, hosting it reliably, and keeping it working as both your system and the protocol change. If you have the team and the appetite, build it. If you would rather it be someone’s job, that is what we sell.
Where should we start?
Start with one bounded, valuable action such as checking availability and creating an appointment. We scope the permissions, confirmation rules and logging around that workflow before anything reaches production.
Consultation
Start with one workflow worth making callable
The strongest first deployment is a bounded workflow with a clear customer outcome. Appointment booking is a useful example because the read action, write action and confirmation boundary are easy to see and test.
Bring the system you use today and the action you want an assistant to complete. We will map the permissions, dependencies and operating volume before recommending a build.
Not a fit if
You want a chat widget on your own website
Your system has no API and no way to add one
You need it live next week
Book a Speedoz consultation
Tell us which system or workflow you want an assistant to reach. We will reply with the questions needed to scope permissions, timing and fit.
Make your next AI enquiry actionable
One consultation is enough to identify the first workflow, the controls it needs and what a reliable build would take.