How AlisX Specialists work¶
AlisX Specialists are the people you reach when you or your agent need another person. In the console they answer in Support; from the CLI, through alis specialist. This page explains who receives a ticket and why, where a ticket stands, how people work on one together, how AI helps and what it never does, and who can see what. For the steps, see Get support.
A ticket starts from where you were¶
You can log a ticket from wherever you are working: an Ideate project, an interview, anywhere in the console, or the CLI and TUI. The ticket records where it came from, so whoever picks it up starts with your context rather than asking for it. That same record decides who picks it up.
Who receives it¶
| Logged from | Reaches |
|---|---|
| An Ideate project, with Log a ticket from Support | An AlisX specialist, with the project and the page you were on. |
| Setting up an interview, inviting participants or reading the results | An AlisX specialist, with the interview you were working on. You can carry on setting it up while they reply. |
| Inside an interview, with Give feedback | An AlisX specialist, with the interview you were in. The reply waits for you in Support. |
| Elsewhere in the console, such as Build or Admin | The people responsible for that area, with the page you were on. Where nobody is set up for it, an AlisX specialist. |
| The CLI or the TUI | An AlisX specialist. Sharing the agent session you were in gives them the commands and output behind your question. |
| Feedback on a skill or a code block | The skill's or block's owners. If none of them can be reached, an AlisX specialist. Feedback on a block also needs access to that block. |
| A request to create a product or to join a build environment | That build environment's administrators, who approve or decline it in the ticket. The product's own permissions still apply. A request for a new build environment goes to an AlisX specialist to set it up. |
| A peer ticket | An administrator of a product you can access, whom you choose, in a private ticket between the two of you. The choice is checked before the ticket is created: a choice that isn't valid fails rather than falling back to the general inbox. |
Routing to the owners of the thing in question, rather than to one general desk, is deliberate. The person who maintains a skill or administers a build environment is the one who can actually fix or approve it, and a ticket that arrives with its context does not have to be passed around before anyone can act on it.
Where a ticket stands¶
A ticket is Open while it waits for or is getting a reply, Waiting on you when the specialist needs your answer, and Resolved when it is done. A resolved ticket stays readable, and you can still thank the person who helped.
Working on it together¶
Everything stays with the ticket. Messages, screenshots, recordings, files and the place you logged it from stay together. Come back later and pick up where you left off; Support shows what is new.
The right people can be brought in. You, or the AlisX specialist on your ticket, can add someone to it, such as a colleague on the project. A skill's owners join only when they are invited; mentioning the skill does not add them.
A handover keeps the history. A specialist can hand your ticket to a colleague with a note, and the whole history goes with it. The previous specialist stays on the ticket unless they choose to leave. A peer ticket keeps the person you chose and cannot be handed over.
The next step starts from the ticket. An AlisX specialist can set up a call or an interview from the ticket, and what comes out of it returns to the ticket. Work for the engineering team is filed from the ticket with a link back, so nothing is lost between your report and the fix.
Thanks are kept. You can thank your specialist, or anyone else on the ticket, even after it is resolved. Thanking the same person again updates your note rather than counting twice.
How AI helps, and what it never does¶
AI helps the people on a ticket write and find answers. It never answers for them.
- Polishing a reply. AI can polish a draft using the ticket's recent messages. The result is suggested text: polishing neither saves nor sends anything, and the person writing decides what to use and when to send it.
- Learning from resolved tickets. Once a ticket logged from the console or the CLI is resolved, its problem and resolution can be kept to inform suggestions on similar tickets later. Private peer tickets, skill and block feedback, and product and access requests are never used this way.
- A draft for a person to review. When a resolved ticket closely matches yours, AI drafts a reply for an AlisX specialist to review, and a specialist can also ask for a suggestion at any time. The draft is never sent on its own: a person reads it, changes it and decides.
Who can see what¶
Access follows the ticket. You see the tickets you logged or were added to; AlisX specialists work across the general inbox. A private peer ticket is visible only to the person who logged it, the specialist they chose and anyone explicitly added. Being an AlisX specialist does not open it.
A saved draft belongs to its author. A draft you save is visible only to you and is not a sent message. The AI drafts that help specialists reply are a separate aid and never expose anyone's own draft.
Each action checks who is taking it. Being the specialist on a ticket says who is replying; it gives no wider access to your projects or products. Adding people and handing over follow the permissions of the person doing it, and only an authorised AlisX specialist can return a ticket to the general inbox.