Aclovo self service

FOR COMPANIES THAT PREFER AUTOMATED PROCESSES. NOT EMAILS AND IT QUEUES

An employee files a request.
The right person approves.
The portal does the rest.

Leave with cover and auto-reply. Access to a SharePoint folder or a mail group. A new person on the team. A different matter every time, the same portal and the same approval path. After the owner agrees, the portal grants rights, adds members to the group, turns on auto-reply, or runs the rest in your system.

No mail to IT people pick a request from the catalog instead of guessing who to email
The right person decides a manager or resource owner approves, not a generic queue
Automatic after approval the portal grants access, adds mail-group members, turns on auto-reply, or runs the rest in your system

WHAT THE PORTAL HANDLES

Processes ready to deploy: 6

Concrete tasks that today go by email or manual clicks in a console. The same request, the same approval, automatic execution in Microsoft 365.

Search
Product

Leave request with auto-reply and mail forwarding

Microsoft

One form instead of three emails. After manager approval, the portal sets the auto-reply and forwards mail to the substitute.

  • leave on the team calendar
  • auto-reply for the absence period
  • mailbox forwarding to the substitute
Product Outlook

Automatic SharePoint permission matrix

Microsoft

The portal builds a view of who has access to which folder. No manual list gathering before an audit or before someone leaves.

  • who has access to the site and folder
  • direct and inherited permissions
  • refresh on demand or before an access review
Product SharePoint

Create distribution lists and Microsoft 365 groups

Microsoft

One request instead of an email to IT. After approval, the portal creates a distribution list or Microsoft 365 group with a mail address, owners, and initial members.

  • distribution list (mail-enabled)
  • Microsoft 365 group (mail-enabled)
  • owners and members from the first minute
Product Exchange

Create and delete SharePoint sites

Microsoft

An employee requests a new site or deletion of an existing one. They choose Team site or Communication site and name owners and members. After approval, the portal creates or removes the space in SharePoint.

  • Team site or Communication site
  • automatic permission groups and named people
  • site deletion after owner approval
Product SharePoint

Add and remove mail group members

Microsoft

An employee asks to add or remove people from a distribution list or a Microsoft 365 group. After owner approval, the portal updates group membership.

  • distribution lists (mail-enabled)
  • Microsoft 365 groups (mail-enabled)
  • add and remove members with no manual Exchange clicks
Product Exchange

Automatic grant and revoke of SharePoint permissions

Microsoft

An employee asks for access or reports they no longer need it. After owner approval, the portal automatically grants or removes permissions on the site or folder.

  • request for read, edit, or full control
  • resource owner approval, not an IT queue
  • executed in SharePoint with no manual clicking
Product SharePoint

Governance

Self-service that does not make a mess

Permission chaos usually starts with free-for-all grants: everyone assigns differently, nobody knows who has access where. The portal keeps one group schema, owner approval before change, a matrix for audit, and a trail of every decision.

Fixed group schema
Permissions are always created from the same fixed group schema. No manual exceptions in SharePoint.
Approval before grant
The resource owner decides, not IT. Only after approval does the portal add the permission in the system.
Matrix at every level
The portal builds a permission view: site, folder, group. Audit without collecting lists by hand.
A trail you do not have to rebuild
Who asked, who agreed, and what changed. Full history on every request, in one place.

MODEL

Always the same path, whatever the matter

Four steps that look the same no matter the request. People learn them once.

  1. 01

    Pick the matter

    The employee chooses from the catalog. Same view, same way to file a request.

  2. 02

    The right person approves

    Someone accountable for that matter decides. Not a generic IT queue and not a manual change in a console.

  3. 03

    The portal executes

    After approval, the portal runs the change in the system. Status shows in the portal, including when something did not land.

  4. 04

    A trail remains

    Who asked, who agreed, what went out. History stays with the request, with no later reconstruction.

Price per company

One amount. Every process. No per-person fee.

In every plan: all processes · hosting · onboarding · no per-person or per-request fee.

Offer START
bez limitu wniosków
Plan Start
For Up to 100 people
Amount 350 PLN/mo (4 200 PLN/yr)

PLN 4.50 per person at 100 people. Less than one email to IT.

01 All processes, no module upsell
02 Hosting and upkeep in this amount
03 Onboarding included — through the first requests
Offer ENTERPRISE
na Waszą skalę
Plan Enterprise
For Over 500 people
Amount Custom quote

A fixed amount after we size you up. No per-seat price list.

01 Everything in Business
02 New processes on your side first
03 Your self-service requests go to the front of the list

QUESTIONS

What people ask on the first call

Will anyone lose access they have today on go-live?

No. We join additively: the portal reads existing permissions and adds new ones. We do not remove anything we did not grant.

We have years of permission mess. Does that disqualify us?

Opposite — that is a typical starting point. The portal first shows who really has access. Cleanup is a separate decision after you see the list, not a prerequisite.

What permissions does the app need in our Microsoft 365?

The narrowest set needed for the operations you enable. You get the full list in writing before signing. If you do not enable leave, the app does not ask for calendar access.

We have hybrid AD, not Entra alone.

We check that on a call. Sync scenarios are supported, but grant order can differ and we want that clear before the contract, not after.

What if we cancel after a year?

Permissions stay — they live in your systems, not ours. You get an export of request history; we remove the app from the tenant.

Who can approve requests?

Whoever is accountable for that matter and whom you name at onboarding: a manager, a project owner, or someone in IT. The portal does not dictate who that is.

We already have a leave system. Does it make sense together?

If it works and nobody complains, keep it and we connect the rest. Value appears when leave lives in one tool, access goes by email to IT, and cover lives nowhere. Then one window with one approval saves more than a leave module alone.

Who runs this on our side: IT or HR?

Both, each their part. HR sets who approves leave and the rules. IT names resource owners. Employees see one window and do not need to know who configured what.

We already have Jira Service Management or a helpdesk. Why another portal?

Helpdesk finishes where we start. The ticket closes, but someone still had to open the Microsoft console and click by hand. Here approval is execution: after the owner clicks, nobody enters anywhere. If you have JSM, we can keep it as the intake and plug in underneath as the layer that executes.

Contact

Tell us what still goes by email

Company, headcount, which matters still bounce by email between staff, HR and IT. We call or write back. Aclovo is run by Interactive Workspace Sp. z o.o.

Interactive Workspace Sp. z o.o.
+48 451 522 320
contact@interactive-workspace.com
interactive-workspace.com

Contact