Source: https://atomicwork.docs.pageloop.ai/product/analytics/request-and-service-health/requests-overview # Requests overview The overview of workspace requests report is a detailed analysis of the requests worked on by your team, encompassing every request type in the workspace (service requests, incidents, problems, and so on). Admins can view requests report by workspace and export this report in PDF and CSV formats by going to **Analytics > Workspaces > \[Workspace name] > Requests overview** and clicking **Export**. PDFs will be downloaded immediately and CSVs will be emailed to you as soon as the report is ready (this could take anything from a few seconds to a few minutes depending on the volume of data in question). If you've applied filters, only data that matches the filters will be exported. > [!NOTE] > > Please refer to [the Admin's deflection guide](/guides/improving-request-deflection) for deflection best practices. ## How to read this report | **Metric** | **Definition** | **Which requests are included** | | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | New requests | Number of requests that came into the workspace. Shows a % change against the previous period. | Requests created (or moved in) in the selected period. | | Completed requests | Number of requests that were closed. If a request was closed more than once, its latest close in the period is used. A request reopened later still counts here; reopens are shown separately in **Reopen rate**. Shows a % change against the previous period. | Requests closed in the selected period, whenever they were created. | | First contact resolution | Share of completed requests that were solved on first contact, with no back-and-forth needed. Formula: requests solved on first contact ÷ completed requests | The same requests as **Completed requests**. | | Reopen rate | Share of completed requests that have since moved back to an open or pending status. Formula: reopened requests ÷ completed requests | The same requests as **Completed requests**. The reopen itself can happen any time up to now. | | New vs completed requests | Daily line chart of requests created and requests completed each day. If the created line stays above the completed line, your backlog is growing. Days with no activity show 0. | The **New** line uses creation (or move-in) dates in the selected period. The **Completed** line uses close dates in the selected period. | | Time to first response | How long it took to send the first response to a request, by a human or Atom. Switch between average and median. Requests that haven't had a first response yet are left out. | Requests created (or moved in) in the selected period. The response itself can come later. | | Time to resolution | How long requests took to resolve, by a human or Atom, minus any time the SLA clock was paused. Switch between average and median. If a request was reopened and resolved again, its total resolution time is used. Requests that are currently reopened are left out. | Requests resolved in the selected period, whenever they were created. | | First response SLA | Number of requests that met vs missed their first response SLA. **Met** means the first response (or resolution) came before the due time. **Missed** means the response was late, or there's still no response and the due time has passed. SLA pauses are taken into account. Requests without a first response SLA are left out. | Requests created (or moved in) in the selected period. Met or missed is judged as of now. | | Resolution SLA | Number of requests that met vs missed their resolution SLA. **Met** means resolved on or before the due time. **Missed** means resolved after the due time. SLA pauses are taken into account. Requests without a resolution SLA are left out. | Requests resolved in the selected period, whenever they were created. | To see the exact requests behind any number, click **View breakdown** on the tile or chart. For example, if **Reopen rate** shows 28%, **View breakdown** lists the reopened requests that make up that figure. New requests appear in this report within 1 hour of being created. ## Report filters You can drill down into this report with all request attributes defined in your account. This includes: - Duration - Request type - Requested by - Group - Agent - Status - Priority - Impact - Urgency - Category - Impacted assets - Service - Rating - Source You can also filter by attributes such as **Follower**, **Tags**, and **Created on**, and save a filter combination as a view to come back to later. See [Filtering reports and saving views](/product/analytics/request-and-service-health/filtering-reports-and-saving-views). ### How the Duration filter works The **Duration** filter (Today, Yesterday, This week, This month, This quarter, This year, Last week, Last month, Last quarter, or a custom range) sets the start and end of the reporting period in your time zone. You can't pick future dates. Not every metric uses the same date to decide what falls inside the period: - Most metrics count requests **created** in the period. A request moved in from another workspace counts as created on the date it was moved. - Completion and resolution metrics count requests **closed or resolved** in the period, whenever they were created. The table in [How to read this report](#how-to-read-this-report) says which date each metric uses. A **% change** compares the selected period with the period of the same length just before it (for example, this month vs the previous 30 or 31 days). Deleted requests are always left out, and other filters narrow the results further.