Very simple, aesthetically pleasing interface. My only complaint is that I don't immediately see how this is any better than the alternatives (sending an email which gets sucked in by Google calendar, Outlook, etc.). Also, I'm asked to start putting information before I have a chance to find out.
Didn't investors have a saying 10 years ago, YAC (Yet Another Calendar)? What makes this clearly different?
Hi there. Thanks for taking the time to look at it (and to comment!). I'm still working out the best way to call out its differentiating feature - which is really aimed at people/businesses accepting bookings, rather than people making them. Once you have an account on the site, you can configure details of the business(es) for which you accept bookings, and when people send you a booking request, the interface asks them to provide information that you need to accept the booking (e.g. what type of booking you're making, at which location, etc.).
In fact, the whole app that you've looked at is really just meant to be a big funnel for the actual service. The paid part is a comprehensive web-based app for managing bookings for a small business, aimed at being used at the front desk (and indirectly by clients booking through the site).
Can you point to a really good SaaS system for handling appointments and billing? (please! I'm looking for one)
Three random use cases:
* Medical and pseudo-medical practices
* Oven cleaning companies and other property maintenance services
* Advice services
Does something like Google Calendar work well for that? You could use it when you have a diary secretary in the way, but not if you want a self-service element.
I know a company that build billing for medical and they tried to build out a product like this but the people running it just hated it. They either get people all booked in horrible times or for a non-busy place people see that and associate it with being bad. One solution they never tried is trying to make it like the Apple store booking engine.
This is probably the best version of online booking I've seen or had to use. The problems with most of these sites is the fact that they require you to send customers to a third party. If tungle.me could run embedded in the clients site, and integrate in any meaningful way with existing client databases it would be a home run. As it is my own clients will continue to request the very basic booking system that I have built simply because the customer never has to leave their site and it will take advantage of their existing customer database and billing systems.
People using bookingly.com to accept bookings have the option of adding a booking widget to their site, which lets people make bookings with them directly on their site.
i'm building www.easycalapp.com for self-employed people who take appointments. it's in early beta right now but we'll be rolling it out to a wider group in the next month.
When the page loads, I see an event under today's date that says "click here to read me". I then click on the calendar entry and... nothing happens. It took me a few seconds to figure out that I'm supposed to click on the description that appears in the left sidebar.
On a related note, the description in the left sidebar is the same as in the calendar view, except it also has a start time. You could just put the start time into the calendar view and get rid of the sidebar description altogether, saving users from a little extra navigation.
I wrote a booking app some years ago, and the biggest UI win was to choose the date and time first, then enter all the details. This matched the workflow of the customer much better: someone would phone up, and the first thing they wanted was a time for the appointment. Once they'd got something which worked, then they were very happy to hand over their details.
Are you planning an API so that other sources can read and write data? (eg client contact details)
Is the Pro version suitable for use with confidential client lists?
Hi there - thanks for taking the time to look and provide some feedback. No API plans yet. I'm not entirely sure what you mean by a "confidential" client list - the list of clients for a business using bookingly.com is never made available to anybody other than that business owner in bookingly. Check out the free trial of the pro version to have a look.
I built an app last year for a client that included doing booking for dentist offices. One of the big things in getting people to use a new booking tool for their business is to allow them to block out times and business hours, before allowing others to just start creating appointments all willy-nilly.
Also, it's important to allow the business owner to set a minimum clearance for new appointments. E.g. if a dentist decides that they need at least an hour-block for a half-hour appointment (prep and cleanup time, etc), then the calendar shouldn't allow a patient to schedule an appointment in a half-hour opening.
But overall, I'm also unclear on how this alternative is better than Google Calendar? Is there a private-label version that could be integrated easily into my own site? Though, I guess Google Calendar now kinda has that as well.
Okay, everything was fine and looked nice until I tried to book an appointment.
It's fair to expect the person making the booking to create an account.
However, to expect the receiving party of the booking request to also sign up for account is asking for too much and is unlikely to happen.
Also, why do you ask for people's contact details (address, phone, ...). Do you really need that info?. If anything just put the necessary stuff on the create an account form and put the rest of the info on a profile page that people can edit later.
Hmm - I obviously need to improve some descriptive text in that email - thanks for the feedback. People receiving bookings made through it definitely don't need to create an account. They can just receive the email with the iCalendar attachment, save it in their calendar app as usual and continue on their merry way.
Didn't investors have a saying 10 years ago, YAC (Yet Another Calendar)? What makes this clearly different?