Automating Service Requests: Service Catalog and Approvals

Why automate service requests at all

When service requests live in emails, chats and verbal agreements, they quickly become noise. One employee posts in a group chat about stationery, another calls about a repair, a third forwards an email “just in case” to IT. In the end, every department has its own “queue” but there is no overall picture.

Without a single service catalog, requests get lost and duplicated. A message can be sent to the wrong person, drown in a thread or arrive at several addresses at once. Executors end up doing the same work twice, and the requester doesn’t know what’s happening: whether the request was accepted, who’s responsible, and when it will be ready.

Automation isn’t about having a “system” for its own sake, but about tangible improvements: faster start of work, transparent status and owner, easier deadline control, reliable reporting on bottlenecks and consistent service rules without unnecessary conflicts.

Usually several departments are involved at once: HR (onboarding, certificates, access), IT (accounts, software, equipment), Facilities (repairs, furniture, passes), Security (zone access, approvals), Finance (limits, purchases, confirmations).

Imagine: a new employee starts on Monday. HR asks IT to issue a laptop and account, Facilities prepares the workspace, Security issues a pass, Finance confirms purchases if something is missing. If all this goes through chats, there’s almost always a “missing step.” In organizations with distributed structures and strict procurement and access rules — for example, in manufacturing or the public sector — a single catalog and clear approval rules become not a convenience but a necessity.

Which requests to include first

Start with requests that repeat weekly and most often get lost in conversations. That gives quick wins: less chaos, clear deadlines, straightforward reporting.

Typically the first set includes three blocks:

• Stationery and supplies: ordering, checking limits, issuing from stock.
• Access: system and folder rights, roles, temporary access.
• Repairs and maintenance: equipment (PCs, printers), office issues (lighting, furniture), Facilities requests.

Immediately distinguish an incident from a request. An incident is when something broke right now and blocks work (for example, the printer in reception won’t print). A request is a planned action (for example, configure a new role or issue a mouse). This distinction affects priority, deadlines and the number of required approvals.

To keep the start simple, keep each form minimal. If there are too many fields, people will go back to messengers.

Usually it’s enough to ask: who requests and for which department (and a contact for clarifications), what exactly is needed (position, system, item, quantity or access level), when it’s needed (urgent or scheduled), the reason for approval (limit, manager, project, order) and the location (office, room, warehouse, remote access).

Example: an employee needs access to a shared folder for two weeks. The form only needs the folder, role (read or edit), duration and the manager for approval. That’s faster than debating details in emails, and later it’s easy to check who granted the access and when it must be revoked.

Single service catalog: a simple structure without excess

A single catalog helps the employee know where to send the request and how to name the problem. They pick a service, fill a clear form, and the request goes down the correct route.

It’s easiest to organize the catalog by who actually performs the work, not by internal department names. At the start, four sections are usually enough: IT (access, equipment, software), Facilities (supplies, repairs, passes), HR (certificates, leave, onboarding) and Security (zone access, CCTV, inspections). Keep 5–15 most common services inside each section and add others later based on actual need.

A service card should answer user questions before they create the request: what it is and when it’s needed (1–2 sentences), expected time to complete and what it depends on, conditions (for example, manager approval or budget), and what the result will be. If there’s any charging, give at least an estimate.

Keep the form short. Make only the fields mandatory that the executor cannot start without: location, contact, what exactly is needed, requested date, and attachment (if required). It’s better to make the rest optional and collect them later than to receive “empty” requests with made-up data.

Hints solve half of the quality problems. Instead of a field named “Comment,” give an example: “Specify printer model and office.” For system access, the hint can ask for “Full name, department, role, access duration.”

To avoid dozens of similar services, agree on naming rules. A simple set works well: start with one verb (“Issue”, “Replace”, “Open access”), one service — one outcome (no “and also”), and move synonyms into keywords. Quarterly reviews help: remove duplicates and services no one chooses.

Example: instead of “Stationery: paper”, “Stationery: pens”, “Stationery: staples”, keep one service “Order stationery” with a dropdown and hints about limits. The catalog stays short and users are less likely to make mistakes.

Approval routes for different departments

An approval route answers: who must give the go‑ahead before work starts. In service request automation it’s better to base this on roles, not on name lists. People change, roles do not: requester, manager, service owner, executor.

Don’t confuse approval with notification. Approval stops the request until a decision is made. Notification simply informs “request created” or “work completed” without an approve button.

How to handle different rules for departments and branches

