01 · The portal
Four things arriving as one system: a dashboard built around your workflow, a portal on your own domain, an assistant that answers questions about your own data, and an engine that keeps everything moving overnight.
Composed at onboarding · configured, never re-coded
Next actions
What is in it
They are not four products bolted together. The dashboard reads what the engine writes, and red answers from the same records — all inside one isolated data store.
Dashboard
Every role lands on a dashboard that answers the same five questions: what needs attention today, what changed, what can I do next, what is blocked, and which records are mine. Metrics, pipeline, next actions and risk — arranged in the shape of your operation.
Portal
Your team and the partners you approve log in at your own address. Your logo, your colours, your labels. No red-route hostname ever appears in a partner’s browser — we are the engine room, never the storefront.
red
Ask in plain language and get an answer drawn from the records that person is already entitled to see. It runs on a local model on our own hardware. Conversations live for the session and are never stored.
Engine
Intake, routing, status changes, chasing what is missing, reminders and alerts. It is the difference between a system that records work and one that moves it along.
Under your brand
A partner logs in at your address, sees your name, and finds only their own work. They never learn that red-route exists.
Partner portal
Northgate Trust
Only your organisation’s submissions
No red-route address ever appears here.
The portal, the API and every form route are served under your domain — same origin, through a private tunnel. You point a CNAME and add a verification record; you never run a tunnel or a Cloudflare account yourself.
Logo, colours and the label on the front door come from your configuration. A charity and a roofing firm run the same platform and share no visual DNA.
The portal serves your organisation and the partners you approve — never your own end customers or the public. The only unauthenticated surfaces are the intake forms you deliberately publish.
The assistant
A question in plain language, answered from data the person asking is already allowed to see. The retrieval happens on our server before a model sees anything.
The lookup runs server-side against the tenant’s own database as a scoped role. The local model only ever receives records that person was already entitled to. It is not filtering a big answer down — it never had the rest.
red runs on a model on our own hardware. If it is unavailable it says so and stops. There is no graceful failover to a cloud AI, because that would put your data somewhere it must never go.
Prompts, answers and transcripts are not written to your tables, to browser storage, or to our logs. Close the tab, switch role, or log out and the conversation is gone.
red will not surface or summarise safeguarding records in general questions. That path stays separate whatever you ask.
Session only · nothing stored · never sent to a third-party AI
The engine
Most operational failures are not decisions gone wrong — they are things that quietly waited. Intake at 9pm, a missing consent form, an outcome nobody chased.
Activity log
0 people involved · 0 items waiting for morning
Submissions are logged the moment they land, stamped with a status, and acknowledged. Nobody has to be watching an inbox for the record to exist.
Incomplete submissions are followed up automatically on a schedule you set, so a missing field does not stall a case for a week.
Status changes notify the people who need to know. Outcomes get chased, no-shows get flagged, and risk surfaces rather than sitting in someone’s head.
Automations are parametrised by tenant, not cloned per client. Your workflows resolve to your database and only yours.
Roles
Three portal roles, renamed to your language at onboarding. For a roofing firm the intake partner is a customer contact and the delivery partner a subcontractor — the labels change, the boundaries do not.
Sees everything for their organisation: the full pipeline, partner activity, approvals, outcomes and any alerts. The top operational role — every in-portal decision belongs here.
Sees only their own submissions. Submits new work through a guided form, then tracks where each one has got to. Never sees another partner’s records.
Sees only the work assigned to them. Marks attendance or progress, submits outcomes, and raises a concern on its own separate path.
red-route staff hold no operational authority inside your portal. We provision, host and maintain the platform — approvals, status changes and every operational decision belong to your own admin.
Shapes
Your portal is composed at onboarding from a reusable kit, starting from whichever pattern is closest to how you already work.
Referrals, matching, placements, partner activity, outcome chasing — with safeguarding kept separate.
Cases, statuses, risk and priority, owner assignment, next actions.
A job workspace, survey data, materials and costs, quote versions, the accepted-quote rail.
Mobile-first capture: sticky job context, checklist steps, large tap targets.
Pipeline, value at stake, ageing work, blocked items, month-to-date.
Boundaries
These are not settings. They hold for every client, on every tier, whether or not anyone asks.
A partner sees their own work and nothing else. Scoping is enforced on the server against the authenticated identity — never by hiding rows in the browser.
Its own route, its own workflow, its own isolated table. It is never mixed into another list, never included in an export, and red never surfaces or summarises it.
Inside the portal, people entitled to a record can see the name. Anything that leaves — an email, an export, a PDF — carries the reference instead.
No permanent login, no stored password in the browser, no conversation history. Close the tab and the session is gone.
Tell us how the work actually runs and we will show you the console your team would land on.