We currently simply integrate with your Google Analytics and filter by Source. This tends to be a lower bound, since it's not always set correctly. Coming from some of the native apps, users might be categorized as direct visitors.
There are other data sources we want to enable in the future like Cloudflare.
funnily enough I was actually speaking to one of the founders of x.ai recently
I think they paved the way for a lot of the implementation we do today along with the model providers. That being said we are trying to do scheduling a degree greater of complexity.
Fair feedback that the case studies don't show this well - they're simplified to demonstrate the flow. The multi-party dependency resolution is happening underneath but we could surface that better.
On the LLM point - agreed that context window alone doesn't cut it. The coordination and state management layer sits outside the model. We learned that the hard way early on.
The concurrent resolution problem you're describing is exactly what we deal with. When a staffing coordinator has 15 interviews to book across shared interviewers, confirming one cascades into others. We track pending holds, rank by urgency, and when a confirmation on one thread invalidates a proposal on another, Vela detects the conflict and re-proposes. Theres
The only other alternative is a booking link but this, slows down business, doesnt work in many many real life situations and more :)
I like the name... very UK "ting." Would love to chat one sunday in April and see if there are learnings - feel free to use Meet-Ting to help get something on the calendar :)
very fair callout - and I can see how "scheduling solved" reads very differently to someone coming from the optimization/planning side of AI. You are right.
Appreciate the note on the slogan, definetly thinking of revamping our landing page in the near future to speak more directly to our audience.
reply