.svg)
A service request in AskCody Meeting Services is not a message to the kitchen. It is an order attached to the meeting, with a status that changes as the meeting does and an email to the organizer each time. Including, and this is the part worth reading, the two statuses that say the order could not keep up.
This is a feature highlight, not a release announcement. Everything here ships today and is documented in the AskCody Help Center. It is written up now because this week’s blog argues that meeting operations break in the handoff between departments, and this is the mechanism built for exactly that handoff.
Start With The Handoff You Already Do By Hand
Someone books a partner meeting for Thursday at ten and orders lunch for eight. On Wednesday afternoon the meeting moves to two.
In most organizations that is now a phone call. Somebody has to tell the kitchen, and somebody has to check the kitchen heard. The second call is the tell: it exists because the first message was never trusted to arrive.
In AskCody the lunch order is not a message that was sent to the kitchen. It is a service request attached to the meeting, and it has a status. That status is the whole of what meeting services adds here: not a faster way to send the order, but an order that answers back.
What Are The Service Request Statuses In AskCody?
A request ordered from the Services add-in in Outlook moves through a small, deliberate set of statuses, and the organizer receives an email at each change that matters.
Pending when it has reached the provider and nobody has accepted or rejected it yet. Accepted when the provider takes it, or straight away if that provider accepts orders automatically, which is what you want for coffee for four. Rejected when the provider cannot deliver it; a request is never rejected automatically, so a rejection is always a person’s decision. Readied when the provider marks it prepared. Updated whenever the order changes: the organizer edits it, the provider adjusts it, or the meeting is rescheduled or moved to a room the provider delivers to.
The provider hears about the changes that move work: a new request, an update and a cancellation. Move the meeting and the order moves with it. Cancel the meeting and the order is cancelled, and the kitchen is told then rather than at the door with a tray. We call that logic Follow-the-Meeting Intelligence.
Three Handoffs That No Longer Need A Phone Call
A team coordinator at an engineering group orders lunch for eight from the Services add-in for Thursday at 10:00. On Wednesday afternoon she moves the meeting to 14:00 in Outlook. The order moves with it, the kitchen receives the update, and she gets an Updated email instead of ringing the kitchen to check that it heard.
A catering manager at a university starts every morning in the Services Management Portal. When an organizer cancels a Friday workshop on Thursday afternoon, the request is cancelled and he is notified, so his team stops preparing food for a meeting that no longer exists.
An office manager at a law firm moves a client lunch on the morning it is due, after the kitchen has already marked the order ready. The request detaches and she is told so in plain words, so she makes one call, decides with the kitchen what happens to the lunch, and the client sits down to the right meal at the right time.
Which Statuses Mean The Order Could Not Keep Up?
No system completes every handoff, and a system that pretends otherwise is hiding the failures somewhere. AskCody documents two cases where a request stops following its meeting, and in both it says so.
Detached. If the meeting is rescheduled or relocated after the provider has marked the request ready, or after the provider’s preparation deadline has passed, the request detaches: it no longer follows the meeting, and the organizer is told. With a 24-hour deadline, moving a meeting six hours before it starts detaches the order, which is the software equivalent of the kitchen having already started. The same happens when a moved meeting’s room is unavailable at the new time; add an available room and place the request again, and it reattaches.
Cancelled. A request is cancelled when the meeting is canceled, when the location is removed from the Outlook or Teams meeting, or when the meeting moves to a room that declined the invitation or that the provider does not deliver to.
That is deliberate. When an order can no longer be delivered as promised, AskCody hands the decision back to a person instead of letting a default decide in silence. Read the two lists as a workplace lead rather than an administrator: every line is a real way a handoff fails, and every one of them usually reaches you as a surprise at the door. Here it reaches the organizer by email while there is still time to act. The full list is in the overview of AskCody Services notifications.
Recurring Meetings, Where This Matters Most
A weekly board prep or a monthly client review is the highest-volume handoff in most buildings, and the one most likely to be run from memory.
In AskCody each occurrence of a recurring meeting is its own meeting, so services are requested per occurrence rather than once for the series. A series that runs all year rarely wants the same lunch and the same layout in December that it had in February, and one occurrence can change without touching the rest.
One thing to tell your organizers, because it is the most common surprise here. Editing a series with “this and the following events” creates a new series behind the scenes, with new meeting IDs, so the requests made for the old occurrences are cancelled. AskCody sends an automatic email that explains what happened and how to place them again. The walkthrough is in how to request services for recurring meetings, and it belongs in your superuser training rather than in a December surprise.
What Providers Control
The handoff only holds if both sides have real controls, so the provider side is configurable rather than passive. Each provider sets a preparation deadline, with a longer one for items that need it, and opening days, so nothing is ordered for a day the kitchen is closed. Providers set buffer time before and after meetings with services, choose whether orders are accepted automatically or reviewed, and require the fields the organization needs: cost centers, VAT, or your own fields such as a client matter number, which travel with each order.
Which of those controls is switched off in your setup because nobody has revisited it since implementation? That is usually where the remaining manual work is hiding.
One Honest Boundary
Ad-hoc requests, the last-minute orders service staff create directly in the Services Management Portal, are not attached to a meeting. They are labeled so nobody mistakes them for orders from Outlook, and because they have no meeting to follow, they are updated by hand (how ad-hoc requests are labeled). They are a deliberate escape hatch, and the one place where the handoff is still yours to manage.
Key Takeaways
- A service request in AskCody Meeting Services is an order attached to the meeting, with a status: Pending, Accepted, Rejected, Readied, Updated, Detached or Cancelled. The organizer is emailed at each change; the provider hears about new, updated and cancelled requests.
- Move the meeting and the order moves with it; cancel it and the order is cancelled, with the kitchen told then rather than at delivery.
- Two statuses exist for honesty. Detached: the meeting moved after the order was readied, after the preparation deadline, or to a time its room is unavailable. Cancelled: the meeting was canceled, the location removed, or it moved to a room that declined or that the provider does not serve. A person decides what happens next.
- Recurring meetings are handled per occurrence. Editing with “this and the following events” creates new meeting IDs and cancels the old requests; an automatic email explains how to place them again.
- Providers control preparation deadlines, opening days, buffer time, auto-accept and the fields that travel with each order, such as cost center, VAT or client matter number.
