For the complete documentation index, see llms.txt. This page is also available as Markdown.

Request a feature

Suggest what akenza should build next, and follow what happens to it.

Feature requests are collected on a public board, where every customer can add a request, vote on the ones already there, and follow what is being worked on.

Writing a request that lands

The board is read as input to the product roadmap, so a request is more useful when it describes the problem rather than only the solution you have in mind. What helps:

  • The use case. What you are trying to achieve, and why the current behaviour gets in the way.

  • Your workaround. What you do today instead, including the manual steps or the external tooling it costs you.

  • The scale. How many devices, workspaces, or people are affected, and how often.

  • The outcome, not the implementation. "I need to know when a device stops reporting" leaves room for a better answer than "add a checkbox here".

Search the board before adding a request. Voting on an existing entry and adding your use case in a comment carries more weight than a second entry saying the same thing, because it keeps the demand visible in one place.

What happens next

Requests are prioritized against the product strategy and against how often the same need comes up. Not everything can be built, and a request appearing on the board is not a commitment to deliver it, but it is visible to the team and to other customers who may vote on it.

The board itself is where the status lives. Follow your request there to see updates and to watch what is planned.

Something broken rather than missing belongs in the Service Desk, where it is tracked as an issue instead of waiting on votes.

Last updated

Was this helpful?