One of the main purposes of Skedda is to make things as self-service as possible, thus reducing the amount of work that your System users have to do. Partly for this reason, we don't really support the concept of administrators having to jump in and 'approve' or 'deny' every single booking.
That said, we understand that there are situations where 100% self-service isn't appropriate, so read on for two options.
Option 1: Default to 'Accept' and then '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. A System user 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 approval, System users 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 add custom booking information to the user booking window. Perhaps something to the tune of "Spaces X and Y require final System user verification and may be canceled within 24 hours if they cannot be accommodated".
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 a System user and manually entered into Skedda if they can be accommodated.
There are several simple form collection options that often exist within a website CMS or by embedding an external service such as Google Forms or Wufoo.
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.
Skedda still allows you to allocate these bookings to specific users so they receive notifications and booking history can be tracked.