Skip to main content

Request management explained

R
Written by Riya Sebastian
Updated over a week ago

Use Requests to keep track of and stay on top of employee requests. Employees can raise requests with the AI Assistant’s help either in a public channel or by DMing the Assistant. If you’ve ever found the process of routing employees from DMs to service desk forms futile, you’re in the right place.

Atomicwork is built for all teams that regularly assist employees - IT teams that work on service requests, HR teams that field onboarding and compensation questions, Legal desk that gets contract questions, Finance Ops teams that work out payroll issues, and more. Use the AI Assistant to provide instant answers to frequently asked questions so your team can focus on the hard problems.

Receive and manage requests in Slack and Microsoft Teams

When an employee sends a message on a request channel (a channel set up to help employees) or DMs the Assistant, it will determine if the message matches a service in a workspace’s service catalog. If it does, it will surface the service form to the employee so they can fill it out and raise a request.

For example, if an employee sends “I want a new laptop” as a message, and there’s a Macbook Pro service in IT’s service catalog, the Assistant will send the Macbook Pro service form to the employee so they can fill it out.

If the service isn’t what the employee is looking for or if the Assistant doesn’t find a service, the employee has the option of raising a request so that a human can look into the issue. Learn more.

Once the employee finishes filling out the request form, it creates a request and gives the requester, the employee, the number for them to keep track of the status.

When there’s an update on a request, the Assistant will DM the update to the requester. Employees can also ask for status updates on open requests.

Working on requests

Service teams like IT or HR can work on requests in Atomicwork. Requests are of three types: requests, incidents and service requests. Service requests are always tied to a service in a workspace service catalog.

Requests are routed to workspaces based on the following:

  • Service requests are routed to the workspace that contains the selected service in its service catalog.

  • Incidents raised from an incident catalog item are routed to the workspace mapped to that incident catalog item.

  • General requests and general incidents that are not tied to a service catalog or incident catalog follow your configured workspace routing mode. This can include channel-based routing for requests raised in connected Slack or Microsoft Teams channels and workspace routing for requests raised in places where multiple workspaces may be eligible.

  • When multiple eligible workspaces exist, the routing outcome depends on your configured mode: Smart Routing can assign the request automatically, Smart Suggestion can preselect a workspace and let the employee change it before submitting, or requester selection can let the employee choose from eligible workspaces without an AI recommendation.

When multiple eligible workspaces exist for a general request or general incident, Smart Routing can use workspace signals to assign the request automatically, while smart suggestions can use those signals to recommend a workspace that the employee can review and change before submitting. You can also configure requester selection so employees choose from eligible workspaces without an AI recommendation.

Smart suggestions applies only to general requests and general incidents. Catalog-based service requests and catalog-based incidents continue to route based on their selected catalog item.

For detailed Smart Routing and Smart Suggestion setup instructions, see the Managing routing rules guide.

Requests can be assigned to any workspace user by a workspace operator or admin. When a request is assigned to an operator, a notification will be sent via Slack or Microsoft Teams to the operator so they can log in and work on the request.

Admins can manage agent groups (Open, Restricted, and Private) within a workspace to control access to requests.

Requests assigned to an Open group are accessible to all agents. Requests assigned to a Restricted group are editable only by group members but viewable by other agents, who can add private comments. Requests assigned to a Private group are only accessible to agents within that group.

Cloning a request

You can clone an existing request to create a new request with the same attribute values.

  • Click on the menu at the top right in any request and choose Clone request.

  • A new request form opens with the attributes pre-filled.

  • Attachments and inline images from the original request are copied to the new request.

  • Edit the details as required and click on Submit to create the new request.

All workflows whose conditions are met will run on the cloned request.

If cloning fails, make sure all attributes are editable on request creation, and try again.

Did this answer your question?