Squeeze: can we squeeze that meeting in somewhere?

A decision has to be made this week. Four people need to talk, half an hour would be enough. A look at the calendars, however, produces a slot in the week after next.

So the real scheduling begins: could you move your Thursday meeting? Would Friday work too? Has someone taken the other slot in the meantime? A short coordination turns into a small project of its own.

That is what Squeeze is about. The name comes from squeezing in a meeting. Not by having an agent push other appointments aside on its own authority, but by asking specifically whether someone can make room, and handling the coordination through to booking.

Classic scheduling starts with a question of availability: when is everyone free? Squeeze adds a second question: who could make a suitable time possible?

If a shared free slot already exists, Squeeze books it. It gets interesting when the calendars do not line up within the desired period. Then the system looks at times where agreement with as few people as possible would be enough.

The organiser describes what they need and approves the plan. Squeeze then handles the individual requests in Teams, processes replies and checks whether a booking has become possible. The human keeps the decisions about what the meeting is for, who has to attend and whether it is important enough to ask others to move something.

Behind Squeeze there is no indiscriminate round of questions but a fixed order for scoring possible times:

As few people as possible should have to make room. A time requiring two moves never ranks above one where a single move is enough.

The time fits the organiser's constraints as well as possible. This decides when the number of affected people is equal.

As many optional participants as possible would be available. This criterion applies when the previous ones are tied.

The earlier slot wins. That is the final tie-breaker.

The decisive step follows only after that: the best-scoring time determines who is asked first, not necessarily which slot is booked.

For that person, Squeeze bundles the candidate time windows in which their existing commitment blocks a booking. Instead of several messages about single slots, they receive one combined request.

That is more than a question of interface design. A single reply can enable a different slot than the one the search started from.

An example makes the logic tangible. Three times are on the shortlist. In each case exactly one person would have to make room: Thursday at 14:00 and Friday at 10:00 Lena, Thursday at 16:00 Deniz.

Thursday at 14:00 ranks first after scoring, so Squeeze asks Lena first. The message contains both times for which her agreement would help: Thursday at 14:00 and Friday at 10:00.

Lena cannot move anything on Thursday. On Friday it would be possible. Squeeze processes the reply and checks the calendars again. If the Friday slot is genuinely free and still works for all required participants, it is booked.

The meeting therefore lands on what was originally the third option. Deniz was never contacted.

The shortlist is not a rigid checklist. After every reply the scoring is recalculated. That prevents the agent from asking further people for a favour when another route already reaches the goal.

There is an important difference between "I can move something" and an actually available time window. An agreement is first of all a willingness to make room. It does not move the existing appointment automatically.

In addition, other calendars can change during the coordination. A previously free slot can be taken, a conflict can disappear.

Squeeze therefore checks the calendars again before booking. An earlier availability query and a positive reply are not sufficient grounds for a booking. This final check is an essential part of the logic, not just a convenience step.

Squeeze asks one person at a time. Each request stays open for three working hours. After a reply the scoring is redone; without a reply the request window expires before the search continues.

Parallel messages might seem faster. But they could make several people rearrange appointments for a slot that already fails because of someone else's refusal.

The sequential approach deliberately accepts this waiting time. Two consecutive request windows can already take six working hours. "Meetings in minutes" would therefore be the wrong promise. The possible gain is making a timely meeting possible at all and relieving the organiser of the follow-up work.

The stop conditions are part of this too: if no option remains after refusals, Squeeze reports that clearly. If there is not enough time before the set deadline for another round of requests, the decision goes back to the human: extend the deadline or try another day.

When checking availability, Squeeze reads only free/busy information, not the content of existing calendar entries. The agent therefore cannot argue that another appointment is unimportant. It does not know it.

Accordingly the request is not "does this time suit you?". In substance it is: "could you free up this time window?" After all, it is already known that the person is busy then.

Squeeze does not reveal the identity of the other person with a conflict. The number matters because it shows whether one's own agreement would already be enough. The name is not needed for that.

A refusal needs no justification. Agreeing and declining are equally valid options. The goal is not to automate social pressure but to phrase a concrete request as clearly and narrowly as possible.

The effort in difficult scheduling does not come only from the number of messages. It comes from the organiser having to step back in after every reply: open the calendar, compare options, message someone, check again, send the invitation.

Squeeze takes over this loop. In a simplified example with four participants and two conflicts, six actions by the organiser become two. That illustrates the process; it is not a measured productivity figure. The people asked still decide for themselves whether they can make room. And not every search ends successfully.

That is where the technical appeal lies: Squeeze combines fixed prioritisation rules, human decisions and a calendar state that can change during the process. The agent keeps working on its own, but only within clear boundaries.

Squeeze does not make calendars infinitely elastic. It takes over the coordination that normally begins once the search for a free slot ends. Whether a meeting is important enough to make room for stays a human decision.

Want to see how Squeeze scores possible times, asks in Teams and replans after a reply? Get in touch and we will walk you through it.