How Scalter picks the next useful action

Scalter is Scalt’s assistant. It searches the sources you have access to, answers by showing the documents it used, and can create a tracked case from your request. But an answer is often just the start: the real question is “what next?”. Here is how Scalter suggests the next useful action, and the choices we made to keep it useful.

Too many tools, no thread

In a working day, topics are scattered: a request in the chat, a document in the drive, an approval waiting in an email, an agent that failed overnight. Each tool has its own notifications, and none of them says where to start. The cost is not just the time lost searching: it is also what slips through the cracks because nobody saw it.

An assistant that only answers adds one more tool. We wanted the opposite: that from a question, or simply from the start of the day, Scalter helps you act. Open the right case, approve what is waiting, restart what failed.

What Scalter suggests

• The morning brief: what is waiting for your approval, what failed, what is running, summarised on the dashboard.
• From an answer: create a case from the request, assign it and track it. The conversation stays attached to the case.
• From the conversation: launch the agent suited to the request, or approve a pending action, without switching tools.

Each of these suggestions remains a suggestion. Scalter approves nothing on your behalf: an action subject to approval stops and waits for your consent, and everything that is done remains visible in the history.

The next action often starts with a check. Every Scalter answer comes with its sources: you open the document, the row or the original message before deciding. The same goes for an Excel or CSV file dropped into the conversation, which you can query sheet by sheet.

The heavy work happens upstream

To suggest at the right moment, Scalter cannot reread everything on every question. The costly work is done upstream, when sources are synchronised: indexing documents, graph links between companies, contacts, documents and cases, the state of cases and executions.

At request time, lighter work remains: finding what relates to your question or your day, among what you are allowed to see, then ranking the possible actions from simple signals: what is waiting for a human to step in, what is late, what relates to what you are currently doing.

Suggestions that say why

Every suggestion carries its reasons: this case has been waiting for your approval since yesterday; this agent failed on a source that no longer responds; this contract is linked to the customer you are talking about. Without a reason, a suggestion is an order. With its reason, it can be checked at a glance, and turned down just as easily.

It is also what forced us to keep the mechanism simple. A ranking you cannot explain cannot show its reasons. We preferred readable signals, such as status, deadline, link to your request or pending approval, over an opaque score you would have to take on trust.

A Monday morning

Take a support lead who opens Scalt on a Monday morning. The brief shows her three things: two replies prepared by the support agent are waiting for her approval, the ticket summary agent failed over the weekend because a source stopped responding, and a case opened on Friday by a colleague mentions her. For each line, the reason is written down, and the action is one click away: review and approve, restart after checking the source, open the case.

She then asks a question about a customer who has followed up several times. Scalter answers with the relevant tickets and exchanges, then suggests creating a case to track the topic and assigning it to the right person. She accepts; the conversation stays attached to the case, and nobody will have to look for it tomorrow.

Always within your rights

Scalter acts on your behalf: it only reads what you can read, in every connected tool. A suggestion therefore cannot reveal that a case you do not see exists. For the design, that is a strong constraint: rights are applied at search time, not filtered afterwards on a result already computed. It is harder to build, and it is what makes it possible to suggest without revealing anything.

What we ruled out

• Automatic actions “because it is likely”: a suggestion remains a suggestion, and you decide.
• One more source of notifications: the brief gathers what was scattered, it does not add to existing alerts.
• Scores without explanation: a suggestion has to be able to say why it is there.

These choices sometimes make Scalter less spectacular in a demo. Above all, they make it predictable, and a predictable assistant is one you use every day.