How does i-Reserve assign tables automatically?

You do not have to hand out tables: i-Reserve does it for you. As soon as a reservation is saved, the automatic table assignment — internally the solver — looks for a table that fits and records it. This page explains when that happens, what the assignment looks at, and what you as an administrator can steer.

When does it run?

• When a reservation is saved — new or changed, whether it was made in the admin, through the booking widget or through the API.
• On a status change of a reservation.
• When a reservation is cancelled or marked as a no-show — in short: when it gets a status that does not count towards availability — the table is released again.
• When a reservation is deleted, its assignments are cleaned up.

It only runs when the reservation's object is linked to a floorplan. Without linked objects nothing happens. If an object hangs on more than one floorplan, the first link is used.

What it never touches

The automatic planning leaves three kinds of assignment alone:

• a guest who is seated;
• a reservation that is finished;
• a table you have manually locked.

That is exactly what the Lock table button in the viewer is for: once you have deliberately put a party at a particular table, lock it, and it stays there even if the reservation is changed later.

What it looks at

Hard requirements — it will not budge on these:

• Capacity. The party size must lie between the table's minimum and maximum capacity.
• No overlap. A table cannot hold two reservations at once. The capacity, buffers and tags count: the buffer time before and after a reservation is simply occupied time.
• Required tags. If you specify required tags on a linked object, only tables carrying all of those tags qualify. Mind the flip side: a table without tags then does not fit, even if it would otherwise be perfectly suitable.
• Combinations. Only the table combinations you have defined yourself are used. While a combination is in use, its individual tables are blocked.

Preferences — these make a solution better, but are not mandatory:

• Giving as many guests as possible a table weighs heaviest.
• The smallest fitting table. Empty seats cost points, so a couple lands at a table for two sooner than at a table for four. That keeps your large tables free for large parties.
• The guest's guest preference. When the guest has chosen a preference, tables in the matching zones get a bonus. It is a bonus, not a guarantee: if nothing is free in that zone, the guest is seated elsewhere rather than not at all.

When nothing fits

If no table fits, the reservation still exists but without a table. You see it back in the viewer under Upcoming reservations with the message No table assigned, and you can assign a table yourself. So a reservation is never lost — you get a to-do list instead.

Even if the assignment itself fails, the reservation is always kept: an error in the automatic planning never makes saving a reservation fail.

What you can steer

You determine the outcome through your setup, not through buttons in the assignment itself:

• Set capacities tightly: a minimum of 1 on a table for eight invites waste.
• Use buffers that match your actual turnaround time.
• Define combinations for every party larger than your biggest table.
• Use tags sparingly, and remember that a required tag excludes tables.
• Use the order of your zones to decide where walk-ins land first.

For support there is also a debug screen in which the assignment for a day can be dry-run without saving anything. That screen is meant for investigating a question or a fault, not for daily use.