Plan a room booking grid to identify overlapping requests

A request for a room can look clear on its own and still collide with another request for the same space. A room booking grid makes those collisions visible by placing each requested period beside the others for that room. It is a review aid, not a record of approval. Before anyone decides which request can proceed, keep the original times, identify the pairs that overlap, and mark anything the grid cannot settle.

Consider a fictional set of requests for Alder and Birch, two rooms, on October 8, 2026. All times below use the same local clock on that date. Each entry is a proposed use, not a confirmed reservation. The example includes a partial overlap, a request entirely inside another, two identical requests, periods that meet at a boundary, and records that need clarification. Those differences matter because a crowded-looking row does not tell you which question to ask.

Shared Booking Review Starts With The Original Requests

Copy the identifying information before drawing blocks. In this example, each request has an ID, a room, a start, and a finish. Keep the ID on every mark you add to the grid. If someone changes a request later, you should be able to identify the original entry and the particular comparison that needs another look. A name written across a colored bar is much harder to trace when several requests arrive for similar times.

• A1 requests Alder from 9:00 a.m. to 10:30 a.m.; A2 requests Alder from 10:00 a.m. to 11:00 a.m.
• A3 requests Alder from 9:30 a.m. to 10:00 a.m.; A4 requests Alder from 9:00 a.m. to 10:30 a.m., the same period as A1.
• A5 requests Alder from 10:30 a.m. to 11:15 a.m. A6 names Alder and a start of 11:30 a.m. but gives no finish.
• B1 requests Birch from 10:00 a.m. to 11:00 a.m.; B2 requests Birch from 11:00 a.m. to noon.
• U1 specifies 10:15 a.m. to 10:45 a.m. but does not clearly identify a room.

The incomplete entries belong in the request inventory even though they cannot receive a full conflict verdict. A6 might extend into a later request not shown here; the missing finish prevents that comparison. U1 might concern Alder, Birch, or another space. Assigning it to a room by guess would make the grid look more certain than the underlying requests. Label both entries as unresolved and ask for the missing fields before treating their apparent placement as reliable.

Give the inventory a single date and a stated clock basis. If a real request supplies a date or time that does not fit the stated basis, preserve its wording and seek clarification rather than quietly converting it. The grid is only as precise as its inputs. Likewise, do not turn a submitted request into a confirmed reservation merely because you have drawn it on a shared page.

Shared Booking Review Needs Exact Boundaries

Separate Alder and Birch into distinct rows or panels, then write the time boundaries where the requests begin or end. For Alder, the relevant marks in the complete entries are 9:00, 9:30, 10:00, 10:30, 11:00, and 11:15 a.m. Labeling those marks lets a reader see exactly where the set of active requests changes. Birch has its own 10:00 a.m., 11:00 a.m., and noon boundaries. Its marks can share a visual clock with Alder without merging the two rooms into one resource.

Choose a scale people can read, but preserve the written start and finish beside each ID. If a block is too small to show a boundary accurately, record the exact time in the accompanying list and mark the sketch as approximate. A narrow bar should never turn a 10:30 a.m. finish into an apparent 10:00 a.m. finish. This is particularly important when someone will use the picture to distinguish an overlap from two requests that only touch.

A paper grid works for a small set. If you prefer to prepare a room booking grid on a computer, the cataloged Dell Inspiron laptop is one optional device for that preparation. The comparison itself does not depend on that model, included booking software, or an automatic conflict alert. Keep a legible list of the source requests alongside whatever visual format you choose.

Shared Booking Review Compares Requests Within Each Room

Now inspect each pair of requests for Alder that has complete times. Two requested periods overlap when they cover some of the same time before either ends. A1 and A2 overlap from 10:00 to 10:30 a.m.; A1 starts earlier, while A2 finishes later. That is a partial overlap. A3 is entirely inside A1, from 9:30 to 10:00 a.m. A bar for A3 might be visually hidden under the longer A1 bar if you draw both in the same lane, so use separate marks or write both IDs in the occupied segment.

A4 has exactly the same stated room and period as A1. Treat the matching times as two distinct requests unless the source records establish otherwise. Its period also overlaps A2 and contains A3. A2 meets A3 at 10:00 a.m., with no stated time before that boundary when both are active. Keeping the IDs separate prevents an identical pair from disappearing during a visual cleanup and prevents a touching pair from being misreported as a positive-time overlap.

