“For employee” requests: setup
A service of the “For employee” type covers tasks that are not tied to a particular place: ordering stationery, calling a courier, asking IT for help. An employee submits such a request from the “Create a request” window, without choosing a desk or a meeting room — they only state the office, the service and what they need. This type has no request object and no service mode; the administrator sets the name and description, the offices where the service is available and who the assignee is in each of them, which fields the request will have and, optionally, SLA times.
When this type fits
When you create a service, UnSpot asks you to pick a “Service type” — it decides where the employee submits the request from and what they fill in. The hint under the chips describes this type as: “General office tasks not related to a specific object or room. For example: granting/revoking access, workplace questions, stationery, general office requests.”
| Service type | Where the request is submitted from | What the request carries |
|---|---|---|
| “For employee” | The “Create a request” window, the “Employee services” group | Office, service and description; a due date and files — if these fields are enabled for the service |
| “In the office” | The object information on the map, the “Create a request” window, or a QR code stuck on the object itself | Additionally the object: desk, parking space, meeting room, office or point of interest |
| “In meeting room” | The card of a meeting-room booking, or the “Create a request” window | Additionally the meeting; for this type the “Due date” field is always mandatory |
Choose “For employee” when the request has nothing to do with a particular object on the map. If the task always concerns a specific desk or meeting room, the other two types suit better — a request of those types arrives with the place already filled in.
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 per office, if different offices have different assignees.
The “Add service” window is split into sections. The steps below follow the order in which the sections appear in the window.
- Open Manage → Office management → the “Services” tab and click “Add service”.
- In the “Availability” section keep “All offices” and pick the “Assignee” — or choose “Selected offices only” and fill in the “Office” and “Assignee” rows. See Availability in offices.
- In the “Service type” section choose “For employee”.
- In the “Service details” section fill in “Service” and, if useful, “Service description”.
- If needed, switch on “Response SLA” and “Completion SLA” and set the times in hours — see the SLA section.
- In the “Service request fields” section decide whether the request will have “Due date” and “Files and images” and whether they are mandatory — see Service request fields.
- In the “Where to process requests” section keep “Inside UnSpot” if your own employees will handle the requests in UnSpot. The “In external ticket system” option is covered in a separate article.
- Click “Add”. The service appears in the table with “For employee” in the “Service type” column.
“Service type” and “Where to process requests” are set once and cannot be edited afterwards. In the “Edit service” window both chip groups are read-only. Everything else can be changed after creation: availability in offices and assignees, the name and description, SLA, the request fields. To switch the type or the processing method you have to delete the service and create it again, and deletion is blocked while the service has requests in progress. Decide before the first save.
This type has no “Service mode” section — private and public modes exist only for “In the office” services. A “For employee” request is always submitted by an employee who is signed in.
Service fields
| Field | Required | Limits and what it controls |
|---|---|---|
| “Service” | Yes | From 2 to 255 characters. This is what the employee picks in the “Create a request” window, so write something that makes sense without context. The name is unique: the check ignores case, and a duplicate returns the error “A service with this title already exists” |
| “Service description” | No | Up to 2000 characters. Shown to the employee under the selected service — put here what helps them fill the request in correctly: what to mention in the text, what the service does not cover, how long fulfilment usually takes |
| “Assignee” | Yes, for processing inside UnSpot | Sits in the “Availability” section: one field with “All offices”, or one field per office row with “Selected offices only”. The assignee receives the email about a new request and processes it |
Availability in offices
The first section of the service window is “Availability”. It decides two things at once: in which offices employees see the service, and who receives a request from each office.
| Option | What you fill in | Where the employee sees the service | Who receives the request |
|---|---|---|---|
| “All offices” (default) | A single “Assignee” field | In any office — even when the employee has not picked an office in the “Create a request” window | Always the same assignee |
| “Selected offices only” | “Office” and “Assignee” rows; a new row is added with “Add office” | Only when the employee has picked one of these offices or an office nested in it one level down | The assignee of the office stated in the request; if that office has no row — the assignee of its parent office |
Rules for the rows with “Selected offices only”:
- An office can be a building or a floor — a city cannot be selected in the tree.
- Each office is listed once. An office already chosen in another row is unavailable in the office tree; if a duplicate still reaches the server, saving fails with “Office is specified more than once”.
- Each row needs an assignee when requests are processed inside UnSpot. With processing in an external ticket system a row may have no assignee.
- At least one row is required. When editing a service, the last row cannot be removed — its delete icon is inactive.
- The option can be switched after creation — the availability chips are not locked in the “Edit service” window.
How the assignee of a request is chosen. For a “For employee” request the employee states the office themselves — the “Office” field in the request form is mandatory. UnSpot looks for that office’s row and gives the request to its assignee. If the office has no row, the row of its parent office is used — exactly one level up; UnSpot does not go any higher. So a row set up for an office also serves requests from offices nested in it one level down.
What it looks like in the services table. In the “Offices” column an “All offices” service reads “All offices”, a per-office service shows the short names of its offices, and if no row is left it reads “No offices selected”. In the “Provider” column a per-office service shows its first assignee and a “+N” counter — how many other distinct assignees are set. Hovering over the counter opens the list of offices with their assignees and the note “The request is assigned to the assignee responsible for the office where it was created”.
What UnSpot changes in the rows by itself. When an office is deleted, its rows disappear from every service. When an employee is blocked or deleted, they are removed both from the common “Assignee” field and from every office row; the row stays, but without an assignee. What happens to the requests is described in The assignee.
Response and completion SLA
The SLA section exists only for services processed “Inside UnSpot”: when you choose “In external ticket system”, it disappears from the window, and SLA cannot be saved for such a service. Both toggles are off by default.
| Toggle | Field | Value when switched on | Allowed values |
|---|---|---|---|
| “Response SLA” | “Response time, hours” — within how many hours the assignee must accept the request | 2 | From 1 to 240 hours |
| “Completion SLA” | “Resolution time, hours” — within how many hours the request must be completed | 48 | From 1 to 720 hours |
Both times are set in hours. If both toggles are on, the resolution time must be strictly greater than the response time — with equal or smaller values the window shows the error “Completion SLA cannot be shorter than Response SLA”.
What SLA does today. The times are saved in the service settings and visible in the “Edit service” window. UnSpot has no highlighting of overdue requests, no notifications and no escalations based on SLA — keeping track of the deadlines is still up to you and the assignees.
Service request fields
The “Service request fields” section decides what the employee can state in the request besides the description. Each field has a toggle and a “Mandatory” checkbox; the checkbox is available only while the field is on.
| Field | What appears in the request | If “Mandatory” is ticked |
|---|---|---|
| “Due date” | A field with the date by which the request must be completed. The employee picks a date only, past days are unavailable; UnSpot sets the time itself — 18:00 on the chosen day | The request cannot be sent without a date |
| “Files and images” | A block for uploading files to the request | The request cannot be sent without a file — the form shows the error “A file is required to submit the request” |
Both fields are off for a new service. Which files can be attached and how many — see Service request for an employee.
If employees cannot attach a file after the update. For services created before this section appeared, “Files and images” is off, and “Due date” is on only for “In meeting room” services. If photos used to be attached to requests for a service, open it and switch “Files and images” on.
Who sees the service in the “Create a request” window
Requests of this type are submitted from the “Create a request” window. It is opened by the “Create a request” button in the UnSpot header, by the item of the same name in the “Requests” section of the menu, and by the button on the “Service requests” page. The window has an optional “Office” field, a “Search services” box and groups of services; services of this type are in the “Employee services” group. A service is listed only when all conditions are met:
| Condition | What must be true |
|---|---|
| The module is on | “My requests” in the “Available functionality” block |
| The service is on | The service’s status toggle in the table is switched on |
| The service can be processed | There is an active assignee — the common one or in an office row; or processing in an external ticket system is selected |
| The service is available in the chosen office | An “All offices” service is always shown. A “Selected offices only” service is shown only when the employee has picked in the “Office” field one of its offices or an office nested in it one level down, and that office or its parent has an assignee |
Until an office is picked in the window, only “All offices” services are listed. So “the service is missing from the list” often just means the employee has not stated an office. If the search finds nothing, the window shows “Nothing found”.
The button in the header and the menu is not always there. It is shown when at least one condition holds: the visitor pass module is on, or — with the “My requests” module on — the company has at least one working service of the “For employee” or “In the office” type. “In meeting room” services alone do not bring the button up. On the “Service requests” page the “Create a request” button is always present.
The assignee
- One assignee per office. With “All offices” there is one assignee for the whole service, with “Selected offices only” — one for each listed office. You cannot assign several employees to one office; the load can be split by office or by creating separate services.
- Any active employee can be an assignee — no special role is needed. The picker offers everyone who is not blocked and not deleted.
- The assignee can be changed at any time — in the “Edit service” window. The change affects new requests only: in requests that already exist the assignee is changed separately, inside the request itself, with “Change provider”. This is available to the Super Administrator and Office manager roles, and only while the request is not “Completed” or “Cancelled”.
- This variant has no observers. The “Request progress observers” field appears only when requests are processed in an external ticket system.
What happens if the assignee is blocked or deleted. UnSpot removes them from the service — from the common field and from the office rows. All unfinished requests of that assignee go back to the “New” status, the assignee field in them is cleared, and a system entry is added to the status history: “The service provider for this request is inactive. Please contact the administrator to assign a new provider or create a new request.” What happens next depends on the availability option:
- “All offices” — the service is left without an assignee: the “Provider” column shows “No provider assigned”, the status toggle becomes inactive and no new requests can be submitted for the service.
- “Selected offices only” — only that employee’s rows are left without an assignee. Requests from such an office go to the assignee of the parent office, if one is set; if not, the service is not offered in that office. The status toggle becomes inactive when no row has an active assignee left.
To bring the service back where it disappeared, assign a new assignee.
Switching off and deleting a service
The services table has a status toggle — the gentle way to stop accepting requests.
| Action | What happens | When to use it |
|---|---|---|
| Switch the status toggle off | The service is no longer offered in the “Create a request” window. Requests that already exist stay and are processed as usual | The service is paused: the assignee is on holiday, the contractor is being replaced |
| Delete the service | The service disappears from the list and from the “Create a request” window. It cannot be restored through the interface | The service is not needed at all any more |
Deletion is confirmed with the question “Delete this service?”. If the service has requests in the “New” or “Accepted” status, UnSpot will not delete it and shows the “Can’t be deleted” dialog. It offers two ways out: deactivate the service so that no new requests are created for it, or close the current ones first — accept and complete them, or cancel them. Requests in final statuses do not block deletion.
Things to keep in mind
| Detail | How to work with it |
|---|---|
| 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 “Selected offices only” service is not visible until the employee picks an office in the “Create a request” window | If everyone needs the service, keep “All offices”; if it is per office, tell employees to pick the office first |
| SLA is saved, but UnSpot does not highlight overdue requests or send notifications | Treat SLA as an agreement with the assignees and track deadlines in the request list |
| The row order in the services table is not defined, and the screen has no sorting or filters | With many services, navigate by name rather than by position in the list |
| The employee sees the service name in the “Create a request” window, and the description only after selecting the service | Put the important part into the name: employees use the list far more often than the description |
| Turning the “My requests” module off removes the “Services” tab entirely | Services of the other two types disappear from setup with it — the module is shared by all three |
| An employee can cancel their own request, but cannot accept or complete it | This is normal: cancelling is available to the author, processing to the assignee |
Related articles
- Service requests: overview — which service types exist and which to choose
- “In the office” requests: setup and QR codes — setting up “In the office” requests and QR codes
- “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
- Service request for an employee — how an employee submits such a request
