Where things stand
CallShark is temporarily down. There is no product you can sign into today, no calendar you can connect, and no account you can create.
We are publishing this website ahead of that deliberately, because the most useful thing we can do at this stage is describe what we are building clearly enough that people can tell us whether it is the right thing. That is easier to do against a concrete description than an abstract one.
This post is the first in what will become our product updates, and it exists mainly to be specific about a question we get asked directly: what actually exists?
What we are building first
The scheduling engine, before anything else.
By that we mean the part that validates a person, a room, and a time together and either commits all three or none of them. Everything else in the product — matching, notifications, reporting — depends on that guarantee being real. A platform that can confirm a meeting it cannot actually hold is worse than a spreadsheet, because the spreadsheet at least does not inspire confidence.
In priority order, the first pieces are:
Atomic booking. Person, room, and time reserved in one operation. If any component is unavailable, the booking fails cleanly and offers alternatives.
Availability as rules. Working hours per event day, daily caps, buffers, location awareness, and blocked commitments — expressed once as rules rather than enforced by hand on each booking.
Expertise-based routing. Attendees describe what they want to discuss; requests route to a team member whose specialism, seniority, and language fit, with a documented fallback when the first choice is unavailable.
Event programmes. The container that holds all of it: dates, venue, rooms, attending experts, meeting types, and one queue for both inbound requests and outbound targets.
Automated communication. Confirmations at booking, reminders before, immediate notification on any change, and a clean release of room and slot on cancellation.
What we deliberately deferred
Being clear about what we are not doing yet is more useful than a roadmap of everything.
Calendar integrations. Google Calendar, Microsoft Outlook, and Microsoft 365 are planned and none are built. We are building the scheduling engine first because an integration that syncs an unreliable schedule just distributes the unreliability.
Mobile applications. The web experience needs to be right before we split effort across platforms.
Deep CRM integration. Getting meeting records into the systems that hold your opportunities matters a great deal for the ROI question. It is not first, because it depends on the meeting record being complete and stable.
Approval workflows at full depth. Basic approval exists in the design. The more elaborate multi-stage governance that large organisations need comes after the core is solid.
Pricing. We have not set it. We would rather publish nothing than publish a number we have to retract.
About this website
Some notes on what you are looking at, because we would rather say it than have you work it out.
The interface images throughout this site are original design mockups. They are not screenshots of a running product and they are not connected to anything. We built them to show the shape of what we are making.
The figures in the results section are illustrative modelling, labelled as such. We have no customers, so we have no customer results, and presenting modelled numbers as measured ones would undermine everything else we say.
The testimonials are marked as examples. They are scenarios written by our team describing problems we have heard, not quotes from real people.
The company logos are placeholders. We are pre-launch and have no customers to name.
The contact form does not send anything anywhere, because there is no backend behind this site yet. It tells you so when you submit it.
None of this is unusual for a product at this stage. What is unusual is saying it out loud, and we think that is the right call — partly because it is true, and partly because a scheduling product's entire value proposition is that it tells you the truth about what is and is not available.
What would help us most
If you run meetings at conferences and events, we would genuinely like to hear how it works for you now. Specifically:
- What breaks most often in your current process
- How you decide who takes which meeting
- What you are asked for after an event, and how you produce it
- What you have tried already, and why it did not stick
That last one is the most valuable and the one people volunteer least. If you evaluated a platform in this category and decided against it, the reasoning is more useful to us than a feature request.
You can request a demo — which at this stage means a conversation rather than a product walkthrough — and we will be straightforward about where things are.
We will post here as things change. If a feature becomes available, that will be announced rather than quietly updated.