ntwrk/
Scope the 30-day POC
CUSTOMER INTELLIGENCE

Customer decisions from data you own.

The record, the signals, the decision logic, and the workflows that improve acquisition, service, retention, and value. In your environment, run by your team, yours to keep.

01 / THE GAP

The data kept growing. One customer truth never arrived.

Most businesses hold more customer data than ever, spread across the CRM, the email tool, the analytics account, the warehouse, and a spreadsheet someone guards. Ask the room which customers are worth keeping and you get five different answers.

That is a decision problem before it is a data problem. Five definitions of value produce five treatments. One customer gets the discount, the win-back call, and the loyalty invitation in the same week. Another gets silence. No outcome flows back into a record anyone trusts, so nobody can say which treatment worked.

The fix is not a promise to unify everything. It is one customer decision worth improving, built against your own record, with the outcome measured and written back. Start there. The one customer truth gets built a decision at a time.

One owned tile on the composable canvas A grid of eight neutral, interchangeable tiles forms the composable martech canvas, all assembled from the same shelf. One tile is set apart: the record of why, the single layer you have to own. THE COMPOSABLE CANVAS data identity audiences agents activation analytics governance the record of why OWNED, NOT RENTED
Everyone can assemble the same canvas from the same shelf. The one tile you have to own is the record of why.
02 / WHAT WE BUILD

Six artefacts. One standard: your team runs it.

Everything lands in your environment, on the warehouse you already run, documented so your team can inspect and change it.

governed_record.schema

The governed record

Identity rules, source mappings, and one set of definitions for the customer record in your environment.

customer_signals.set

The signals

The behavioural, commercial, lifecycle, and service signals that show where each customer stands.

decision_logic.spec

The decision logic

Scoring, segmentation, and next-best-action rules your team can inspect, version, and change.

activation.workflow

The activation

The working workflow where the decision changes an action: an offer made, a call queued, a message held back.

measurement.board

The measurement

The baseline, the outcomes against it, and the improvement backlog, readable by your team.

capability.runbook

The capability

Documentation, named owners, and training, so the whole system keeps running after we leave.

Handover is part of the build, not a phase after it. The standard is checkable: remove NTWRK and the record, the logic, and the workflows keep running.

03 / THE FIRST 30 DAYS

The first month earns the second.

Every engagement starts the same way: a 30-day proof of concept. We map the decisions worth improving, from the customer record to the operating workflow, rank them, and build one POC against a bar you set before we start. Day 30 ends with evidence and a recommendation: build, buy, change the process, or stop.

A POC proves the idea on cases you chose, against a bar set before we built anything. It is not production, and it is not a promised return. It runs in your environment, or in a controlled NTWRK workspace where access requires it. The boundary is stated in the scope.

Scope the 30-day POC See the full method
04 / GOOD CANDIDATES

Four questions find the decision.

Start with the customer decision your team repeats most often, or the one that costs the most when it goes wrong. Then ask:

  1. Is the decision repeated often, or material when it happens?
  2. Can you describe what a better decision looks like, clearly enough to measure it?
  3. Is the first-party data available, or are the gaps in it at least measurable?
  4. Is there a real workflow where the result changes an action someone takes?

Four yeses earn a controlled test, not an automatic build. The test runs against cases you choose, and what it produces stays with you either way. The argument for keeping the intelligence layer while the tools around it change is in the field note: Rent the platform. Keep the customer intelligence.

05 / WHEN NOT TO BUILD

Rent the standard. Build the distinctive.

Rent or configure an existing product when the decision is standard for your industry, the workflow is not where you compete, switching later is manageable, and the supplier gives you real access to your data and your decision records. Plenty of tools clear that bar. Use them.

Build when the decision carries distinctive knowledge of your customers, when the volume or the consequence is real, and when you will maintain what gets built. A system nobody maintains becomes next year's stalled pilot.

Teams often arrive here weighing alternatives to Segment or Salesforce Data Cloud. The real comparison is shape, not features: a packaged platform keeps the customer record in its store, and this build keeps it in your warehouse.

The 30-day recommendation treats buy, change the process, and stop as real answers, and we put them in writing when they are right. Whichever way it goes, the intelligence underneath the tools should sit where your team can keep it.

The customer model stays; the tools change A central box labelled the customer model, in your warehouse. Four tool boxes surround it: activation, analytics, identity, messaging, each drawn with a dashed border and a swap mark, connected to the centre by hairlines. The centre is solid; the tools are replaceable. ACTIVATION ANALYTICS IDENTITY MESSAGING replaceable replaceable replaceable replaceable THE CUSTOMER MODEL in your warehouse
Tools change without moving the model. The learning underneath them stays put.

START WITH THE DECISION

Bring the customer decision that should work better.

Thirty days later you have the evidence, the working proof, and a recommendation you can fund or decline. The four questions above tell you which decision to bring.

Scope the 30-day POC Read the field notes