Product development update

Building Ask:Enact around real frontline work

A prevention tool only works if it fits the moment it is needed.

That sounds obvious, but it is where a lot of digital systems fall down.

They are often built around tidy workflows. A person sits at a desk. They have time. They know which screen to open. They know what information they need. The situation fits the process.

That is not how frontline work usually happens.

A concern might come up during a planned appointment, a phone call, a home visit, a community session, or a brief conversation where something does not feel right.

The professional may have limited time. The person may not explain the issue clearly. The housing concern may be hidden behind something else. Money, safety, health, language, family breakdown or digital exclusion can all sit underneath the first thing someone says.

If Ask:Enact is going to be useful, it has to work in that reality.

Starting with the work, not the software

Ask:Enact started with a simple problem.

Professionals often spot that something is wrong, but the next step is not always obvious.

That might be because housing is not their main role. It might be because the guidance is hard to find. It might be because there are too many possible services and not enough clarity about which one fits.

So we are not building Ask:Enact as a generic chatbot with a housing label stuck on it.

That would be easy to build and probably useless.

The work has to start with how people actually practise.

What does a professional need when they are under pressure?

What helps without getting in the way?

What kind of answer is useful when the person still has to make a judgement?

What level of detail is enough, and what is too much?

Those questions matter more than the technology.

What early testing is telling us

The first phase of testing has been useful because it has moved the work out of theory.

The Community Learning and Development Team have been asking and acting across the city. Police Scotland have tested the approach in Tillydrone. NHS and Allied Health Partners have been briefed and are preparing to begin their own testing.

The feedback is already shaping the build.

Staff are generally comfortable having conversations, but the same issues keep appearing after that first conversation. People need clearer referral information. They need to know which service is the best fit. They need clearer follow-up after signposting. Some situations are affected by wider barriers, including language, digital access and complex household circumstances.

That is the kind of feedback that matters.

It tells us where the system needs to help.

Not in a vague “AI will sort it” way. In a practical way.

• Make the next step clearer.
• Make guidance easier to access.
• Make service information easier to use.
• Help the professional think through risk and urgency.
• Do not bury them in process.

The March version gave us a base

The first live version of Ask:Enact launched in March.

That was an important step, but it was not the finished product. It gave us a working base for structured testing, learning and improvement.

Since January, a lot of the work has been about turning the early concept into something credible and usable.

That includes the visible parts, such as the interface, design and accessibility.

But it also includes the less visible parts, which are just as important:

• the knowledge behind the system
• local service information
• risk categories
• legislation and guidance
• governance
• data protection
• quality processes
• assurance work

That stuff is not exciting to write about, but it is what separates a serious tool from a demo.

If this is going to be used by professionals, in live practice, with real people, it has to be built properly.

Why the May version matters

The next major focus is version 2 for release in May.

This is where the system moves much more towards frontline usability.

The question is not, “Can the system produce an answer?”

The question is, “Can a busy professional use that answer?”

That is a different test.

The answer needs to be clear. It needs to be short enough to use. It needs to show risk and urgency. It needs to give practical next steps. It needs to support the conversation, not take it over.

The system also needs to avoid making people feel as though they are filling in a form with extra steps.

That is why the design work matters.

Ask:Enact needs to feel simple, even though there is complexity underneath it.

Built around judgement, not replacement

One thing I want to be clear about is that Ask:Enact is not being built to replace professional judgement.

That would be the wrong approach.

Frontline staff understand context in a way software does not. They notice tone, behaviour, hesitation and circumstances. They understand the limits of their role and the relationship they have with the person in front of them.

The job of Ask:Enact is to support that judgement.

It should help a professional ask useful follow-up questions, spot risk, understand urgency, and connect the person to relevant guidance or support.

It should also help create more consistency, so that the quality of the response does not depend entirely on who happens to be working that day, what they already know, or whether they have time to search through different websites and documents.

That is the balance we are trying to get right.

• Support the professional.
• Keep the human decision.
• Make the next step easier.

Building in stages

The build is deliberately staged.

Version 1 in April is the Minimum Viable Product: rebuilding the prototype on enterprise infrastructure.

Version 2 in May focuses on frontline users and the findings from Human Factors work.

Version 3 in July will focus more on supervisors, including the tools and permissions needed to manage small teams.

Version 4 in September will move towards managers and back-office teams, with analytics, reporting and trend insight.

Version 5 in October will focus on pre-audit refinement and User Acceptance Testing.

Version 6 in early December is planned as the final release.

That staged approach matters because different users need different things.

A frontline worker needs speed, clarity and confidence.

A supervisor needs oversight and safe team management.

A manager needs patterns, reporting and evidence.

Back-office teams need governance, assurance and administration.

Trying to build all of that at once would be a mistake.

The better route is to build, test, listen, fix and improve.

The system needs to learn from practice

Ask:Enact is being shaped through focus groups, frontline testing, prompt refinement and user feedback.

That will continue throughout the build.

This is important because prevention work does not sit neatly in a policy document. It happens through real conversations, in different settings, with people whose lives are rarely simple.

A system built for that kind of work needs to be tested against reality.

That means listening when staff say something is too long, too vague, too hard to find, or not useful in the moment.

It also means being willing to change the system when the feedback shows we have got something wrong.

That is not a weakness in the build. It is the point of the pilot.

What we are aiming for

The aim is not to create another system that professionals have to battle with.

The aim is to create something that helps people act earlier and more consistently.

Ask:Enact should help professionals:

• ask better follow-up questions
• understand risk and urgency
• find relevant guidance
• identify suitable support options
• produce clear next steps
• learn from what is happening before crisis

If it cannot do that in real frontline conditions, then it is not good enough.

That is the standard we need to hold it to.

The early build has given us a base. The next phase is about making it work properly for the people who will actually use it.

Not in an ideal workflow.

Not in a demo.

In the real moments where a professional notices something, asks a question, and needs to know what to do next.