“In meeting room” requests: setup
A service of the “In meeting room” type is what you order for a meeting: a coffee break, paper and markers laid out, help with the video link, cleaning after the session. A request for such a service is tied not to the room but to a specific booking, so the assignee sees the meeting and the deadline by which everything must be ready. The service is ordered by the organiser of the meeting — from their booking card or from the “Create a request” window; from the booking card their manager or an employee who manages all users can do it too. The service can be made available in all offices or only in selected ones, with a separate assignee for each office.
When this type fits
The hint under the chips describes this type as: “Services related to a specific meeting room and a specific meeting. For example: coffee break before the meeting, room preparation, cleaning before/after, equipment check for the booked time.” The key word is “meeting”: without a booking, a request of this type cannot be submitted at all.
| Task | Which service type to use |
|---|---|
| Lay out a coffee break for the 3 p.m. meeting | “In meeting room” — the request is tied to the booking and carries its time |
| Repair the projector in a meeting room, unrelated to any particular meeting | “In the office” — the request is tied to the room as an object |
| Order stationery for a department | “For employee” — there is no object at all |
Creating the service
What you need: the Super Administrator or Offices Administrator role; the “My requests” module enabled (Manage → Company settings → the “Available functionality” block); an employee to assign as the assignee — or one assignee per office if the service will work in selected offices only.
- Open Manage → Office management → the “Services” tab and click “Add service”.
- In the “Availability” block keep “All offices” and fill in the “Assignee” field, or choose “Selected offices only” and fill in the “Office” and “Assignee” rows.
- In the “Service type” block choose “In meeting room”.
- In the “Service details” block fill in “Service” and, if useful, “Service description”.
- If needed, set the SLA and switch on the “Files and images” field in the “Service request fields” block. The “Due date” field is always on for this type.
- In the “Where to process requests” block keep “Inside UnSpot” or choose “In external ticket system”. For processing inside UnSpot the assignee is required.
- Click “Add”. The service appears in the table with “In meeting room” in the “Service type” column.
“Service type” and “Where to process requests” are set once and cannot be edited afterwards. In the edit form both chip groups are read-only. Everything else stays editable: availability in offices and the assignees, the name, the description, the SLA, the “Files and images” field and the status toggle — and for services with external processing, the ticket-system address, the observers, the email copy checkboxes, the project ID and the priority level as well. To switch the type or the processing method, the service has to be deleted and created again.
This type has no “Service mode” block: private and public modes exist only for “In the office” services. Only a signed-in employee can order a service for a meeting.
Availability in offices and assignees
The “Availability” block decides for meetings in which meeting rooms the service can be ordered and who receives the request. The request’s office is the office the booked meeting room is in.
| Option | What to fill in | Which meetings the service is offered for | Who receives the request |
|---|---|---|---|
| “All offices” | A single “Assignee” field. This option is selected by default | Meetings in any meeting room of the company | This assignee |
| “Selected offices only” | “Office” and “Assignee” rows; a new row is added with the “Add office” button | Meetings in the meeting rooms of the listed offices and of the offices nested one level below them | The assignee of the meeting room’s office row. If there is no such row — the assignee of the parent office’s row |
The rules for the rows, the “Offices” and “Provider” columns of the “Services” table, and what happens when an office is deleted or an assignee is blocked are the same for every service type — they are described in “In the office” requests: setup and QR codes, in the “Availability in offices and assignees” section.
Who can order a service for a meeting
A service can be ordered in two ways:
- from the meeting-room booking card — with the “Request service” button in the “Service” block. The meeting is filled in automatically;
- from the “Create a request” window — the employee picks the service in the “Meeting room services” group and then the meeting in the “Meeting” field. The list contains only meetings they organise, from today and seven days ahead.
For the block with the button to appear on the booking card, four conditions must hold at once. Plus one separate limitation: the block is not shown if the booking was created from a meeting-room display panel, that is, if its organiser is a device. Bookings from Google or Outlook whose organiser is an ordinary employee do show the block.
| Condition | What must be true |
|---|---|
| The module is on | “My requests” in the “Available functionality” block |
| A matching service exists | At least one service of the “In meeting room” type with its status switched on. For processing inside UnSpot that is not enough: the service must have an active assignee — with a blocked employee the service will not appear in the order list |
| The service is available in the meeting room’s office | The service is set to “All offices”, or its settings have a row for the meeting room’s office or for that office’s parent |
| The employee has rights to this booking | They are the organiser of the meeting, or they manage all users, or they are the organiser’s manager |
An ordinary attendee cannot order a service: on the booking card the button is visible only to the organiser, their manager and an employee with the right to manage all users, and in the “Create a request” window everyone sees only the meetings they organise themselves.
Due date, files and SLA
In the “Service request fields” block of an “In meeting room” service, the “Due date” field is always on and mandatory: its toggle and the “Mandatory” checkbox are locked. The second field, “Files and images”, is optional and can be made mandatory too.
| Field | How it works in a request for a meeting |
|---|---|
| “Due date” | The employee picks a date only — the day of the meeting is filled in by default, past dates are unavailable. UnSpot sets the time itself: the end time of the meeting |
| “Files and images” | If the field is on, photos and files can be attached to the request; if it is mandatory, the request cannot be sent without a file. If the field is off, the form has no upload block |
The assignee sees the due date in the request list, in the “Execution” column. If the service has to be delivered by the start of the meeting rather than by its end, say so in the “Service description”: the employee cannot change the time in the due date field. That is also the place to describe what to put in the request text: the number of people, the set of drinks, the serving time.
Services created before this setting existed have “Files and images” switched off. If files need to be attached to meeting requests, switch the field on in the service settings.
For processing inside UnSpot the service window has an SLA block: “Response SLA” with the “Response time, hours” field (1 to 240 hours) and “Completion SLA” with the “Resolution time, hours” field (1 to 720 hours). Both values are set in hours, and the resolution time must be longer than the response time. For now the SLA is only stored in the service settings: it is not shown in the request list or on the request card, overdue requests are not highlighted, and there are no notifications. The details are in “In the office” requests: setup and QR codes, the “Request fields and SLA” section.
What happens when a meeting is moved or cancelled
The request lives together with the booking, and UnSpot keeps it in step when the booking changes. The automation touches only requests that are still in progress: those already in the “Completed” or “Cancelled” status are left alone entirely.
| What happened to the booking | What happened to the request |
|---|---|
| The meeting time changed | The request goes back to the “New” status and the system entry “Booking was changed” is added to its history. The assignee has to accept the request again, for the new time. If the request was already “New”, the status does not change, but the history entry is still added. The due date of the request is not recalculated — it stays as chosen when the service was ordered |
| The meeting was ended early with the stop button | The request is moved to “Cancelled” — the same way as when a booking is deleted, not the way a reschedule works. The status is final; the request cannot be brought back into progress |
| The booking was deleted | The request is moved to “Cancelled” with a system comment. This affects only requests in the “New” and “Accepted” statuses; closed ones are left alone |
| The meeting room was deleted entirely | The request is not cancelled and keeps its status. UnSpot ties such requests to the booking rather than to the room, so deleting the room does not touch them. In the list, the place of the request will read “Booking removed” — you will have to close it by hand |
The automation does not apply to requests with external processing. If the service is processed in an external ticket system, the request immediately gets the final status “Sent”, and moving the meeting does not touch it: the email to the external system has already gone out, and UnSpot does not send a second one. The reschedule has to be communicated to the assignee separately — for instance, by an email to that same ticket system.
Things to keep in mind
| Detail | How to work with it |
|---|---|
| The request is tied to the booking, not to the room | For tasks about the meeting room itself, outside any meeting, create a separate service of the “In the office” type |
| The due date is mandatory, the employee picks only the date, and the time equals the end of the meeting | If the service has to be delivered earlier, for example by the start of the meeting, state it in the “Service description” — the time in the due date field cannot be changed |
| A service with selected offices is offered only for meetings in the meeting rooms of those offices and of the offices one level below | If an employee does not see the service on the booking card, check the “Availability” block and the assignee in the row of the office concerned |
| Services created before the field setup existed have “Files and images” switched off | Switch the field on if photos or a seating plan need to be attached to requests |
| Moving a meeting returns the request to “New”, while ending it early cancels the request | Warn the assignees: a request reappearing in progress is not a duplicate but the result of a reschedule; the due date in such a request stays the same. If the meeting finished early and the service is still needed, the request has to be created again |
| The service type and the processing method cannot be changed after saving | Decide before the first save; to switch, delete the service and create it again |
| A service cannot be deleted while it has requests in the “New” and “Accepted” statuses | Close those requests, or simply switch the service off with the status toggle |
Related articles
- Service requests: overview — which service types exist and which to choose
- “For employee” requests: setup — setting up “For employee” requests
- “In the office” requests: setup and QR codes — setting up “In the office” requests and QR codes
- Processing requests in an external ticket system — processing requests in an external ticket system
- Processing service requests — how requests are processed inside UnSpot
- Service request for a meeting — how to order a service for a meeting