Differences between teams and sites usually come down to budgets, access and responsibility. It’s more convenient to define rules by request attributes: department, branch, cost, access type, criticality.

Example: in the central office stationery up to the limit is approved by the manager, and above the limit the procurement owner is added. In a branch the same request can go through a local admin because they handle delivery and stock locally.

When one approval is enough and when a chain is needed:

• Low risk and standard service — usually the manager is sufficient.
• Costs above the limit or non‑standard requests — add the service owner or finance control.
• Access to sensitive systems — chain: manager -> system owner or security.
• Repair causing downtime — notify IT and require manager approval.

How to record decisions

To avoid disputes later, save the decision in the request card: who approved, when and on what grounds. Grounds can be simple: chosen reason, a comment, budget number or a reference to internal rules (as text).

If an approver rejects a request, they should state a reason and the next step (for example, “use another service” or “clarify model and amount”). That keeps the process clear even when people change.

Roles, responsibilities and deadlines

The most common failure at the start is not the request form but unclear agreements: who is responsible for what and how long it takes. Fix roles and deadlines before launch.

Every service should have an owner. They are responsible for rules: which fields are required, where the request goes, when approval is needed, and what exceptions exist. Executors may change, but the owner ensures the service doesn’t become outdated after personnel shifts or policy changes.

Write the process rules in plain language, as for a new employee. Four items are enough: input (what must be in the request), output (what counts as completion), time (how long it takes) and exceptions (when and why the time may increase). Example: “Access to shared folder: input — full name, department, folder, access level. Output — access granted and confirmed by the user. Time — 1 business day. Exception — owner approval required.”

To agree SLAs and priorities without arguments, tie them to impact, not emotions. A useful scale: critical (department stop or security risk), high (affects deadlines today), normal (can wait until the agreed time), low (do within the coming days).

Build executor queues around roles (for example, “IT Service Desk”, “Facilities Service”), not around a single person. Assign backups for vacations and sick leave up front, and decide what happens to unresponsive requests: auto‑escalation to a manager or reassignment by a dispatcher.

Quality isn’t only speed. After closing, add a short feedback: “resolved/not resolved” and one comment. If many “not resolved” items accumulate in a month, review the service rules rather than looking for someone to blame.

Step‑by‑step rollout: from request list to pilot

At the start, stability is more important than a perfect scheme. Deliver a small, working part of the process: a stable flow of requests with clear statuses and approvals.

A practical rollout scenario:

• Collect the 10–20 most frequent requests and document how they are handled now: who receives them, who approves, timeframes, and what counts as “done.”
• Build the catalog with simple names and short descriptions. Keep forms minimal so the executor can start work.
• Define routes by roles, not names: department manager, accounting, IT, Facilities.
• Set clear statuses: “accepted”, “under approval”, “in progress”, “awaiting clarification”, “done”.
• Test with a small group, then run a pilot in one department and expand gradually.

Example: the “New employee” request. In a minimal version the form needs only full name, department, start date and required accesses. Approval goes to the manager, and tasks are assigned to executors: IT issues accounts and access, Facilities prepares the workspace, Procurement gathers the basic kit.

Agree pilot success criteria in advance: share of requests without clarification, average time from creation to completion, and the number of approvals that stall longer than expected.

Auto‑assignment, statuses and execution control

When requests grow, time is wasted on forwarding: “who handles this?”, “why the silence?”. Auto‑assignment fixes this: the system assigns an executor by service type, department and location (office, branch, floor). For repairs you can set contractor responsibility zones; for accesses — by application or user role.

To avoid repeated clarifications, use task templates: a short checklist inside the request of what to do, what to check and which confirmations to attach. Then “printer repair” doesn’t turn into a 20‑message thread, and “grant access” won’t stall because required data is missing.

Clear statuses and notifications significantly reduce tension. The requester needs to see progress; the executor needs a status that reflects reality and doesn’t require extra actions. A typical set is enough:

• New (created but not yet picked up)
• Accepted (executor assigned)
• Awaiting approval
• Awaiting requester (needs data or access)
• Completed or Rejected (with mandatory comment)

Control deadlines with rules: time by service type and priority, automatic overdue logging and a required reason for delay (for example, “no spare part”, “waiting for a contractor”, “need additional data”). This creates a clear picture without manual reports.

Store attachments and results directly in the request: before/after photos, acceptance act, invoice scan, access confirmation. Then quality checks and dispute resolution take minutes instead of searching chats and emails.

Example scenario: onboarding and related requests

