Customer intelligence
Your customer data is spread across systems. Start with one decision, such as who needs attention or which action is worth taking, and test it against the record you already hold.
NTWRK / AI-NATIVE INTELLIGENCE YOU OWN
Quiet intelligence
beats loud platforms.
NTWRK is a Melbourne consultancy that builds intelligence into the systems your business runs. We start with a 30-day proof of concept.
30 DAYS · RANK THE USE CASES · TEST ONE · DECIDE WHAT COMES NEXT
Your team can check
- The record
- The decision logic
- The workflow
- The handover
Services it may still need
- Hosting
- Model usage
- Licences
SELECTED CLIENTS
01 / TWO ENTRY POINTS
Start with the problem in front of you.
Operating intelligence
Your team has a process that takes too much manual work, or an AI pilot that never became useful. Start with that workflow and test what should change.
Before your next renewal: five questions about what stays when the contract ends.
02 / THE FIRST 30 DAYS
Assess widely. Prove one thing.
We review the decisions worth improving, rank the possible use cases and test one against criteria agreed before the build. At the end of 30 days, you have evidence for the next decision: build, buy, change the process or stop.
The assessment
A record of the current systems, data and working practices relevant to the problem.
The priorities
The use cases assessed, ranked by value, feasibility and risk.
The proof
A working proof of concept, with its test results and known limits.
The recommendation
A decision pack that sets out the evidence and what should happen next.
The POC tests an idea on agreed cases. It does not establish production readiness or guarantee a return. It runs in your environment or an agreed, controlled NTWRK workspace. The scope sets out access, deliverables and handover. Any production build is agreed separately.
03 / WHAT WE BUILD
What a working build can include.
The use case determines the build. These are the parts we may need, with the deliverables and dependencies agreed in the scope.
Records and signals
-
Customer record
Customer data, source mappings and definitions brought into a record your team can use.
-
Signals
The behaviours and events that matter to the decision being tested.
Decisions and workflows
-
Model
Scoring or prediction logic, with the tests and documentation needed to review it.
-
Decisions
Rules that turn the evidence into a recommended next action.
-
Workflows
The steps that carry the decision into the tools your team uses.
-
Agents
AI assigned to a defined task, with agreed permissions, checks and escalation points.
Measurement and handover
-
Measurement
A baseline and outcome measures that show whether the work is useful.
-
Handover
Documentation, runbooks and training for the people responsible for the completed work.
04 / WHY OWNERSHIP MATTERS
Your next supplier decision should include the exit.
A useful system needs an owner inside the business. Someone must be able to inspect the logic, approve a change and keep the work running when a supplier relationship ends.
Before the next contract, ask for the deliverables, access rights, ongoing costs and handover responsibilities in writing. That makes the ownership claim something you can check.
05 / FOR LEADERS
Bring the people who need to trust the decision.
Marketing, operations, data, finance and risk will ask different questions. The proposal should answer them before the build starts.
06 / FAQ
Questions worth answering first.
What does the 30-day POC give us?
You get an assessment of the current situation, a ranked set of use cases, one working proof of concept and a recommendation on what to do next. Before we build the POC, we agree its test cases and success criteria. A production build is a separate decision, based on what the proof shows.
Do we need perfect data before we start?
No. We need enough access to assess a useful problem and understand the limits of the data behind it. The first step is to find out what can be tested, what needs fixing and whether a build makes sense. Bring the decision you want to improve and the systems involved.
What happens if we stop after the POC?
We hand over the agreed findings, test results, documentation and completed POC artefacts. The scope sets out their format, where the work runs and any remaining dependencies. Stopping after the proof is a valid outcome. The point is to make the next commitment with evidence, including evidence that says stop.
Can our internal team run the finished work?
That is a delivery requirement to agree before the build. We identify who will own the work, what access they need and what documentation and training the handover must include. A completed POC may still need further work before production. Ask to see the handover responsibilities in the scope.
07 / BUILD TO KEEP
A useful next read.
Wes Fischer writes about the decisions behind the build: what to keep, what to question and what to test before committing. Read a field note, then subscribe if it earns a place in your inbox.
You're subscribed to Build to Keep. The next issue will arrive by email. Every issue includes an unsubscribe link.
Check your inbox. We've sent a link to confirm your subscription. Click it to receive Build to Keep.
We couldn't complete your subscription. Please try again in a moment.
Email delivery is stopped for this address.
We haven't sent a confirmation email. If you'd like us to check the delivery status, email hello@ntwrk.com.au from this address.
START WITH THE DECISION
Bring the decision worth testing.
Start with a 30-minute conversation about the problem, the systems involved and what a useful proof would need to show.