Transcript
Someone asked me today how to build a room booking management system, so I imagine this is for something like a coworking space. We will look into how we can actually achieve that with Softr. I am creating a new app here, selecting Softr Databases as the data source, and we will start by setting up our database.
I will create a new database from here and call it Room booking. What we need is to start with a users table with an email field, and these are actually the users who will be using this app. Right now, to simplify, we can consider that this is the admin team of the coworking space.
We will have their email, their name, and for now, that is it. We will also add a select field for their role. That is how we will have admin and manager roles, which helps if later you want some user groups in your app.
Of course, you could also have clients instead of a manager so your clients have their own accounts to manage their bookings. Now we will focus on the booking management system, which is the most crucial part of this app. I will be adding a new table called Rooms.
I will actually be using the AI Co-Builder to go faster in building this table and also add some dummy data. I think that looks good.
[.blog-callout]
Note from Softr: When starting a new app or building database tables from scratch, another great option is to simply open the AI co-builder and prompt for what you want. It builds complete apps, pages, or database schemas instantly, while still letting you tweak things manually later.
[.blog-callout]
I will just be deleting this one field because we will be managing the bookings in a different way, but I think this is very good dummy data. For the status, we will not need it, but basically, we have a description, an image, capacity, and floor location. Now we need another table to actually manage the bookings.
We want one table per object. We have our app users, we have our rooms that can be made available, and we have our bookings. For now, to simplify, let us consider that the rooms can be booked at any time of the day and all week long.
We will see later that we have ways to handle that with more granularity. I will be adding a new table for bookings. For now, let us keep a status and a name, but I will be adding a related record field to link that to the room being booked.
Let us consider that one reservation is one room. When I do that for the Atlas meeting room, for example, I see that we have our bookings table already connected. Now we will add a date field, which is the start time, and I will duplicate that to have the end time.
Then we would be linking that to users, but for the sake of simplicity, I will just add an email field and say booked by. For statuses, instead of to do or in progress, we will have pending, approved, and canceled. Let us add some fake data right here.
Now that we have this, we can go back to building the first steps of our interface. Here we will have a grid with horizontal cards instead of a list, where we will be displaying all the rooms that we have available. Let us modify the contents.
For the image, we already have what we need, and it is perfect. We just need to make sure that we have a couple of filters. We will keep the default one to allow users to filter, and maybe we also include the search bar.
We will remove the image from the filter options. These are the fields that the users will be able to use to filter through the rooms. I will just delete that other block for now, as we are simply displaying the different rooms that we have.
We will not be adding records from here, as we are focusing on the user experience to book these rooms. What we need is that whenever we click one of these cards in the list, we open an item details block to show the room information. That block will be on a page that shows up whenever we click the list item.
Content-wise, we will have the image and maybe the room name here. The description and other details look excellent, so it is just the core information that we need. I will add some styling here with a container and remove the edit function.
Now we need the capacity to see the available time slots for this room and book them by providing our email and selecting the exact dates. For that, there is no native block in Softr because this is something very custom. That is where we will be using a Vibe-Coding block to prompt what we want.
[.blog-callout]
Note from Softr: If a native block doesn't quite fit your custom needs, try using the Vibe-Coding block! You can simply prompt for the exact custom component you want, and it will generate it and connect to your Softr Databases seamlessly.
[.blog-callout]
We will get the exact block that we described and then we can share follow-up messages to ask for edits or refinements. Let us make sure this is connected to a data source, which will be our bookings. I will be adding a conditional filter to make sure that the room name matches the current record.
This ensures we are only showing the availabilities of this specific room. Now I will just explain to the AI what I want for this block. I have described with my own words what I think would be the best fit, so let us see what we get.
I think this looks really good for a first version. Now I would like to preview what we have. If I go back to the homepage, let us change the card action to have an icon instead of just clicking anywhere on the room.
Having an icon might be a bit more visual, and it will be set up to open the detail page for that room. I will be adding a title as well. As for now, the experience to book rooms will not trigger for logged in users.
I will make the visibility of this page available to everyone, and the same goes for the details page. From there, I can just hit the preview button and we will see how my app looks. I will choose this room, and if I select a day like tomorrow, I can decide to book the three-hour slots.
I can type in my email to confirm it. The booking is requested, and if we go back to our database, we see that we have a pending booking for that room. That is exactly what we wanted.
We can actually improve this naming convention using a formula if needed. That would be an easy change, and of course, you can set it up the way you want. Now I went back and asked for some UI improvements on the component, which the AI implemented for me.
We will be previewing again from the homepage. We will choose that same room and go check what we booked. We booked the 10th, so that is tomorrow, and we see that these time slots are not available anymore because we booked three hours.
We could re-prompt the block to ask for a different design, like completely hiding those slots or showing that they are unavailable. That is very easy to change. If I pick a one-hour slot here, it perfectly changes my interface, and I can even go back and adjust my slots.
From there, you can imagine tailoring the experience to make sure it is perfectly presented and introduces your coworking space layout. You could also implement this strictly as a logged-in user page. If I go right here, instead of seeing the app open immediately when you enter the website, you would see a login or signup page.
We can configure that in the user settings. We could be syncing the user setup of this app to the users table that we had created earlier. This will sync and pull the data that we had inside Softr Databases.
Right now I am not sure we had any users yet, so I will add some. When we go back to our users table, we will have them all populated. I will just remove the test user, and our user system is perfectly synced.
From there, that is where you would be building your user groups. You could set a rule that says these are my admins, and the condition is that the role is admin. The other user group would be clients.
You could allow people to sign up in the authentication settings to get new users into this app. They could sign up as a client, and then you could have a system for them to pay to become a paid client or access free client resources. Setting up different plans and accesses really takes this booking system to the next level.
We will make sure this functionality is only visible to logged-in users, especially for the clients. From there, we can also build a block for our admins to essentially approve those incoming bookings. We will use one of Softr's native blocks, a list that is connected to the bookings table.
We will provide filters for the start time, the end time, the booked by email, the status, and the room. Let us also add the booked rooms as a separate filter. If needed, we could have an interface for them to manually add a booking by configuring these fields themselves.
Then we would simply be adding item buttons to the list. What I would do here is create a one-click update that we would call accept. We would set this to only show when the status is pending.
With one click, we will change the status to approved. With another button, we will call it reject, and when we click it, we cancel the booking entirely. Once we have added some customization there, I can also go in and change the overall theme of my app.
Maybe this brand is more orange, which we can update, format the text, and it looks perfect.
