Hey everyone! Are you surprised to see us back with an update so soon? Well lucky you, we've added yet another new feature that we're excited to share with you.
You can now transfer bookings from one experience to another.
For a long time now, we've had the ability to transfer bookings from one date or time to another. But ever since we released that feature, we've heard from you, our merchants, that you need to also be able to transfer across experiences.
It took us a while to decide how to approach this because one of the complexities that comes with transferring across experiences is the fact that experiences sometimes cost different amounts of money. We went back and forth on whether to handle that inside our app which would mean more work to manage refunds and extra charges but ultimately settled on just moving the inventory and letting you as the merchants decide how to reconcile the cost differences. At some point in the future we may still add the ability to refund or invoice customers while transferring but for now it just transfers the booking from one experience to the other.
The one caveat with this functionality that you should be aware of is that we currently have two types of experiences. One we refer to as "Legacy" and the other just as "Experiences". As the word legacy implies, these experiences while mostly behaving the same to you, are actually quite different under the hood. For this reason the transfer across experiences will only work to transfer to the same version of experience.
The good news is that we're also very close to getting all our legacy version experiences converted over to the new system which means very shortly this won't even be an issue.
As always, thanks for using Experiences App! If you have any questions you can always reach out to us using the chat bubble in your app or emailing us at firstname.lastname@example.org
Hello everyone! Man it's been a long time since the last update. We have been hard at work making Experiences App an even better way to run your Experience business!
We're not going to try to go through every little detail of what we've done since the last update but we do want to highlight some of the exciting things we've been working on.
Yes this is what we're most excited for. We know many of you have been waiting eons for this functionality and we're excited to announce it's finally available for everyone. Because this was quite the undertaking and impacted every part of the application, we wanted to double and triple check that everything was working correctly. This is by far our most requested feature so far but it's also one of the most complex features we've released which is why we've written and recorded some pretty thorough tutorials on how to manage multi-day experiences. As people start to use the Multi-day scheduler and provide feedback, you can expect that we'll be doing our best to reduce complexity and improve the ease with which you can manage multi-day experiences. If you are interesting in getting start with multi-day experiences you can checkout the article here.
Don't worry if you're not sure what a "Proxy Page" is. Essentially one of the issues that we've had since releasing Experiences app at the very beginning is that when we embed our booking form into the store front page for the shop, our app will inherit any cascading styles from your shop's theme. In many ways this is awesome because it means that our app can embed in your site and look like it's part of your theme and been there the whole time. We want Experiences App to fit flawlessly in to your shop and to stay on brand and on narrative with the experiences that you're offering. The down side of embedding the app in the theme files, however, is that if any of the styles that cascade down to our app mess around with layout, colors, functionality, or display, our embedded form can be rendered unusable. After lots of research and experimentation we found that the best way around this was to use Shopify's Proxy page functionality which allows us to embed a full page app outside of the theme files on your shop. This way the app still appears at your shop on your domain, but we don't run the risk of having our app's styles overwritten by theme styles. If you don't have the full page booking widget set up you can go in to your Experiences App Settings and change your "Default Template" to "Full Page" which will make use of the proxy page. One thing we lost in making this change is the ability for our app to stay in line with your theme's colors, font, style, etc. This is definitely very important to us so we're already discussing ways in which we can make the proxy page customizable to suit your shop's branding.
Minor fixes and improvements
Along with those to big features, we've made numerous improvements and quite a few minor bug fixes. Too many in fact to go into individually. App stability and ease of use is a huge priority for us as we understand that our app is a vital component to your experiential commerce business. The ideal is always to release perfectly working software 100% of the time that's easy to use. The reality is, we're not perfect and sometimes unexpected bugs make it past our tests. Furthermore, some times the things that are so clear to us when building it turns out to not be that clear to others. When this happens we do our best get bugs and improvements done as quickly as possible and then take the necessary steps to make sure that it never happens again. We are always available via the chat bubble if you ever need help or think you've found a bug so don't hesitate to reach out to us!
What's coming down the pipeline
We have a few exciting things we're working on now that aren't quite ready to release yet.
- Transfer across experiences- This has been a big request. Up until now you've only been able to transfer attendees to different time slots on the same experience. With this additional feature you'll be able to choose not just a different time but also a different experience.
- Link an experience to a collection of products- For many of you, your customers need to choose not just a date and time but also a corresponding product such as a workshop project, or class supplies. With this feature addition, you'll be able to choose or create a collection of regular products and our app will make sure that each attendee chooses a product from that collection before getting to the cart page.
Those are the two we're most excited about but there's plenty of other things in the works that we can't wait to get in your hands. We appreciate all of our merchants and love that you've chosen to use Experiences App as your partner in the experiential commerce industry. If you have any questions or issues please don't hesitate to reach out to us in the chat bubble in your app or email us at email@example.com.
Hopefully, you're all enjoying these updates. We're always excited to let you know about the things we've fixed, improved, and added.
Todays update is a quick as we just released a hot fix for a bug that affecting people using the "Allow customers to book while in progress".
Some more details
We introduced the "Allow customers to book while in progress" functionality shortly before releasing our new scheduler system. This functionality was originally just applied to our legacy schedule system and in bringing the two features sets together, we missed adding it to the new system.
This meant that merchants who were using the new scheduler (if you've created your experience after Dec 8, 2020 then you're using the new scheduler) and also allowing customers to book an experience if it was already in progress, weren't actually allowing customers to book.
This was seen in that those time slots that were in progress simply didn't appear in the booking form. This was relatively quick and easy to remedy once we were made aware of it and have confirmed that it's resolved the issue.
While we can't promise bugs will never make it into production, we do consider issues like this beyond what should be expected and we moving forward we're looking in to ways in which we can do a better job catching these types of mistakes before they have in impact on your business.
As always if you have any questions or concerns please reach out using the intercom chat in your app or email us at firstname.lastname@example.org
As you can tell we've been busy and busy fixing bugs!
Here's a few updates from the latest release.
We fixed some issues where orders created via the POS were missing the correct line item properties and/or customer. This resulted in a lot of orders getting put in the unassigned order bucket even though they were
We also fixed an issue that was just introduced in the last release where our new "Latest Changes" widget was causing the admin to crash if loaded on mobile or a small screen size.
Here's a more detailed run down of issues and their corresponding fixes for those interested.
This one took a while to track down due to the unpredictability in when it occurred. We had a few people reporting POS orders without a customer or unassigned orders even though they were booked through POS correctly. While the issues were very similar they were ultimately two different issues.
We keep some
linksto customers in our own system so that when orders are created through our app, we can be more performant on linking that customer to the order. Since Shopify limits our use of the API to your shops (as they should), we try to be very careful at how often we use that API so that we're not abusing it. What that means is we need to keep certain data in sync between our system and Shopify. Sometimes things get out of sync and in the case of the missing customers on orders, we were using an out of date Shopify customer ID which Shopify correctly said "Oops, can't find that customer".
This would often occur when a customer that had previous booked an experience in your shop was then deleted from Shopify's side. Our fix for this is to simply use the name and email provided at the time of booking which Shopify can then link up correctly on their side.
So no more missing customers from POS orders.
Invalid Unassigned Orders
This issue came from a subtle difference in how Shopify treats line items vs how our system treats them. Shopify will
batchline items with the same variant and properties together so that instead of seeing two line items for the same variant, you'll see one line item with the quantity of 2.
line itemsare essentially bookings, we keep them separate so you still see that each line item is 1 booking. What this meant is that when we went to create each of the line items in the Shopify POS cart, we would tell Shopify to update the 4th line item even though it might have collapsed that line item down into just 3. So the Shopify POS said "uhh can't update a 4th line item if there's only 3".
This was a pretty simple fix once we were able to identify exactly what was happening. So from now on those of you that were creating orders in the POS and then having them come up in the unassigned orders window...you'll be happy to know that this has been fixed.
As you can tell from our last few releases, we've been hard at work fixing some of the annoying bugs that you've been kind enough to point out to us. While bugs are inherently a part of software we want the core of our app to be insanely reliable so while we have a few cool features coming you're way, we've been extra focused on making sure what we have works 100% of the time.
As always reach out with questions or issues using the chat bubble or email us at email@example.com!
We have just a couple quick things to tell you about this time.
We fixed one more missed bug related to email customizations and we added a fun little button that lets you know when we've released something new and what we've been working on!
The Email Bandit Returns
Ok remember how last time I talked about how complex our email system was and how I was so glad that it was finally fixed and working probably and we would never disappear your emails again?
Turns out I was right that it's super complex and as luck would have it we missed one more little edge case that was disappearing email customizations. After much double checking and testing, I can now confidently say that we've addressed these customization issues.
Read All About It
In case you haven't noticed, we've been posting updates about our releases. We want to keep you updated on fixes and new features. From now on, when you see a little red badge next to the "Latest Changes" button just like in the picture above, you'll know that there's something exciting for you to check out.
Thanks for reading, that's all for now!
-The Experiences Team
Nothing too flashy in the latest releases. Not every release can be the pinnacle of innovation. Sometimes you just have to tend to a few bugs. That's exactly what we did for this release!
We address a couple high impact bugs this week.
The first of which was a bug where email templates would save but then later when you came back to them the changes would be gone. Rest assured, from now on we will not disappear your custom email changes.
The second was an issue in the Point of Sale that would prevent certain afternoon time slots from showing.
Finally, by popular opinion we brought back the functionality to duplicate email templates when duplicating an experience. From now own, if your experience has custom notification templates that you've edited and you duplicate that experience, those email customizations will carry over to the duplicate as well.
Most of what was to say has already been said above. I'll just add some context around the release points for those of you that are interested in this stuff.
The Case of the Disappearing Email Changes
Whenever we make changes to how some current functionality works (even if it's not visible to you the merchants or the customers), we have to wrestle with the question of how to keep things working while still updating the functionality. Generally, there are two options.
- Determine what needs to change at the database level and run a script to make those core database changes so that all functionality flows through the new changes.
- Add in additional logic to the application codebase to handle both the "legacy" functionality and the "new" functionality so that both scenarios continue working.
As with anything in life, all choices come as a set of trade offs. Option 1 carries with it a lot of risks in that you're running a potentially error prone script against production data that people are depending on. Option 2 means that moving forward you'll forever be maintaining two ways of doing the same thing and all the potential bugs that may come along with that.
In general, we like to stay away from option 1 as much as possible as errors there tend to be higher impact and harder if not impossible to repair.
All this is to say that a while back we changed some of the core functionality that runs our email template customizer to an overall better system. However, when we made that change we went with Option 2 from above and now we're dealing with the issues associated with managing both a legacy and updated system.
What was happening here is that in shops where you the merchants had edited the global shop email templates in the legacy system, and then later went to edit individual experience templates, your changes would be saved to which ever template you were editing that time. However, when you moved on to edit the next experience template, the system would update the edited template from the last experience to be linked to the new experience. Thus as you went through your experiences making changes, those changes would only be applied to the last saved experience and all other ones would go back to the default template.
After several days of trying to figure out what was going on here, I'm happy to say we've finally got this one wrapped up and from now on changes made to email templates will be correctly saved and linked to the correct experience.
The Not Duplicated Emails
Loosely related to the email changes above, was the removal of duplicating email templates, when duplicating experiences. Again, going back to making changes to things that are already in use, you have to make trade offs when making those changes. One of the things we de-prioritized was duplicating the email changes. We thought that since most email template changes are specific to the individual experience, if people had made those edits, they wouldn't mind starting with the default on a duplicate experience.
As it turns out there are several good reasons to carry on those edits to the newly duplicated experience and therefore we've brought this functionality back. From now on if you've edited your experience level email templates those edits will carry over when you duplicate that experience.
The only caveat to that is that for legacy email templates (templates that haven't been edited since January), you'll need to first go in and save those templates with a minor change before duplicating the experience. This will convert the template over to our new email system and allow it to be duplicated along with the rest of the experience. Be sure to do this for every email template on that experience.
Hidden Time Slots in the POS
Lastly, we fixed a small bug with pagination on the POS time slot list. For those of you not familiar with pagination, this is the act of programmatically loading data in to a page in small chunks or "pages" and then incrementally loading more as needed.
This can be a bit tricky especially depending on the type of the data being displayed. In the case of dates and times which is what we're dealing with, there's a lot of little big details that can cause parts of the data to be skipped over.
That was the case here where the evening time slots would be skipped over when clicking "Load More" because it would simply jump to the next day, rather than including the remainder of the current day.
Our current POS time slot list will load in 10 time slots at a time and we've now corrected this to ensure that if there are still time slots on the current day, it will include those in the next page when clicking "Load More".
We know these types of "bug fix" releases aren't quite as fun as ones filled with a bunch of shiny new features but we consider the reliability of current functionality as important as the generation of new functionality.
Because of this we consider these types of releases similar to taking our daily vitamins. They're not nearly as a smoked brisket but they keep everything running well enough to occasionally indulge in delicious slow cooked meat.
Thanks for reading this far and most of all thanks for using Experiences App. You can always reach out with questions using the blue intercom bubble in the app or by emailing us at firstname.lastname@example.org.
This latest release is pretty exciting in that while it doesn't have a lot of flashy new functionality, we've addressed some long running bugs that have been nagging at all of us for a while.
We fixed quite a few bugs that were occurring with booking conflicts and made some much needed improvements to the transfer booking calendar in the Admin dashboard. You can see the transfer booking changes in the video below.
Booking Conflict Issues
Many of you have noticed a few strange issues where editing an experience with lots of bookings would cause some to be marked as booking conflicts. There were also issues where orders would be marked as booking conflicts even though they were for a valid time slot. All of this and a few other issues were essentially due to the way we attached bookings to a specific time slots. We used a unique id which was added as line item property to connect a line item to a specific booking. There were some technical reasons for structuring the id the way we did but we didn't foresee that anytime that id changed even in the slightest, bookings wouldn't be able to be linked to the correct time slot even when all the time info is there. While we tried to remedy these issues using some less invasive approaches, it became clear that we needed to rethink how we were doing this and put in the work to fix them once and for all.
You'll now notice that the "Timeslot" property on line items no longer includes the long string of random characters, but instead is just a plain old UNIX timestamp indicating the time of the booking. We still want to make this invisible to the customer and plan to do that in the future but hopefully this isn't quite as confusing as the long string of gibberish that many of you have noticed. This change means that bookings will no longer run the risk of becoming "detached" from the correct time slot due to weird unique id changes which means you can edit your experiences schedule and bookings will always appear in the right place.
The other exciting implication of this is that because this unique id issue was creating a pretty big performance overhead on our database, with it remedied we're now able to confidently say our system can handle very high bursts of booking traffic (1000+ people trying to book at the same time) without impacting either the integrity of the bookings or the performance of other parts of the app (admin, pos, etc).
You can still get booking conflicts if you completely remove time slots that already have bookings but you will no longer have issues with valid bookings becoming conflicts. This is the correct behavior of booking conflicts.
Updated Transfer Booking Calendar
Another issue that has been seen on several occasions is an overall "bugginess" with the transfer booking calendar in the admin app. Sometimes time slots wouldn't load in unless you clicked forward and back, times were being displayed in 24h time instead of 12h time and a few others.
We finally dedicated some time to putting in a much better calendar here which correctly displays time slots, improves the UX and makes it very easy to navigate to the time slot you want to transfer to. Hopefully, this will make it much smoother for you to move your bookings to different time slots.