Productize Intent Reporting: Client Workflow and Portal Costs

Current MarketPulse research workflow

BrandWell MarketPulse: intent data starting at $500/mo. Find people researching topics relevant to what you sell, apply saved ICP filters, and review available contact details before taking action.

MarketPulse plans are starting at $500/mo. Verify current package scope and offers on the product page.

MarketPulse standard monthly plans

Plan	Topics and refreshes	Monthly exports
Starter	1 topic, weekly	25,000 contacts
Growth	3 topics, daily	100,000 contacts
Scale	10 topics, daily	Unlimited contacts

Swipe the table to see all columns.

A pull retrieves available data from the previous 24 hours for one topic. Daily use across all included topics provides 90 Growth pulls or 300 Scale pulls in a 30-day month. Weekly Starter pulls vary by calendar month. Available audience size and contact fields vary, and audiences may overlap. Refreshes stop at the plan limit without overage charges.

• Find and qualify: search the topic catalog, save your ICP, and review the people and companies that match.
• Act on the research: export qualified contacts or prepare an Outreach or Direct Mail workflow. Connected products, channel usage, and fulfillment may cost extra.
• Get help from AIMEE: Growth and Scale include AIMEE for the initial user to research accounts and prepare the next step through connected tools.

Agencies and other service businesses can build client deliverables around their available Intent Scans and exports. Keep each client’s scope, permissions, and service fees clear. A subscription is not a promise of a white-label platform or exclusive access to a market.

Explore MarketPulse and watch the demo or compare plans starting at $500/mo. Any early-access discount is a separate, time-limited offer shown to an eligible recipient.

Design backward from an accepted client action

Design backward from the first useful client action. Choose one contracted signal type, one review role, one destination, and one disposition. Show the client how a record enters, what confidence is known, how it is qualified, and where the response is recorded. That narrow route creates time to value faster than a portal containing every possible chart.

Standardize the seven modules, but configure fields and actions by client. A client using a CRM may need an assignment receipt and stage feedback. A client without reliable integration may need a controlled review queue and export approval. The underlying operating model stays consistent even when the delivery surface changes.

Use progressive disclosure. Put the next decision at the top, evidence one layer below, and governance details where authorized users can inspect them. Never make a heat color or score appear more certain than its source. For reporting cadence and audience design, use BrandWell’s guide to weekly and monthly intent-data reporting.

Define the first-value event with the client before configuration. It might be an accepted company record with a clear reason, a successful handoff into the CRM, or a completed topic decision. A login, page view, or published panel is not automatically client value. The portal should make the chosen event easy to verify.

Define states, owners and destination receipts

Begin with an intake record covering scope, topics, source rights, identity policy, destinations, roles, retention, branding, client dependencies, and acceptance. The delivery owner publishes or approves the feed. An analyst owns exceptions and sampling. The client owner accepts, rejects, and assigns. A technical owner monitors integrations. A privacy or security reviewer handles new purposes, exports, access, and incidents.

1. Receive: validate contracted source, expected schema, timestamp, and tenant.
2. Inspect: check completeness, duplicates, identity state, exclusions, and freshness.
3. Publish: place accepted records in the correct client workspace and confirm entitlement.
4. Notify: alert only the approved role using the agreed severity and cadence.
5. Activate: record assignment or destination receipt without assuming follow-up occurred.
6. Reconcile: compare portal, integration, and client-system states; open exceptions.
7. Review: document decisions, scope changes, and unresolved dependencies.

Service levels should cover observable agency-controlled work: feed checks, portal publication, exception acknowledgment, restoration communication, and scheduled review. State clock pauses and client dependencies. The handoff is complete only when the destination receipt or human acceptance is recorded.

Evaluate custom portal and integration requirements

Evaluate capability groups rather than declaring a universal winning platform. The stack may include a white-label portal, data source and enrichment, identity and validation, workflow or ticketing, CRM or marketing connectors, access management, file or object storage, monitoring, and an evidence ledger. The portal must isolate tenants, support roles, expose update history, and export what the contract permits.

Useful templates include a field dictionary, role matrix, portal acceptance test, delivery runbook, incident note, change request, client review, retention schedule, and offboarding checklist. Integrations need destination ownership, credential custody, retry behavior, duplicate handling, reconciliation, and rollback. A connector logo is not proof that those controls exist.

Run a sample through the same route clients will use. Inspect mobile and accessible behavior, empty states, error messages, notification load, export boundaries, and how corrections appear. BrandWell’s CRM and marketing-stack integration guide provides a companion state model.

Compare manual and automated delivery

Do not automate a disputed definition. Resolve what counts as delivered, accepted, activated, and measured first. Then automate the stable state changes and keep exceptions visible. White-labeling should change the client experience, not conceal the underlying responsibilities or data origin where disclosure is required.

Price setup and ongoing exception repair

There is no responsible universal setup fee. Model discovery, information architecture, branding, tenant configuration, data mapping, integration, access setup, QA, training, documentation, and risk review. Recurring cost includes wholesale modules and usage, hosting or portal licenses, monitoring, analysis, reporting, client service, support, exception repair, security work, and allocated overhead.

Use the agency’s own cost and contribution target. Keep optional integrations and custom support separately scoped. A low setup fee may be rational for a standardized configuration, but only if the recurring term and actual workload support it. Do not present a gross-margin benchmark or ROI figure without comparable, verified evidence.

Measure first value and completed actions

