Northra

DESIGN-PARTNER PILOT

Run one workflow on your own data in 8–12 weeks.

This is not a sandbox running on sample data, and it is not a slide deck. One business unit, your own sources, two or three workflows that matter, and success measures agreed before we start, so that at the end you have an answer instead of an opinion.

SCOPE
1 business unit · 5–20 users
WORKFLOWS
2–3, chosen by you
ENDS WITH
A go / no-go against your numbers
How a pilot is judgedAgreed up front
1 · Before we start

We write down what success looks like

In your numbers: detection time, margin found, hours returned. Signed off by the person who owns the outcome.

2 · During

Your team uses it on real weeks

Not a demo environment. Real signals, real accounts and real decisions, with a person approving every one.

3 · At the end

A go / no-go, against those measures

If it did not clear the bar you set, the read-out says that.

You keep the findings either way.INDICATIVE

Scope and timings are indicative. The specifics are agreed per pilot, in writing.

A design-partner pilot is a joint build, not a trial licence. You are not evaluating finished software against a feature list. You are pointing a working system at a problem you already have and finding out, inside twelve weeks, whether it changes the decision. Your people shape how it works as it goes.

In exchange for that access and that feedback, design partners get preferential terms and a direct line to the people building it.

Before you start

A pilot works when three things are true.

Most pilots that fail did not fail technically. They failed because nobody owned the outcome, or the scope grew until nothing could be judged.

Someone owns the number

A named commercial sponsor, usually a CCO, pricing lead or business-unit head, who owns the margin or the speed we are trying to move and can act on what comes out.

The problem is specific

"Improve decision-making" cannot be judged. "Cut the time from a feedstock move to a repricing decision, on this business unit" can.

The data can be reached

Read access to a few real sources. It does not have to be all of them. A narrow, well-scoped slice makes a better pilot than a broad one that stays blocked.

How it runs

Eight to twelve weeks, in five steps.

The shape is fixed. The content is yours. Timings are indicative and depend mostly on how quickly source access is granted.

Week 0

Scoping call, before any demo.

Ninety minutes with your commercial people. We map where decisions are actually slow, which sources hold the answer, and what would have to be true for this to be worth doing. If it is not a fit, we say so on that call.

YOU: 2–3 PEOPLE, 90 MINUTES
Weeks 1–2

Diagnostic workshop and success measures.

A working session with the team who will use it. We pick two or three workflows, write down the measures the pilot will be judged on, and produce the data-handling note: which sources, which fields, which AWS region, who has access, how long it is kept.

OUTPUT: SCOPE + SUCCESS MEASURES + DATA NOTE
Weeks 2–4

Workspace stood up on your sources.

Your isolated tenant is deployed in your chosen AWS region and connected to the agreed systems, read-only wherever the source allows it. This is usually the step that decides the timeline, because it depends on access approvals rather than on us.

YOU: IT + SOURCE OWNERS
Weeks 4–10

Your team uses it on real weeks.

Five to twenty users, working the two or three chosen workflows against live market movement. We meet weekly, watch where it is wrong or unclear, and tune it while the pilot is still running. That is the design-partner part.

YOU: 5–20 USERS, WEEKLY CHECK-IN
Weeks 10–12

Read-out and a decision.

We measure against what was written down in week 1 rather than against a story assembled afterwards. You get the findings, the audit record, and a straight recommendation: continue, narrow, or stop. If it is stop, your data is exported and deleted.

OUTPUT: GO / NO-GO + FINDINGS

Who does what

What each side brings.

Northra brings

  • The diagnostic workshop and the scoping work.
  • An isolated workspace in your AWS region, stood up and connected.
  • Two or three workflows configured to your products, contracts and regions.
  • A weekly working session, and tuning while the pilot runs.
  • The data-handling note, and your security questionnaire completed.
  • The read-out, measured against the agreed numbers.

You bring

  • A commercial sponsor who owns the outcome.
  • 5–20 users who will actually use it in their week.
  • Read access to the agreed sources, with your usual approvals.
  • One IT or data contact for the connection work.
  • An hour a week for the working session.
  • Honest feedback when the output is wrong or unclear.

What gets measured

Pick the measures that would convince you.

These are the ones design partners usually choose. Two or three is right. Ten is a way of avoiding a verdict.

MeasureWhat it answersHow it is judged
Time to detectionHow long between a market move and someone in the business knowing what it does to us?Against your current baseline for the same workflow
Exposure identifiedDid it find contracts, accounts or clauses the current process missed?Reviewed case by case with your team
Actions takenHow many proposals became a real commercial action, and what happened?From the audit record, with outcomes attached
Preparation timeHours returned to senior commercial people who were assembling the picture by hand.Self-reported by the users, before and after
Trust in the outputWould the team rely on this without re-checking it themselves?Asked directly at the read-out, where a no is still useful

Common questions

The ones that come up first.

01Does our data leave our environment?

It is stored and processed inside AWS, in the region you choose, in a tenant isolated from any other customer. That includes the AI inference. It is never used to train models that another customer touches. The full picture, including what we do not claim, is on the security page.

02What if our security review blocks source access?

Then start narrower. A pilot on market data, published sources and a limited slice of your own book still shows whether the reasoning holds up. It is a weaker test, but it is a real one, and better than a pilot that never starts.

03How much of our IT team's time does this take?

Concentrated in weeks 2–4, for the connection work, and it is mostly approvals rather than engineering. One named contact is enough. After that the pilot is run by the commercial team, not by IT.

04What does it cost?

Design-partner pilots are priced per engagement and depend on scope: the number of workflows, sources and users. We put a figure in writing after the scoping call, once we both know what is actually being built. We would rather not quote a number before we understand the problem.

05What happens if it does not work?

We say so at the read-out, and you keep the findings. That includes the map of where your decision data actually lives, which is usually worth having on its own. Your data is exported and deleted on request.

06Do we have to replace anything we already run?

No. Northra sits above your ERP, CRM and reporting rather than replacing them, and by default it does not write back into them. Switching it off leaves your systems exactly as they were.

How to book it

Three steps, and the first one is a conversation.

Send us a note with your industry, the business unit you have in mind, and one decision that is currently too slow. We will come back within two working days with either a scoping call in the diary or the reason we are not the right fit yet.

Book a scoping call

Or write directly to hello@northra.ai. Before you commit to anything, the security and data page covers where your data would live, including what we do not claim.

WHAT TO SEND US

  • Your industry and the business unit in scope
  • One decision that is currently too slow, and roughly what it costs
  • Which systems hold the data behind it
  • Who would own the outcome internally
  • Any hard constraint we should know about now: a security gate, a timeline, a budget cycle