Hoppa till innehållet
Peak Atlas

Peak Helpdesk · Partly planned

Permissions and approvals.
Who sees what, who may do what.

Who in support may see and do what: roles exist today through Peak One. Approvals for sensitive steps such as refunds are planned in Peak Helpdesk.

Which change do you want to check?

Your next review briefToday · Workspace roles

Peak Helpdesk uses the roles of your workspace: owners, admins and members. Members work on tickets, owners and admins set rules such as response and resolution promises. There is no second user management just for support.

You can take the brief with you at the end of the page. The original evidence stays open.
See the flow
For
Teams with several people in support
Today
Roles via Peak One, assignment, history
Planned
Approvals for refunds and the like
Dossier · demo template

Roles today,
approvals planned.

Original evidence pending
  1. 01Roles
  2. 02Ownership
  3. 03Approvals (planned)

A real story starts with its release.

The starting point

What works today and what is planned.

Today the roles of your workspace in Peak One decide who sees tickets and who changes settings. Only members of your workspace see tickets, guests do not. Every ticket has an assignee, and every change is in the history. Approvals for sensitive steps, for example when a refund is to be promised, are planned and not yet available. Peak Helpdesk never refunds anything itself and does not decide for your team.

Customer release still open

This pattern shows the structure. It doesn't tell a real customer case yet.

Starting point → change → evidence

The path to change

Permissions in support in three stages.

  1. Roles from Peak One

    Peak Helpdesk uses the roles of your workspace: owners, admins and members. Members work on tickets, owners and admins set rules such as response and resolution promises. There is no second user management just for support.

    One permission system for all Peak apps
    Evidence format · not filled in yet

    The starting point.
    In the original.

    Original excerpt

    Insert the released passage here.

    A / ObservationWhich concrete friction is visible in this source?
    Today · Workspace roles

  2. Ownership and history

    Every ticket has an assignee. When a ticket is assigned, a notification lands in the Peak One Inbox. Who changed what and when is in the ticket's history and cannot be silently overwritten.

    Clear responsibility for every ticket
    Evidence format · not filled in yet

    One step.
    Traceable.

    BeforeOriginal processSource evidence required
    ChangeConcrete interventionProduct view and date required
    Today · Assignment and history

  3. Approvals for sensitive steps (planned)

    The plan is that certain steps only continue after an approval, such as promising a refund or a goodwill gesture. Until then your team handles such cases itself, for example with an internal note on the ticket or a task in Peak Task.

    Four eyes where money is involved
    Evidence format · not filled in yet

    The result.
    With a yardstick.

    Observation
    Not evidenced yet
    Period
    Open
    Source & release
    Pending

    Without released data this statement stays open.

    Concept · Approval, not yet available

What can be evidenced

What applies today and what is still coming.

The evidence is still pending

There are deliberately no metrics here. There are no measurements of approvals because approvals are not yet built in Peak Helpdesk.

Space for a released perspective.
The sculpture does not depict a customer.
Room for a real voice

One perspective.
With name and release.

No released customer quote on file.

Beyond the single case

What you can settle right now.

  1. Hand out roles deliberately

    Give admin rights only to people who should really set rules and promises. Everyone else works on tickets as a member. External people stay guests and see no tickets.

    Key idea

    As few permissions as necessary

  2. Make sensitive cases visible

    While approvals are missing, a fixed team rule helps: refunds and goodwill only after checking with someone, recorded as an internal note. That keeps it traceable who decided what.

    Key idea

    Traceable decisions even without an approval feature

Sources & context

What this article is based on.

Description based on the Peak Helpdesk fact brief. Available today: roles via Peak One, visibility for members only, assignment, Inbox notifications and history. Planned and not yet available: approvals for refunds, goodwill and other sensitive steps. Peak Helpdesk refunds nothing itself.

  • Editorial demo

    Editorial guide with made-up sample data. Only features Peak Helpdesk has today are described; everything else is marked as planned or example. No studies, no customer metrics.

The next step

Decide who may do what in support.

Start Peak Helpdesk in your workspace. The roles you assign in Peak One apply here too.

Start Peak Helpdesk for free

Frequently asked questions

Which roles exist today?

Peak Helpdesk uses Peak One's roles: owner, admin, member and guest. Whoever belongs to the workspace sees its requests.

Can refunds go through an approval?

Not yet. Approvals for refunds and goodwill are planned. Peak Helpdesk never refunds anything itself.

Does Peak decide for my team?

No. Peak sorts and shows what is waiting. A person on your team always makes the decision.

More in Peak Helpdesk