One of the main purposes of Skedda is to make things as "self-service" as possible, thus reducing the amount of work that admins have to do. Partly for this reason, we don't really support the concept of admins having to jump in and 'approve' or 'deny' every single booking.
That said, we understand that there are of course situations where 100% self-service isn't appropriate, so read on for your options.
Option 1: Default to 'Accept', and 'Deny' only when needed
The first possibility is to invert the logic and 'accept / approve' bookings by default and then deny/cancel them when necessary.
Specifically, the venue email address is notified whenever a booking is created. An admin can then jump in and cancel any booking after it's been created if they feel it should be denied. Through this mechanism you're able to "deny" bookings. In the "default" case of "approve", admins don't have to do anything (which hopefully reduces your workload).
To help your users understand that their bookings may still be denied after they create them, you can put custom information in the booking process. Perhaps something to the tune of "Spaces X and Y require final admin verification and may be cancelled within 24 hours if they cannot be accommodated".
The article below explains how you can include this information:
Option 2: Booking Form
A more strict approach is to add a form to your own website that collects booking requests. These submissions can then be monitored by an admin and manually entered into Skedda if they can be accomodated.
This can often work well alongside an embedded Skedda calendar, so that users can check availability before making a request. More details on embedding can be found here: Embed Skedda into your website
Skedda still allows you to allocate these bookings to specific users so they receive notifications and booking history can be tracked.