Q: Hi - the 1% transaction fee will likely kill any interest for most sumos.
I addition, if you are charging a transaction fee, why limit it to a single brand? In such case I would seek as much adoption adoption as possible…including unlimited brands and calendars. You are essentially asking to own 1% of the revenue of our businesses, without any risk on your end 🤷🏻
Orkun_kiwilaunch
May 15, 2024A: Thank you for the feedback. Essentially you have unlimited calendars with unlimited number of staff. Branding settings are at the account level so it feels quite intuitive and common to me that each bought code represents a new account.
We have a lot of clients who pay our regular monthly fees already and from experience and past data, I can say it doesn’t essentially represent 1% of the businesses’ revenues. There are a lot of bookings where clients don’t opt for online payments hence you don’t pay transaction fees.
I disagree with the part that we are not taking any risks. We plan to honor our commitments, and selling a SaaS as a lifetime deal does come with a life long liability to provide support, answer questions, provide a service level with a certain uptime, and even bear the risk of cannibalization.
I am sure different types of usage limitations of other products are also not favored by sumos. As you see we don’t have any limitations in terms of calendars, staff, number of customers/bookings or services because we don’t have an agenda of locking in upselling later. Instead transaction fee provides fairness in pricing and differentiates what a freelancer pays from what a large cooking school pays.
I know you didn’t ask a question and it was rather a comment, but wanted to address your points regardless.
ba9607f2e640454697ddcd46b78aaa98Orkun, I appreciate your reply!
In my view, there are essentially 3 types of vendors in AS:
1. Solopreneurs (and micro SMEs) with scarce resources seeking to monetize their solutions
2. Startups seeking to validate their proposition and accelerate maturity with users feedback for pennies on the dollar.
3. Existing businesses requiring an urgent infusion of cash but were unable to do so via conventional ways.
I thought yours was an startup, but based on your feedback:
“We have a lot of clients who pay our regular monthly fees already”
It seems yours is in the latter group….which is an eye-opener considering the solution seems of great value.
Note that (although is NOT my definition of a great deal) I am NOT criticizing de 1%, which is a brilliant business model (if you manage to get customers). Just ask any bank 🤣!
My feedback is about the limitation of 1 business per code, when you are already asking for the 1%.
IMHO you’ll do way better with unlimited businesses. In the end, the money is with the transaction fee, as a you said “ because we don’t have an agenda of locking in upselling later”.
Finally, with regards to your statement about the transaction fees, there are two sides of a coin…
You call it “ fairness in pricing and differentiates what a freelancer pays from what a large cooking school pays”.
Someone else could argue that it is a system that penalized growth and progress 🤦🏻♂️.
Yes, the busier the business the more resources it’ll consume. But then, you should consider the economies of scales in your end. That is why other organizations with a per transaction model usually provide volume-based discounts…even payment processors such as PayPal and Stripe!
I hope you see this message as constructive feedback and NOT as criticism. I wish you great success!
Hello, Thanks for the great message! I think we partially joined Appsumo to engage with an educated buyer community, and your message really proves it works (Would love you to add me on linkedin to build a longer-term connection).
Appsumo gives us the platform to test how different personas may or may not utilize our platform. Initially, we all built the initial clientele with a sales-based approach with assisted onboarding, which automatically filters out a significant target group with cost sensitivity. We wanted to see if Appsumo helps us see how much we are missing out on certain target groups with our initial limitations.
Nobody yet argued that it penalized growth and progress. But it naturally creates friction, there are millions of businesses who don’t want to adapt even online payments because they don’t want to pay ~2% in transaction fees. We just respect their choices.
Very few software products enjoy the privilege of perfectly measuring the monetary value they create, and we are fortunate to be able to adopt value-based pricing via transaction fees. I can’t think of any better “pay as you earn” pricing.
Your feedback about one business per code still didn’t echo with me. All branding settings, domain/cname settings are at the account level, and each code creates an account. Regardless, I like that a super small fee (one of the lowest in Appsumo) acts as a filter. That’s the very reason why we haven’t built a free plan yet.
Don’t worry about your comment being interpreted as criticism, we are open to it as well ;)
Cheers!
JenwI agree with you, once I saw the 1% transaction fee in addition to having to pay stripe fees was a deal breaker for me.
BrightspacePLUS
Verified purchaser
I have to agree also a % of hard earned sales does not sit well and it's something I would avaid at all costs, and it's easy to avoid there's plenty of choice, Trafft is very good and no charges, if you attract MRR that's a red flag for me, at the most I would consider an annual fee for white label of $10, but even then it would need to be necessary because there weren't viable alternatives, but I don't think it is now and will be even less likely in future, unless there's something special I will refund this I suspect.
BrightspacePLUSVerified purchaser
* if you CANNOT attract MRR in the near future ..
Hello @BrightspaceGroup.com, Thanks for the feedback and for sharing your thought process transparently.
I think we do have something special. We provide a conversion-optimized approach to service sales, and we knew that to achieve this, we needed to build an excellent admin/back office suite, which is a service business ERP. I shared more details about this below.
As to transaction fees, when we attract our users to pass online paid transactions via our platform we already see it as a huge win. I don’t agree with MRRs being the defining success criteria, if a client doesn’t make revenues through our platform, then we are fine to not charge them a monthly fee anyway. Our target is to increase your revenues, and we are fine to only make money if you do so.
It would be unfair of me to name any particular competitors as they won’t get the chance to share counter-arguments, but I have built service marketplaces and bring some knowledge of service sales, and before building kiwilaunch, I tried 20+ paid/free alternative products. I am still trying every time I come across a new one.
Most of the time what disappointed me were:
1. Meeting schedulers’ positioning: Existing products didn’t think beyond simple meetings, and adding a payment field to the end. They reduce the domain to calendar events and participants are an attribute of that event. For us staff/booking/purchases/customers are different entities and calendar events are just an extension of bookings and pre-defined schedules. If you are a product-led growth expert with a client base, and selling a one-off $800 consultancy, it works for you. If you are a personal trainer, who wants to manage the client lifecycle, then you should reconsider.
2. Online booking products focusing only on Salon/Spa: Existing products reduce the whole booking domain to ‘salon/spa’. and the moment you introduce things like proper repeating appointments, session packages, at-home services, and fixed-dated courses/experiences, they claim they solve it, but they failed in terms of usability or functionality.
3. Not having a vertically integrated system: Showing real-time availability to the clients is very important, which means the online booking should be fed from staff calendars. For freelancers, Google Calendar integration just seems to solve it, but even for slightly larger companies this requires almost a service company ERP. We tried to design kiwi to be very simple and intuitive to work for smaller companies, but still have enough complexity to manage their day-to-day operations. 80% of our development efforts are going into the admin panel although the actual hook value proposition is the online booking functionality. What happens is after getting 2-3 bookings, users start to appreciate the admin panel functionality for day-to-day operations.
So all in all I do believe we do have something special, but of course, if you gave it a fair try, and your experience didn’t reflect our vision, then you indeed should get a refund, especially if the pricing felt unfair. Either way, we appreciate the interaction and the feedback.
944cb7f0043a4049b414a883a0536963Verified purchaser
I just bought and love the Ai feature as I am setting this up. I am not worried about the 1% fee because I will use this to book services with a deposit. That deposit goes toward service being booked for, or it's non refundable for any no-show. The deposit is only $45, so the 1% would would .45, which is worth getting a new client for me. They will pay the reminder at time of service.
BrightspacePLUSVerified purchaser
Orkun,
Thanks for your reply, I have discovered myself through trying several different booking apps there is far more potential for complexity than one might think at first (as so often in life!), and indeed granularity of the Admin side is the only way to solve that unless you can change your business model to fit the Booking Apps view on how things should work. With flexiblity for different needs comes admin power and usability tends to inversely correlate of course so it's tough to balance but I would opt for Power every time in a booking App, after all once it's set up it's generally not too much extra work depending upon powerful features like duplicating meeting types with both date ranging and on an adhoc basis. Trafft is decently powerful but has some basic errors IMHO like making refund policies apply at the account level rather than at the service or Event level ( very disappointing for me), the inter appointment padding again should not be set at the account level ( shooing out 10 people from a group session can easily take 45 minutes whereas a 1:1 meeting might only take 10 minutes, and also the way it imposes time blocks for appointment bookings after a group session, it does have quite a pretty front end design though, but that's superficial versus the functionality IMHO.
Fyi my need is for a hybrid booking service, some group sessions that have fixed scheduled times and limited spaces within them, and some "choose your own appointment slot" type bookings, ideally it would natively update a Google Sheet with all booking transactions too, and the booking forms should allow custom fields which can be "Required" if needed, finally Admin should be able to set the app so that only customers they have added can use it by logging in with their own credentials ( which the app would remember and use for their booking transactions) if that could be a SSO login from a client portal such as Fusebase or Super Okay also that would be awesome and really make it something special. ( I know I'm probably demanding but it's a wish list!)
Regarding fees, I think charging commission will harm traction but you wouldn't be the only app to use that model, to innovate why not use an automated cap so the Lifetime deal owners never pay more than X £/$/€ per month.
Finally I agree MRR is not the definition of success, but SASS businesses do tend to need MRR to cover support, development and to stay engaged. Hence if they can't achieve MRR it's a red flag, in this community we have seen quite a few vendors come with a product, cash raid for lifetime deals and then fold and leave us high and dry because their product, or perhaps their marketing meant they weren't able to achieve a sustainable level of MRR. Booking apps are a red sea IMHO and some market leaders have a fixed price so to avoid churning the better customers capping would need to be considered at some point anyway. Just my thoughts GLWS
Hello, Thanks for taking the time to write your thoughts extensively, I am picking up the feature requests and suggestions.
We are trying to be very careful while judging the need for granularity, as sometimes things that look like necessities don’t increase either our Sales or our clients’ sales.
For example, for you it might sound even hard to grasp, but we don’t even have a portal for the end users to log in and manage their bookings. We found out that the logged-in user percentage is so low, it doesn’t tick the needle. That’s why we doubled down on guest checkout and the admin panel functionality to manage the lifecycle.
You mentioned that another software has a shortcoming that the refund policy is at the account level and cannot be overridden, my experience with microbusinesses is, when they look eye to eye with the customer they never honor the refund policy window, and the last minute so-called emergencies are almost always accomodated. We see it, understand it, and say, “Why put a cancel button inside the email to call for the action, if the cancellation window won’t be honored anyhow?”. It becomes a negative sum.
We are not trying to claim we always know what’s best for our clients of course. But there is also the fact that agencies most of the time are judged by their ability to accommodate change requests and customization demands. And it sure should be hard to re-sell a product only to say after “It is not possible to achieve this config.”. It is easy for us to defend a product design choice (even if it is a restriction) heartfully by explaining the reasoning that we have their interest in mind. But it is hard to expect an agency to buy into this reasoning, believe as much as we do, and resell that reasoning to their clients.
I agree with the risk of buying products that don’t build sustainable models, selling lifetime deals, and then failing to fulfill. We are trying to make sure that doesn’t happen through the transaction fees and I really liked the idea of capping it (we offered this in the early days to larger clients who were expecting large volume). We just need to think about how to communicate it, as if we say it is capped to $X, people may perceive it as $X additional cost without putting the $100X online revenues in perspective. But it is a good idea nevertheless.
Thanks for the interaction and good wishes!