Section 12 · Intent — Know When an Old Lead Is Heating Up

12.2High-intent page behavior

Designed for Phase 2

No.: 12.2
DMA's reference: Decision Book p.26
Phase: Phase 2
Autonomy: L1 · Recommend
DMA's decision: Yes

What DMA asked for · Decision Book p.26

Repeat visits to enterprise pages, case studies, pricing or contact, or to several services, count as a buying signal.

Why it matters to DMA: It sharpens "they visited" into "they visited with intent".

In our words, from DMA's Product Decision Book v3, page 26.

How we do it

Scheduled for Phase 2 in DMA's book, after website-return detection. The design uses the same visit history.
Each DMA page gets an intent weight in a small, approved list: pricing, contact, case studies and enterprise pages weigh most; blog posts least. The list is a rule DMA can edit, not code.
Rules add up a visitor's weighted visits over a rolling window (for example 7 days) and note when several services are looked at, which also feeds the multi-service detection in section 2.
Crossing a threshold adds a "high-intent behaviour" reason to the account's score, with the pages that caused it listed in plain words.

Already in place

Every CRM account already has a 0–100 score, an A/B/C tier and one next best action, recalculated when the data changes.
Rules in the POC are already versioned and approved by a person (Govern → Rules), which is where the page weights would live.
The chat widget keeps an anonymous visitor id in the browser, and every chat records the page it started on and the campaign tags of the link.

What the later phase adds

The page-weight list and the rolling-window rule.
Visit history from the site tag (12.1).
The "high-intent behaviour" reason in the score, with the pages listed.

The flow

It plays on its own while it's on screen; hover or use the controls to pause or step through.

Step 1 of 4

Visits come in

A known contact views the pricing page twice and a dental case study.

Person
Stored data
Rule in code
Routing

Where the data goes

The same six stages on every page. Nothing reaches Nutshell except through the write gate.

1DMA's website
Source
Page views (from 12.1).
2Sync
Copies Nutshell changes into the bridge database
Not involved.
3Bridge database
A copy of the CRM data, plus what the AI works out
Visit history and the approved page-weight rule.
4AI
Claude models, only through DMA's own gateway
Not needed: the weights and threshold are rules.
5Write gate
The only way back into Nutshell: checked, approved when needed, sent once
Optionally writes the reason onto the Nutshell record.
6Nutshell
The system of record
The rep sees which pages showed intent.

The tables behind it

Drawn from the POC's database catalogue: structure only, no data.

PK primary keyFK reference the database enforces (solid line)ID reference kept by id (dashed line)

Table	What it holds	Columns
ctrl.policy_rules	Versioned, approved rules; the page weights and threshold would be one.	21
ai.scores	Where the new reason code lands.	20

How the tables connect (2)

Column	Points to	Kept by
ctrl.policy_rules.approval_id	ctrl.approvals	The application (by id)
ai.scores.prompt_id	agent.prompts	The application (by id)

Worked example

Synthetic demo data: every name, business and number is made up.

A week of visits for one known contact, and the rolling total (synthetic example; weights as designed).

Seven days of visits

Page	Visits	Weight	Points
Pricing	2	5	10
Case study: dental group	1	4	4
Blog: local SEO tips	3	1	3
Total (threshold 12)	6		17

In the running POC

There is no screen for this one yet: it is designed for Phase 2, as DMA's book decides. The parts listed under “Already in place” run in the POC today.

See it live

Opens the exact screen in the running POC, in a new tab.

Open	Where	What to try
Rules	DMA AI dashboard	Where an approved page-weight rule would sit.

Status

Designed for Phase 2

Designed for Phase 2. DMA's book schedules this for Phase 2. The design is ready and builds on parts that already run in the POC.