Time-to-value should measure a real milestone: time from approved scope to first accepted signal, first assigned action, or first completed review. Quality measures include schema pass, duplicate rate, identity-confidence distribution, exclusion accuracy, destination receipt, and exception resolution. Adoption measures include active approved users, completed reviews, dispositions, assignments, and stale items.

Outcome metrics must preserve evidence levels. Record campaign or sales actions, meetings, opportunities, pipeline, and revenue only from the agreed system and with sourced, influenced, associated, or unknown labels. Portal views alone do not prove value. A small number of decisive actions may be more useful than high login volume.

Include operational economics privately: cost to serve, support load, custom-work hours, and contribution. Review metrics by client maturity and package. Do not combine records with different definitions just to create a larger sample.

Pair every metric with an owner and response

A metric is operational only when its threshold causes a documented action. A growing stale-item count might trigger client enablement, routing repair, or a smaller feed. A rising exception count might trigger source review. A longer time-to-first-action might expose notification noise or missing ownership.

Document the threshold, reviewer, response, and evidence of closure. Avoid automatic penalties or client-facing claims based on a single noisy period. Use the metric to ask a focused question and let the accountable owner approve the response.

Adapt delivery to the client workflow

An early-stage client may need a curated signal inbox, a human qualification review, and a simple action worksheet. A client with a disciplined CRM can use automated assignment, receipt reconciliation, and outcome association. A mature client may need more granular roles, multiple destinations, warehouse delivery, governed exports, and a formal change process.

Package differences should be explicit. A base tier might include one workspace, agreed topics, standard refresh, one review, and standard support. Additional modules might cover extra destinations, deeper analysis, more frequent review, or approved integrations. Never make security basics an optional luxury. Tenant isolation, access control, logging appropriate to the risk, and offboarding belong in every package.

When the client’s stack is weak, do not force automation. A controlled manual handoff may produce better evidence and less risk. The plan should include a maturity gate for moving to the next delivery method.

Preserve the source-to-action chain

Each portal row should preserve the chain from source to action. Show the signal type and recency, approved topic, company identity, person identity if permitted, contact-validation state, fit decision, exclusions, destination, owner, action, and result. Keep company-level and person-level claims visibly separate. A company match does not reveal which individual researched a topic.

Activation states should be explicit: proposed, approved, sent, received, assigned, completed, suppressed, failed, or unresolved. Define which system owns each state and how reconciliation works. If an export breaks the evidence chain, require a receipt or import confirmation.

Outcome evidence should link back to the signal without implying causation. Preserve source records, client dispositions, and attribution labels. If the client does not provide outcome data, mark it unavailable rather than substituting portal activity.

Review scope, access and support risks

Scope risk appears when users, topics, refreshes, destinations, exports, custom analysis, or support expand without change approval. Data risk includes excessive fields, mistaken identity, duplicate tenants, uncontrolled downloads, and unclear retention. Integration risk includes expired credentials, silent retries, field overwrites, loops, and destination changes. Expectation risk appears when a polished portal is presented as proof of buyer certainty or business results.

The NIST authentication guideline distinguishes authentication assurance levels. Have the responsible reviewer select controls for the actual risks and context. It does not certify this proposed portal or establish a universal obligation for every agency.

The NIST Privacy Framework can help organize privacy risks. It is voluntary and does not certify the portal. Actual obligations depend on contract, jurisdiction, data, and use, so obtain qualified review.

Use a portal release gate

Before launch, ask separate owners to accept the workflow, data, access, and support views. The workflow owner checks states and actions. The data owner checks fields, identity labels, and corrections. The security or privacy owner checks roles, exports, retention, and incident routing. The account owner checks branding, expectations, training, and contract alignment.

Release only after critical defects are closed or explicitly accepted by an authorized person. Record the accepted version, known limitations, rollback owner, and first reconciliation point. This makes launch a controlled handoff rather than a promise that the portal will never fail.

Define the recurring custom service

The recurring package needs contracted modules and entitlements, source and identity definitions, a branded workspace, controlled roles, agreed refresh, QA, action ownership, destination monitoring, evidence, review cadence, change control, retention, offboarding, support boundaries, and a current client runbook. The white-label experience should make the agency accountable, not obscure data-use limits.

AIMEE can help prepare approved reporting and exception summaries through configured connected tools. Review sources, missing states and the actual destination before action. Do not assume it provisions custom portals, tenant access or unsupported integrations.

Start with supported MarketPulse research starting at $500/mo and save the approved client ICP. A custom reporting portal, integration, authentication system and service agreement are separately scoped work. Confirm actual supported fields, exports, terms and destinations before configuration.

Use BrandWell’s intent-data delivery SOP to connect the portal modules to the operating handoffs behind them.

ROLE: Act as a portal operations tester. Do not grant access, change production data, or approve compliance.

INPUTS:
- signed module and entitlement matrix
- field dictionary and identity-state definitions
- sample records using only approved necessary data
- user roles, destinations, retention, and support rules
- acceptance tests and known exceptions

TASK:
1. Trace each sample from signal inbox through evidence ledger.
2. Verify the company, person, and contact states remain separate.
3. Test expected, empty, duplicate, stale, failed, and suppressed states.
4. Compare portal and destination receipts.
5. Draft an exception list, owner list, and launch checklist.

STOP CONDITIONS:
- Do not invent missing identity or outcomes.
- Do not expose one tenant to another or copy unnecessary personal data.
- Do not publish, export, invite users, change permissions, or trigger outreach.

HUMAN APPROVAL REQUIRED:
The delivery owner accepts functionality. The client owner accepts workflow. Authorized technical, privacy, security, and legal reviewers approve applicable controls. A human authorizes launch and every production change.