“In the office” requests: setup and QR codes
A service of the “In the office” type handles tasks tied to a specific object: a socket by the desk is dead, the meeting room has run out of paper, a parking space needs cleaning. A request for such a service always carries the object, so the assignee knows immediately where to go. The service can be made available in all offices at once or only in selected ones — with a separate assignee for each office. This type has something the other two do not: a service mode. In public mode a request can be submitted without signing in — via a QR code stuck on the object itself.
When this type fits
The hint under the chips describes this type as: “Tasks related to physical office assets. For example: setup and repair of equipment, furniture, engineering systems, replacement of printer supplies.” Pick it when the request always concerns a specific place and the assignee needs to know which one.
A request for such a service can be submitted in three ways:
- from the object card — the employee clicks a desk, a parking space, a meeting room, an office or a point of interest on the map, opens its information card and clicks “Request” in the row of actions at the bottom. The object is filled in automatically, and a different one cannot be picked in the form;
- from the “Create a request” window — the employee picks the service in the “Office services” group and chooses the object in the form with the “Find a resource” button;
- by the QR code on the object itself — this route is available in public mode only.
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.
The “Add service” window is made of blocks that go from top to bottom in this order.
- 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. The details are in the section below.
- In the “Service type” block choose “In the office”.
- In the “Service mode” block that appears choose “Private” or “Public” — the difference is described below.
- In the “Service details” block fill in “Service” and, if useful, “Service description”.
- If needed, set the SLA and switch on extra fields in the “Service request fields” block — see “Request fields and SLA”.
- 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 the office” 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 can be changed after saving: availability in offices and the assignees, the service mode, the name and description, the SLA and the request fields.
Availability in offices and assignees
The “Availability” block comes first in the service window and settles two questions at once: in which offices employees see the service and who receives the request. There are two options.
| Option | What to fill in | Where the service is offered | Who receives the request |
|---|---|---|---|
| “All offices” | A single “Assignee” field. This option is selected by default | In every office of the company | This assignee — whichever office the request comes from |
| “Selected offices only” | “Office” and “Assignee” rows; a new row is added with the “Add office” button | In the listed offices and in the offices nested one level below them | The assignee of the row that lists the request’s office. If there is no such row — the assignee of the parent office’s row |
The request’s office is the office of the object the request is about: for a desk or a meeting room — the office they are in; for a request about an office itself — that office; for a parking space or a point of interest — the office they belong to. The full table is in “Which objects a request can name”.
Rules for the rows:
- one office cannot be listed in two rows — an office already chosen in another row is unavailable in the tree;
- for processing inside UnSpot the assignee is required in every row; for processing in an external ticket system a row can be left without an assignee;
- when editing a service, the last row cannot be removed — to drop the office restriction, switch to “All offices”.
In the “Services” table availability shows in the “Offices” column: a service for all offices reads “All offices”, a service with selected offices shows their short names. In the “Provider” column such a service shows the first assignee and a counter for the rest, for example “+2”; the tooltip on the counter lists the office and assignee pairs.
UnSpot keeps the setup up to date by itself:
| What happened | What happened to the service |
|---|---|
| An office was deleted | Its row disappears from the service settings. If no rows are left, the “Offices” column shows “No offices selected” |
| The assignee’s account was blocked | They are removed both from the “Assignee” field and from every office row. If no row has an assignee left, the assignee column shows “No provider assigned” |
The service status toggle is inactive while the service has no valid assignee. For processing inside UnSpot there must be an active assignee in the “Assignee” field or in at least one office row; for external processing with selected offices — at least one row. A service with an incomplete setup is greyed out in the table.
Request fields and SLA
The “Service request fields” block holds two extra form fields. Each is switched on with its own toggle, and the “Mandatory” checkbox next to it makes the field required. “Mandatory” cannot be ticked for a field that is switched off. On a new service both fields are off.
| Field | What appears in the request form |
|---|---|
| “Due date” | A date by which the request must be completed. Past dates are unavailable; UnSpot sets the time itself — 18:00 on the chosen day |
| “Files and images” | Uploading photos and files to the request. If the field is mandatory, the request cannot be sent without a file |
The field setup applies wherever a request for the service is submitted — on the object card, in the “Create a request” window and on the public QR page. Services created before this setting existed have “Files and images” switched off. If employees can no longer attach a photo to a request, switch the field on in the service settings.
The SLA block is visible only while “Inside UnSpot” is selected in “Where to process requests”: no SLA is set for an external ticket system. The block has two toggles, both off by default.
| Toggle | Field | Value when switched on | Allowed range |
|---|---|---|---|
| “Response SLA” | “Response time, hours” — within how many hours the assignee must accept the request | 2 | 1 to 240 hours |
| “Completion SLA” | “Resolution time, hours” — within how many hours the request must be completed | 48 | 1 to 720 hours |
Both values are set in hours. If both SLAs are on, the resolution time must be longer than the response time — otherwise the form shows “Completion SLA cannot be shorter than Response SLA”. 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 SLA breach notifications.
Service mode: private and public
The “Service mode” block exists only for the “In the office” type. “For employee” and “In meeting room” services do not have it at all — there the request is always submitted by a signed-in employee. The mode can be changed after the service is saved.
| Mode | Hint in the interface | What it means in practice |
|---|---|---|
| “Private” | Users must sign in to access the service and submit a request. | The request is submitted only inside UnSpot — from the object card or from the “Create a request” window. The initiator is always known: they are shown in the request, receive status emails and can cancel their own request |
| “Public” | Users can access the service and submit a request without signing in. | Submission by QR code becomes available on top of that. Such requests are anonymous: they have no initiator |
Public mode does not mean “the service is visible to all employees” — it means “a request can be submitted without signing in”. Which offices the service is offered in is decided by the “Availability” block, not by the mode. Public mode is needed where requests come from people who have no UnSpot account: visitors, tenants, contractors, staff on production floors without work computers.
Which objects a request can name
Technically an “In the office” service accepts seven object types, but only five are usable: two have no entry point in the interface. The same five are found with the “Find a resource” button in the “Create a request” window, and QR codes are exported for the same five. The last column shows which office UnSpot treats as the request’s office: it determines the assignee, and on the object card and the public QR page also the list of available services.
| Object | Request from the card on the map | QR code for the object | Request’s office |
|---|---|---|---|
| Desk | Yes | Yes | The office the desk is in |
| Parking space | Yes | Yes | The parking space’s office |
| Meeting room | Yes | Yes | The office the meeting room is in |
| Office | Yes | Yes | That office itself |
| Point of interest | Yes | Yes | The point of interest’s office |
| Locker | No | No | The locker’s office |
| Locker cell | No | No | The office of the locker the cell belongs to |
Lockers and their cells are in the table on purpose: the service itself accepts such objects, but a request for them cannot be submitted from the interface. There is no request button on the locker and cell cards, the object search in the “Create a request” window does not find them, and these resource types are absent from the QR export for service requests as well. If the task concerns a locker, file it as an office request or as a “For employee” request and name the locker in the description.
Exporting QR codes
QR codes are exported from the neighbouring tab of the same section: Manage → Office management → the “Resources report” tab.
- In the first list — labelled “Please select the type of report” — choose “QR codes of resources (service requests)”. Do not confuse it with its neighbours: “QR codes of resources (booking check-in)”, “(resource information)” and “(map location)” lead to other UnSpot screens, not to the request form.
- In the second list, select the offices. It is labelled “No space” — that is the placeholder of an empty field, not a ready value. Formally the field is optional, but without it the list comes back empty: see the warning below.
- In the third list — it appears after the report type is chosen and is labelled “Select the type of resource” — pick the resource type: “Desk”, “Parking space”, “Meeting room”, “Office” or “Points of interest”. This report has no “All” value; one type is exported at a time.
- Click “Generate report”. The table fills with resources of the selected type.
- Tick the rows you need — while nothing is selected, the “Download” button stays inactive.
- Click “Download”. The browser saves the archive qr-codes.zip.
If no offices are selected, the table stays empty and UnSpot does not explain why. UnSpot does not mark required fields in advance: there is no asterisk and no highlight, and the message “This field is required” appears only under the two lists that really are required, and only after the button is clicked. The office filter is not one of them, so an empty result is easy to read as “there are no resources of this type”. For desks, parking spaces, offices and points of interest, nothing is returned without selected offices; for meeting rooms, only those that belong to no office are returned. The rule is simple: always select the offices.
Inside the archive, files are arranged in folders named after the offices, and the file name is {Type}_{Resource name}.svg. Top-level resources that have no parent office go into a folder with a service name made of a single underscore. If both the type and the name coincide inside one folder, a number is appended to the name: (2), (3) and so on; identical names in different offices do not collide, they sit in different folders. The sheet format is SVG: the card itself is vector, while the QR code inside it is raster, so do not scale the sheet beyond its original size when printing.
What is printed on a QR sheet
There are four elements on the sheet:
- a background with rounded corners;
- the resource name — in a large font, in the company brand colour if one is set in the settings;
- the QR code itself;
- the company logo from the settings, or the UnSpot logo if none is uploaded.
There is nothing else on the sheet — no office, no floor, no resource type, no link address, no export date. The type and the office exist only inside the archive: in the file name and the folder name. Once printed, that information is lost.
Hence a practical consequence: if different offices have resources with identical names, their sheets will be indistinguishable. Print batches office by office and do not mix them, and write the office and the floor on the back or on the packaging. More reliable still — give resources names that are unique across the whole company from the start.
The public request form
A QR code leads to the public request page. It opens without signing in and contains the object card, a service selector and a description field. The “Due date” and “Files and images” fields appear only if they are switched on for the selected service; as in the internal form, the due date is a date, and UnSpot sets the time to 18:00.
This form has two properties worth knowing before you print the first batch of codes.
| Property | What it looks like | How to work with it |
|---|---|---|
| The list shows the public services available in the object’s office | The list includes active public services set to “All offices” and those whose settings list the object’s office or its parent office. Services set up only for other offices do not appear | If a public service is needed only in some offices, choose “Selected offices only” for it. Give services for all offices names that make sense outside the context of a particular office |
| The request is anonymous | The form asks for no name, no phone and no email. In the console the initiator of such a request is shown as “No user data available” | Ask people to describe the problem in detail: there will be no way back to the requester. It is worth using the “Service description” to ask them to leave a contact in the request text if one is needed |
The requester gets neither a request number nor a link to it: they will not be able to check the status later without signing in. The public page has a “Sign in” button — an employee of the company can authenticate and submit the same request under their own name, and then it appears for them on the “Service requests” page.
Things to keep in mind
| Detail | How to work with it |
|---|---|
| The service type and the processing method cannot be changed after saving; the service mode, availability in offices and the assignees can | Wrong mode or offices — just correct the setting; wrong type — the service has to be created again |
| A service with selected offices works in them and in the offices nested one level below | The service does not reach deeper into the tree. If offices are nested several levels deep, add a row for the level you need |
| The assignee of an office row was blocked, and the row is left without an assignee | For processing inside UnSpot the service stops being offered in that office unless the parent office also has a row with an active assignee. Assign a new assignee in the row |
| Services created before the field setup existed have “Files and images” switched off | If photos need to be attached to requests, switch the field on in the “Service request fields” block |
| The SLA is stored but not tracked | Do not count on overdue highlighting or notifications — track deadlines in the “Execution” column of the request list |
| A QR export with no offices selected silently returns an empty list | Always select the offices before clicking “Generate report” |
| The “Download” button does nothing while no row is ticked in the table | Tick the resources you need or select them all — this is a separate step after generating the report |
| Switching a service from public to private does not disable printed codes | The link keeps working, but the service disappears from the list on the public page. If no public service is left for the object’s office, there will be nothing to choose |
| The “Request” button is in the object information card even when no “In the office” service is available for its office | The employee will open a form with an empty service list. This also happens when services exist but are set up only for other offices. Check the availability before telling the team about this route |
| A request can be submitted for an object that is later deleted | UnSpot moves the still-open requests of that object — those in the “New” and “Accepted” statuses — to “Cancelled” and adds a system comment. Requests that are already closed are left alone |
Related articles
- Service requests: overview — which service types exist and which to choose
- “For employee” requests: setup — setting up “For employee” requests
- “In meeting room” requests: setup — setting up “In meeting room” requests
- Processing requests in an external ticket system — processing requests in an external ticket system
- Processing service requests — how requests are processed inside UnSpot
- Request for an office object and by QR code — how to submit a request for an object and by QR code