A5 starts at 10:30 a.m., precisely when A1 and A4 finish, but A2 continues until 11:00 a.m. The A2 and A5 pair therefore overlaps. The A1 and A5 pair, and separately the A4 and A5 pair, only meet at a boundary. One short request can have a different relationship to each of its neighbors. Check pairs rather than assigning a single status to the whole row.

For Birch, B1 finishes when B2 starts at 11:00 a.m. They touch under their written times. B1 also shares clock time with some Alder requests, but that does not create a same-room conflict: the requests name different rooms. The unclear room on U1 is a different matter. You cannot use the separate-room distinction for U1 until someone specifies its room.

When the row gets dense, read it in intervals between labeled boundaries. Alder has A1 and A4 from 9:00 to 9:30 a.m.; A1, A3, and A4 from 9:30 to 10:00 a.m.; and A1, A2, and A4 from 10:00 to 10:30 a.m. From 10:30 to 11:00 a.m., A2 and A5 remain. After 11:00 a.m., A5 is the only complete Alder request shown until 11:15 a.m. This interval view exposes containment without requiring the reader to judge bar widths by eye.

Shared Booking Review Leaves Touching Requests Conditional

A finish at the same written moment as the next start differs from the overlaps above. If the booking owner's rule treats the finish as the point at which the first period ends and the next period can begin, the two written periods have no positive-time intersection. Whether that arrangement is usable in practice is a separate question. The room might require a changeover, or the requested finish might include activities that continue up to that moment. Do not add an allowance or assume one is unnecessary when no rule has been supplied.

Ask the person responsible for the booking rules what a requested finish and start mean, and whether back-to-back uses of the particular room are acceptable. Apply the answer to A1/A5, A4/A5, and B1/B2 rather than marking them automatically clear or conflicting. Keep the unanswered question visible on the grid. A label such as “touching; changeover rule unknown” is more useful than coloring those pairs green when nobody has checked what the boundary permits.

An unmarked stretch in the drawing also needs care. It says only that the complete requests copied into this example do not cover that stretch. It does not establish that the room is available: A6 has no finish, U1 has no settled room, and the grid may not contain every submitted or confirmed use. A useful annotation states what was compared and what remains outside the comparison. That keeps a visual convenience from becoming an accidental availability promise.

Shared Booking Review Ends With A Pair List

Once the picture is legible, write down the result in terms of request IDs. For Alder, the positive-time overlap pairs are A1/A2, A1/A3, A1/A4, A2/A4, A2/A5, and A3/A4. The A1/A4 entry records identical periods; A1/A3 and A3/A4 record containment. The pairs A1/A5, A4/A5, and A2/A3 have only touching boundaries under the written times. In Birch, B1/B2 touch. These labels describe the submitted intervals; they neither grant a request nor select which requester should change plans.

List the unresolved items immediately after the pairs: obtain A6's finish, identify U1's room, and confirm the treatment of touching boundaries. If a clarified record changes a start, finish, date, or room, compare that entry again with requests for its stated room. Preserve the revised entry's identity so readers can tell why the issue list changed. There is no reason to erase an earlier conflict merely because someone has suggested an alternative time that has not yet become the requested time.

For a shared booking review, show the request inventory, the room-separated grid, and the pair list together. A cataloged Tiburn board is an optional display for discussing the picture with a group if the setting is suitable; the linked shared booking review product page describes that device. No connection to the Dell laptop is assumed. What matters in the discussion is that participants can read the IDs and exact times, including the records held for clarification.

Calculate Elapsed Time Only For A Different Question

Conflict review asks whether periods for the same room intersect. It does not require the length of every request. If someone later needs to calculate elapsed time for a request, that is a separate task; the related guide on how to calculate elapsed time addresses duration across midnight. Keep duration work out of this single-date example so a room conflict does not get mistaken for a problem about how many hours one request spans.

Hand the booking owner an annotated grid with the original request IDs, the specific overlapping pairs, the touching pairs awaiting a rule, and the entries awaiting missing information. Ask them to clarify those items against the actual room process before anyone treats the drawing as a reservation decision. The room booking grid has done its job when it makes the open questions easy to find without answering them on someone else's behalf.