Bookings

Two crews arriving at the same hoist at seven in the morning is a whole day lost between them, and nobody finds out until it happens. Bookings is the shared diary for the things on site that only one person can have at a time: the crane, the hoist, the loading dock, the laydown area, the workzone on level four.

A booking is an operation rather than a slot. It has a title in plain words ("Unload rebar delivery"), a start and a finish, and it reserves one or more resources for that window. It goes through an approval, and the board shows what is agreed for today.

What can be booked

Two kinds of resource, and both are switched on individually rather than being bookable by default.

Equipment that is on site. Any piece of plant with an accepted induction on this project can be marked bookable, which is the join between this tool and Equipment: a machine has to be on site before anybody can book it.

Locations from the project's own location tree, the same tree Inspections uses. Loading docks, laydown areas, work zones, hardstand.

Each bookable resource carries three things of its own: whether a clash is exclusive or shared, its own custom fields (number of lifts, truck type, anything the site needs asked), and standing reference documents such as a crane lifting radius chart, which are shown to whoever is making the booking.

Board, week and register

Three views of the same records.

The board is one day. Columns are the bookable resources, grouped into equipment and locations, and the rows are the hours of the site's operating day, with a line showing the current time. Drag down a column to create a booking in that window. Approved and pending bookings are shaded differently and blocked periods are hatched.

The week view is the same thing across seven days, for spotting the pattern rather than the hour.

The register is the ordinary register screen: booking number, title, resources, status, organisation, start, duration and who created it, filterable and exportable.

Making a booking

Give it a title and the window it runs in, then pick the resources. Everything else is there because somebody on a site asked for it: the delivery location the materials are going to, what the materials are, the load weight for a lift, free-text notes, and attachments, which can be a file or a link to a document, a photo, a whiteboard or a piece of mail already in Teralo.

Whatever custom fields the resources carry are asked for per resource, so a crane can ask for the number of lifts and the dock can ask for the truck type without either form carrying the other's questions.

Booking numbers are generated in sequence for the project, BK-001 upwards. You do not type them.

Clashes and conflicts

Teralo checks for an overlap the moment the window and the resources are known, against every approved or pending booking on those resources. What happens next depends on how the resource is set up.

An exclusive resource cannot be double booked

The clash is refused, the booking is not created, and the conflicting booking is named so you can go and talk to whoever holds it. Set this on anything genuinely single-use: the tower crane, the hoist, the one loading dock.

A shared resource warns and lets you through

Set this on anything where two crews overlapping is a coordination problem rather than an impossibility, such as a large laydown area. You are told about the conflict and you decide.

A blocked period always blocks

Whichever kind the resource is. Blocked periods are set in tool settings and come in two shapes: recurring, for a lunch break or a non-working day, and one-off, for a public holiday or a shutdown. Each can apply to the whole project or to one resource.

Recurring bookings

A booking can repeat daily, weekly on named days, or on a custom pattern, between a start and an end date, up to ninety instances.

Each instance is a separate booking with its own number, its own approval and its own record. That is what lets one Thursday be rejected without touching the other eleven. It also means the exclusive-resource check runs per instance rather than on the pattern as a whole, so a pattern that clashes on two days out of twelve gives you the ten.

Status

• Pending, submitted and waiting
• Approved, the resources are reserved
• Changes requested, sent back with a note saying what needs to change
• Rejected, with a comment saying why
• Cancelled, called off

The submitting organisation can edit its own booking while it is pending, sent back for changes, or rejected, and can cancel it even after it has been approved, which is the case that matters: plans change on Tuesday afternoon and the crane should go back on the board straight away. Cancelling notifies the other party.

Bookings waiting on you appear in My Items.

The daily digest

A project can send a daily booking digest at six in the morning, in the project's own time zone, to a named list of people. It lists every pending and approved booking that overlaps today, with its window, its resources and who submitted it, and it marks the ones that began yesterday or run past today so a time on the list cannot be misread.

If there are no bookings for the day, nothing is sent. It is off until you turn it on and choose the recipients.

SettingsHost only

Project, then Tools, then Bookings holds four things.

Operating hours and the default slot

Operating hours are set per day of the week and are what the board is drawn against: the default is six in the morning to six in the evening, Monday to Friday, with the weekend closed. The default slot duration, in minutes, pre-fills a new booking and starts at sixty.

Bookable equipment and bookable locations

Each resource is switched on here, given exclusive or shared conflict handling, given its custom fields, and given its reference documents. The counts at the top of each card tell you how many of the available machines and locations are currently bookable.

Blocked periods and the digest

Blocked periods are described above. The daily digest is switched on here too, with its recipient list.

The workflow binding is set at organisation level with an optional per-project override, and the organisation can lock it so projects cannot change it. See Binding a workflow to a tool.

PermissionsHost only

• Can view the bookings board and register shows the tool
• Can create and submit booking requests allows making one
• Can approve, reject, and request changes on booking requests is the approver permission
• Can manage all bookings, configure bookable resources, delete bookings is the tool administrator
• Can permanently delete bookings is separate and is not implied by managing

Bookings is one of the few tools with a separate approve permission, and it is worth using. The person who should be deciding whether the crane is free at eight on Thursday is often a foreman rather than whoever administers the tool, and this is what lets you give them the decision without giving them the settings. See How permissions work.

WorkflowsHost only

Submitting a booking starts its workflow, and a booking cannot be created until one is bound.

The default graph does the sensible thing with the case that is not really a request: a booking made by a host manager who could approve it anyway is approved immediately, rather than being sent to themselves. Everything else lands pending and notifies everybody holding the approve permission, and the first of them to respond decides it.

The review has three outcomes. Approve reserves the resources. Request changes and Reject both require a note and both send the booking back to the submitting organisation as one edit-and-resubmit task, which returns it to pending and notifies the approvers again.

Cancelling sits outside the workflow deliberately, because it is an ending rather than a step. Build variations in the workflow builder.