A new employee starts on Monday. The manager needs workstation, equipment and access ready, and IT and Facilities shouldn’t receive dozens of scattered emails. Onboarding shows why automation is needed: one request can trigger multiple related tasks for different executors.

How it looks in practice

The manager creates an “Employee onboarding” request and fills minimal data: department, start date, role, location, and approver. The system then creates related requests from the catalog.

First — “Issue PC or workstation.” Usually approved by the department manager and executed by IT warehouse or IT service. If standard profiles exist (office, accountant, engineer), the device type is chosen from a template instead of being written in comments.

Second — “System access.” To avoid excessive rights, access is granted via roles: position -> set of systems -> access level. Approval follows two branches: the manager confirms the need and the system owner confirms rights.

Third — “Basic stationery kit.” Limits help: a standard kit is issued without approval; an extended kit requires Facilities or manager approval for budget. Issuance is recorded so there’s no later dispute about what was received.

What the manager and the new employee see

Simple statuses and clear notifications are enough: created (shows related requests and deadlines), under approval (shows who has the ball and how long it’s been waiting), in progress (who the executor is), completed (with outcome confirmation), needs clarification (requests specific data, not generic comments).

In the end the manager monitors onboarding readiness in one place, and the new employee gets a predictable start without extra messages.

Common mistakes when configuring the catalog and approvals

The initial setup can look good on a diagram but fail in real work. The usual reason is simple: the catalog and approvals are built for the convenience of configuration, not for how people use them daily. Then automation doesn’t reduce workload, it adds frustration.

The most visible problem is overloaded forms. If ordering stationery requires ten fields and three attachments, the user will go back to chat. Start with the minimum: what to order, where to deliver, and who receives it.

The second common mistake is approvals “by name.” Today it’s Ivanova, tomorrow she’s on leave or has left the company, and the process stops. Tie approvers to roles and departments instead: department manager, budget owner, security officer.

A third problem is lack of common statuses and clear rejection reasons. If one executor marks “Rejected”, another writes “Impossible”, and a third simply closes the request, disputes and re‑creations begin. Define unified statuses: what they mean and acceptable rejection reasons.

Fourth mistake — the catalog grows without an owner. Duplicates appear like “Mail access”, “Mail: open access”, “Create mailbox”, and people choose randomly. Assign a catalog owner and a rule: every new service is checked for duplicates and clarity.

Fifth — launching a pilot without short training and a support point. Even 15 minutes of instruction and a clear channel for questions in the first weeks greatly improve adoption.

If your organization has many departments and strict regulations (for example, public sector or a large enterprise), these mistakes surface faster. Start with simplicity, roles and common rules, and add complexity only after real cases.

Short checklist before launch

Before opening the catalog to everyone, check basic items. It takes a couple of hours and saves weeks of investigation into why requests get lost, approvals go in circles, or executors receive incomplete data.

• Each service has an owner (rules) and an executor (operations), with backups for vacations.
• Forms are checked for unnecessary fields and have short hints for key fields.
• Approval routes are described by roles and departments: who approves accesses, who approves spending, who confirms repairs, and what to do in disputes.
• Statuses, notifications and deadlines are set. Priorities shouldn’t turn “urgent” into a way to speed up everything.
• Metrics for the first 2–4 weeks are defined: average approval time, completion time, share of returns for clarification.

If you can’t confidently answer “yes” to at least two items, run a soft launch in one department. You will catch typical issues on real requests and update the catalog without noise and user distrust.

Next steps: how to launch and scale the solution

To see results quickly, pick 1–2 departments (for example, office management and IT) and collect the top 10 frequent services: stationery, mail access, workstation setup, equipment repair, cartridge replacement.

Before configuration, agree on basic data: owner of each service, executors and responsibility zones, approval matrix, response and completion times (considering working hours), rejection reasons and mandatory fields (what to attach or specify).

Measure effect with numbers. Compare pre‑ and post‑pilot metrics: average approval time, share of requests without clarifications, number of overdue items, how many requests still come through wrong channels (email, messengers), and how much time managers spend on routine approvals.

Bring in a systems integrator when routes are complex (different rules across branches, budgets and dependent requests), many systems are involved (AD, mail, asset management) or you need a single process model for several teams. Then it’s important not only to configure tools but to carefully document rules so they work the same everywhere.

If you plan to roll out service processes broadly and need a reliable IT base, involve a partner experienced in integration and support. GSE.kz, as a technology vendor and systems integrator in Kazakhstan, can help with designing routes, integrating with infrastructure and supporting service processes.