Solutions · Departments · IT
AI enters the company where IT says it can.
In Skyller, IT decides what comes in: it publishes the knowledge that answers on its own, connects each system enabling it function by function for each team, sets what stops and waits for a person, and afterwards checks the record of actions.
- Permissions by group
- The requester's access
- Human approval
- Activity trail
Access to the Customer Service workspace
Customer Service group| Resource action | Permission |
|---|---|
| View documents | Allowed |
| Edit content | Allowed |
Demonstration · illustrative data
Who works here
From support to IT management.
Fewer repeat tickets
How it goes today
Answers the same ten questions every week — password, access, printer, VPN — while the runbook sits in a folder only IT opens.
With Skyller
The published runbook answers whoever asked, with the link; the tickets left are the ones that really need a person.
Access by function
How it goes today
Gets the request to “enable AI for the team” with no way to say yes to only part of a system.
With Skyller
Connects the system and enables it function by function, per group; what was not enabled does not show up for whoever may not use it.
Recorded activity
How it goes today
Knows the team uses AI on the outside, with company data, and has no record of it.
With Skyller
Usage inside the company, with corporate identity, approval for sensitive actions and actions on record.
Connections to your systems
How it goes today
Writes a new service every time someone wants to wire an internal system into an automation.
With Skyller
Registers the internal system by its own address and, depending on the plan, lets that system call Skyller with an API key.
The IT routine
Where Skyller fits — and what stays with you.
Select a routine to see the details.
Skyller does it
The team's repeat questions
The runbook and the policy are published with review and answer in chat with the link, respecting what each person may see.
Enabling AI access per team
Each function of a connected system carries a risk level, an approval policy and a per-group restriction; whoever was not given the function does not see it.
Usage records and auditing
The activity trail keeps author, action and resource, with filters, for administrators; origin address and browser appear on some events.
Needs configuration
Connecting the company's systems
Catalogue connectors, a custom connector registered by an administrator and a personal connection through each person's login. Use requires configuration, authentication where applicable and authorisation of actions.
Identity and people joining
Corporate directory sign-in in read-only mode, single sign-on via SAML or OIDC depending on the plan, Google or Microsoft accounts, and two-step verification.
Stays with the team
Monitoring and ticketing
Monitoring and ticketing stay in IT's tools. When something happens, your system can call Skyller with an API key, depending on the plan.
Devices and network
Machine inventory, antivirus, network and device management stay in the tools IT already uses.
Live proof
The same question, two results.
Starting point
IT connects the ticketing system and, in that connector's function list, enables only viewing and commenting on tickets, and only for the support group.
What happens
- On each function's row, IT sets the risk level, whether it requires approval and which groups may use it.
- Ana, in support, asks in chat for the status of ticket 4471 and gets the answer. Bruno, in finance, asks the same question: for him the function is not available, and Skyller answers with what the documents say.
- When Ana asks to close the ticket, a high-risk action, Skyller opens the card with the action and its parameters and waits for Approve or Deny. The decision goes into the trail, with who decided and when.
Result
The permission belongs to the person, not to the sentence they typed, and IT can prove it afterwards, in the record, without relying on anyone's memory.
Good to know
- The per-group restriction only narrows what the connector already allows; nobody gains access beyond it, and the setting is an administrator's.
- By default, high- and critical-risk functions ask for confirmation; the company can demand more or waive it, and lock the choice.
- The official record stays in the ticketing system: Skyller looks up and acts within what IT enabled.
Fictional company, people and ticket; real product features.
Features
What IT configures before enabling anything.
Select a feature to see how it works.
Three controls on every function
On each function's row in a connected system: the risk level, the approval policy (inherit, always ask, never ask) and the groups that may use it. The per-group restriction goes back to inheriting from the connector in one click.
An internal system of yours also fits
The connector catalogue can be searched by category and country, and an internal system comes in two ways: the company connector, registered by an administrator, and the personal connection, where each person links their own account or registers an address of their own. Both use a secure connection and refuse addresses that should not be reached; enabling function by function belongs to the company connector.
Credentials nobody reads
Credentials for connected systems are encrypted. A personal connection is read only by its owner: there is no administrator shortcut to a colleague's credential.
The identity is the company's
Corporate directory sign-in in read-only mode with periodic sync; single sign-on via SAML or OIDC, depending on the plan; Google or Microsoft accounts; and two-step verification through an authenticator app, which the administrator can require.
Integration in both directions
Inbound: depending on the plan, your system calls Skyller with an API key created in administration; the automation runs with the permissions of whoever created the key, and the event's data arrives as fields of the task. Outbound: an administrator registers an address to receive notices from Skyller, with validation and a test send. The operations a key may call are described in the platform's integration specification.
Activity trail
Author, action and resource, with filters by action, resource type and person, for administrators; origin address and browser appear on some events. A change to a tool's reach is recorded with the before and the after.
Ready-made agents for the area
Technical support, infrastructure and information security are among the ready-made agents; the company adjusts each one's instructions, documents and tools.
Activity trail
Documents| Time | Person | Action |
|---|---|---|
| 09:42 | Carla | Document published |
Demonstration · illustrative data
How to start
From the first runbook to the first enabled function.
Start with what depends on nobody: publish the knowledge that answers on its own. Then connect one system, enable the minimum and only then grow.
IT
Publishes the runbook and the usage policies in the right hub, with review by a second person; each person sees only what their permission allows.
IT
Connects the first system, from the catalogue or by the address of an internal one.
IT
Enables only the necessary functions, sets which ones require approval and restricts each to the right groups.
Team
Uses it: asks, looks up and, when authorised, acts, with the approval pause where IT defined one.
IT
Follows it in the activity trail and adjusts whatever is needed, per function or per group.
IT questions
What IT needs to know before enabling anything.
Start with IT
Publish one runbook. Enable two functions.
Create your account, publish the knowledge your team asks about most and connect one system enabling the minimum.