On this page
- Current MarketPulse research workflow
- Keep actual client boundaries explicit
- Define client-scoped objects and versions
- Use five portfolio control layers
- Name daily handoff owners
- Compare separately implemented delivery
- Budget direct and shared costs
- Measure per-client costs and outcomes
- Check actual client operating scope
- Preserve distinct evidence and action units
- Hold unresolved access and billing requirements
- Scope current BrandWell capabilities
- Verify controls before adding clients
- Frequently asked portfolio questions
- Copyable client-scoped operating record
Manage agency clients with explicit client identity, permissions, versioned configuration, credentials and output boundaries. Reuse a workflow only after testing its actual client context and destination checks. Attribute QA, costs, billing and outcomes to each client; a workspace label or shared schema does not prove isolation.
Who is this for? Agency owners, delivery leads, paid-media teams, RevOps consultants, and client-service operators moving from a few bespoke intent engagements to a managed recurring portfolio.
Current MarketPulse offer: intent-data plans start at $500/mo. See the product, demo, and current plans. Updated October 3, 2026.
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.

| 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.
Keep actual client boundaries explicit
Managing intent data across many clients becomes dangerous when the team treats a collection of folders as a multi-tenant system. Client separation has to follow the record everywhere: source ingestion, normalization, identity resolution, enrichment, suppression, activation, exports, reports, logs, backups, and deletion. One missing boundary can expose data or send an action to the wrong account.
The agency should share a vocabulary, workflow engine, quality method, and service catalog. It should not share client records, credentials, destination IDs, exclusions, examples, or detailed performance without authority. This distinction lets operations improve once for the portfolio while preserving each client’s decisions and data obligations.
Make the client ID a required object, not optional metadata. Jobs should fail closed when a client context is missing or conflicts with a credential, destination, or configuration. A useful operating rule is: no input, record, action, or report exists without a tenant, owner, permitted purpose, and lifecycle state.
Define client-scoped objects and versions
A multi-client model needs separate objects for the client, program, topic, source, signal, account, identity candidate, validated contact, suppression, activation, destination result, seller action, outcome, invoice unit, and exception. These objects may live in one platform or several systems, but their relationships should be explicit and testable.
- Client configuration: market, ICP, topics, evidence windows, confidence rules, exclusions, destinations, and approvers.
- Operational state: queued, normalized, held, rejected, approved, activated, reconciled, actioned, or suppressed.
- Commercial state: included allowance, usage, setup work, custom scope, overage, credit, and renewal evidence.
- Governance state: provenance, permitted purpose, retention, access, lawful-use review, deletion, and incident history.
Version configuration rather than overwriting it. When a topic, threshold, or destination changes, preserve who approved the change and which records used each version. That history prevents debates about why two months produced different outputs and makes a rollback possible.
Use five portfolio control layers
These five control layers form a practical portfolio-operations list. Each is evaluated against the same seven criteria so the agency can see its operational value, cost, and limitation. Implement separation before shared automation, then add capacity, client-level QA, and exception control.
1. Separate client workspaces and permissions
Best fit and exclusions: Best for every multi-client service, even when the first clients are small. Each client needs a distinct workspace, configuration namespace, credential set, storage boundary, output location, and user-access policy. Shared master files are an exclusion, not a shortcut.
Inputs and prerequisites: A client identifier that cannot be confused, documented data flows, named users and roles, destination ownership, credential inventory, retention and deletion rules, and an offboarding procedure tested before it is needed.
Implementation effort and ownership: A security or operations owner designs roles; client leads request access; an independent approver grants it; the system logs changes. Provisioning and deprovisioning should follow a checklist instead of a message in chat.
Data, privacy, and governance risk: Cross-client exposure is the defining risk. Apply least privilege, role-based access, separate service accounts, scoped tokens, client-specific encryption or storage controls where appropriate, and recurring access review.
Cost drivers: Workspace licensing, storage, secrets management, identity administration, access reviews, offboarding, audit evidence, and support. These costs grow with clients and users, not only record volume.
Measurement and revenue relevance: Track unauthorized-access findings, stale users, shared credentials, provisioning time, offboarding completion, cross-tenant incidents, and the percentage of access with a current owner and purpose.
Meaningful limitation: Logical separation depends on correct implementation and testing. A workspace label alone does not prove that queries, exports, caches, backups, or automations are tenant-safe.
2. Use shared automation with client-specific rules
Best fit and exclusions: Best when the same deterministic steps recur across clients: normalize, validate, suppress, route, reconcile, report, and alert. Keep client ICP, topic map, confidence gate, destinations, and approvals in scoped configuration.
Inputs and prerequisites: Versioned workflow code, tenant-aware configuration, test fixtures, default-deny behavior, client-specific secrets, an exception queue, and rollback. Every job must receive a client context rather than infer it from a filename.
Implementation effort and ownership: Engineering or automation operations owns the shared workflow; client strategy owns configuration; QA tests representative and edge cases; authorized owners approve material rule changes.
Data, privacy, and governance risk: A shared workflow can spread one error to every client. Test tenant isolation, permission scope, suppression behavior, logging, and failure containment before increasing automation coverage.
Cost drivers: Build and maintenance time, orchestration tools, connector updates, monitoring, retries, test environments, and exception handling. Automation pays when stable volume exceeds the cost of ownership.
Measurement and revenue relevance: Measure automated completion, manual touches, exception rate, retry rate, time saved, defect escape, per-client latency, and downstream acceptance. Review by workflow version as well as client.
Meaningful limitation: Automation makes bad rules faster. It should not decide a new lawful purpose, erase identity uncertainty, or interpret a client’s market without a governed configuration and review path.
3. Control portfolio capacity and unit economics
Best fit and exclusions: Best before adding the next client or module. Capacity planning links client demand to topic volume, records, analyst review, destination complexity, report load, meetings, and support instead of relying on headcount intuition.
Inputs and prerequisites: A service catalog, included units, normal and peak usage assumptions, labor standards, client-specific complexity factors, queue limits, support severity, and cost allocation for shared infrastructure.
Implementation effort and ownership: Operations forecasts workload; finance validates cost and contribution; account owners surface upcoming changes; sales checks capacity before committing. A single owner resolves conflicts when demand exceeds limits.
Data, privacy, and governance risk: Pressure to meet volume can weaken QA, encourage broad permissions, or delay deletions. Capacity controls should trigger reprioritization or a commercial conversation, not quiet shortcuts.
Cost drivers: Data and platform charges, analyst time, client success, engineering, QA, storage, reporting, actual support expense, with unused contingency tracked separately, and unused committed capacity. Allocate shared cost with a consistent driver.
Measurement and revenue relevance: Track contribution per client, direct labor, records per analyst hour, utilization, queue age, peak-to-normal usage, support hours, exception load, and revenue per constrained resource.
Meaningful limitation: Averages hide expensive clients. Use client-level costs and percentile or peak views so one complex account does not consume the margin attributed to the rest of the portfolio.
4. Keep QA and outcome reporting client-specific
Best fit and exclusions: Best because the same source can perform differently by market, topic, geography, and action. Use a common QA method but sample, threshold, and report results within each client’s context.
Inputs and prerequisites: Client-specific acceptance rules, sample plans, known negatives and positives, destination reconciliation, seller disposition, outcome taxonomy, report owners, and an escalation threshold.
Implementation effort and ownership: QA owns release evidence; client leads interpret results; data or automation owners correct defects; client stakeholders confirm whether accepted records led to the intended action.
Data, privacy, and governance risk: Portfolio averages can conceal a failing client and can expose another client’s information if examples are reused. Reports, screenshots, downloads, and benchmarks must remain tenant-safe and appropriately aggregated.
Cost drivers: Sampling, investigation, reprocessing, report production, client review, outcome mapping, and corrective action. Charge for deeper custom analysis rather than letting it become invisible monthly work.
Measurement and revenue relevance: Use freshness, completeness, match-confidence distribution, activation acceptance, seller use, qualified outcomes, rework, and incident measures for each client. Compare trends, not confidential client rankings.
Meaningful limitation: Outcome data matures slowly and is influenced by many factors. Reporting can show progression and association, but it should not turn every intent signal into a causal revenue claim.
5. Operate exception, escalation, and change control
Best fit and exclusions: Best as the portfolio safety valve. It gives unusual records, broken connectors, privacy questions, billing disputes, urgent client changes, and quality incidents a visible queue with owners and deadlines.
Inputs and prerequisites: A ticket or case ID, client ID, severity, affected objects, evidence, temporary containment, owner, approver, communications plan, resolution, and follow-up action. Never troubleshoot client data in an unscoped shared channel.
Implementation effort and ownership: Front-line operations triages; specialists investigate; an incident or service owner coordinates; account leads communicate; commercial owners approve scope or credits. High-impact incidents need a retrospective.
Data, privacy, and governance risk: Exceptions often contain the most sensitive evidence. Limit access, redact examples, preserve logs, stop affected automation, and avoid copying records into unmanaged documents.
Cost drivers: On-call time, investigation, reprocessing, client communication, credits, engineering fixes, and preventive work. Maintain a reserve and attribute recurring causes to the right client, source, or workflow.
Measurement and revenue relevance: Track open age, time to contain, time to resolve, repeat incidents, affected clients, reprocessing cost, root-cause category, and completed preventive actions.
Meaningful limitation: A ticketing process does not replace judgment. Teams still need authority to pause delivery immediately when client separation, personal data, spending, or trust may be at risk.
Name daily handoff owners
A daily run should begin with tenant-aware intake. Validate that the source, client, topic map, configuration version, and permitted destination agree. Normalize and score inside the client context. Route ambiguous or high-consequence records to a scoped review queue. Activate only through that client’s credential and destination mapping. Reconcile accepted and rejected counts before the output is marked complete.
Ownership should follow the decision. Data operations owns ingestion and normalization. Strategy owns topic and fit interpretation. QA owns release evidence. Security or a designated administrator owns access controls. The account lead owns client communication and configuration requests. Finance owns reconciliation of wholesale usage, delivery cost, retail billing, and credits. A service owner resolves cross-functional tradeoffs.
A weekly portfolio review should focus on exceptions, capacity, defects, usage anomalies, aged queues, and upcoming changes. A client review should focus on evidence, adoption, outcomes, and requested decisions. Do not turn an internal operational review into a client presentation or expose cross-client details for comparison.
Compare separately implemented delivery
Spreadsheets can support early discovery, controlled samples, and a small number of non-sensitive configuration choices. They are weak as a multi-client system of record because copying, permissions, formulas, exports, and deletion are hard to govern consistently. Use them as scoped views, not the only boundary protecting client data.
Custom automation provides control and can fit an agency with engineering skill, stable volume, and unusual workflows. Its total cost includes tenant architecture, secrets, connectors, monitoring, test coverage, support, and incident response. A separately implemented client platform requires verification of workspaces, branding, modules, reporting, effort and delivery timing, but the agency must verify tenant isolation, roles, exports, retention, sub-processors, and contract terms.
No model removes agency responsibility. NIST describes least privilege as giving users and processes only the access needed for assigned tasks and reviewing privileges on a defined cadence. Its role-based access guidance also supports separation of duties. Apply those principles proportionately to the actual systems and risk.
See the NIST least-privilege control and NIST role-based access control overview for primary guidance.
Budget direct and shared costs
Budget by client and by shared capability. Direct client costs include data or topic usage, enrichment and validation, destination usage, analyst review, client meetings, custom reports, support, and approved exceptions. Shared costs include the platform, orchestration, engineering, security, QA leadership, documentation, sales enablement, and management.
Choose allocation drivers that match consumption. Topic and record fees can follow usage; analyst and support costs can follow time or complexity; shared platform and governance can follow active clients or a weighted tier. Keep the model explainable. If an allocation changes the apparent margin dramatically, review both the method and the underlying delivery design.
Forecast normal, peak, and failure conditions. A normal month may fit the retainer, while a new destination, reprocessing event, urgent topic expansion, or large review queue can exceed capacity. Define setup, included scope, overage, change-order, and pause rules before the portfolio is busy.
Measure per-client costs and outcomes
Portfolio metrics should reveal both shared-system health and client value. Shared measures include workflow success, defect escape, queue age, access findings, incidents, connector failures, and automation coverage. Client measures include freshness, evidence completeness, accepted records, activation results, seller use, qualified outcomes, support, and rework.
Profitability measures include direct contribution by client, labor by service component, gross margin, revenue per analyst hour, setup payback, exception burden, actual support expense, with unused contingency tracked separately usage, and expansion contribution. Do not hide an unprofitable client inside a portfolio average or judge a new client before its setup costs and outcome lag are understood.
A useful renewal record shows what evidence was delivered, how it was used, which actions were accepted, what outcomes matured, what was learned, and what changes are proposed. It should state attribution limits. Intent can help prioritize attention, but it does not guarantee a purchase or prove causation.
Check actual client operating scope
Compare each separately scoped feed, managed action or custom client interface against actual client capability, rights, review work, implementation, support and full costs. A MarketPulse subscription does not establish a reusable wholesale service engine or native multi-client portal.
Immature clients need a narrower pilot, fewer topics, one destination, explicit training, and a simple outcome. Complex enterprise clients may require their own security review, data-processing terms, identity architecture, and ABM orchestration. A portfolio operating model should recognize those tiers instead of forcing one SLA and workflow on every account.
Preserve distinct evidence and action units
Keep account evidence separate from identity evidence. First normalize the company and test fit. Next assess topic or visitor evidence and recency. Only then resolve potential people, verify contact fields, apply suppressions, and determine permitted activation. Store the reason at each transition and never let a downstream contact record erase the uncertainty in the upstream signal.
Outcome reporting should preserve the same chain. Report eligible accounts, released profiles, destination acceptance, seller action, qualified conversations, and pipeline stages as distinct counts. Reconcile them rather than presenting one blended total. This helps the client see whether the constraint is evidence quality, identity, activation, adoption, or sales follow-through.
Hold unresolved access and billing requirements
The highest-severity failures are cross-client exposure, wrong-destination activation, shared credentials, unauthorized export, incomplete deletion, and a misleading client claim. Other material failures include billing the wrong usage, applying another client’s threshold, missing suppressions, or reusing a confidential example.
Controls should include tenant-aware tests, least privilege, separate credentials, access approval, recurring review, output reconciliation, audit logs, scoped support tools, and an offboarding runbook. Contracts should clarify controller and processor roles, instructions, sub-processing, security, retention, deletion, audit support, and incident obligations based on the actual service.
Verify actual source, recipient, purpose, jurisdiction, necessary access, contract responsibilities, correction, retention, deletion, suppression, security and incident ownership. Resolve unanswered requirements before release. Test actual resource and client boundaries rather than assuming a role label or agreement settles every requirement.
Scope current BrandWell capabilities
MarketPulse supplies topic research and available match details. AIMEE can organize supplied context through configured tools. An agency operating service, branded weekly report, CRM synchronization or custom client interface needs separately verified implementation, rights, scope and fees. The research subscription does not establish those delivery capabilities.
Review an available MarketPulse topic, saved ICP and actual preceding-24-hour matches for the approved research purpose. Keep uncertain company context visible. AIMEE can organize supplied context through configured tools; named owners approve actual exports, messages, audience uploads and CRM writes.
MarketPulse supplies topic research and available match details. AIMEE can organize supplied context through configured tools. An agency operating service, branded weekly report, CRM synchronization or custom client interface needs separately verified implementation, rights, scope and fees. The research subscription does not establish those delivery capabilities.
Verify controls before adding clients
- Establish the tenant model: assign immutable client IDs, separate workspaces, roles, credentials, outputs, retention, and offboarding.
- Externalize configuration: move client differences out of code and analyst memory into versioned, approved settings with safe defaults.
- Add portfolio controls: implement capacity, unit economics, access review, QA samples, exception queues, and change impact analysis.
- Automate carefully: automate deterministic, tenant-aware steps; test failure containment; keep human approval where consequence or ambiguity is high.
Scale should make the system more observable. If adding clients makes the team less able to explain access, cost, quality, or outcomes, pause growth long enough to repair the control plane. Recurring revenue is not durable when the agency cannot prove whose data moved where or why.
Frequently asked portfolio questions
How many clients can one operations team manage?
There is no universal number. Capacity depends on topic volume, source complexity, review rate, destinations, reporting, meetings, exceptions, and automation maturity. Model the constrained work by client and test peak conditions.
Should every client get a separate platform instance?
The required boundary is secure and testable tenant isolation, not necessarily separate physical infrastructure. Choose architecture based on data sensitivity, contractual requirements, platform design, and verified controls.
What should never be shared across clients?
Do not share records, credentials, destinations, detailed configuration, suppressions, exports, confidential examples, or identifiable performance evidence without explicit authority. Shared templates must be stripped of client data.
Which portfolio metric matters most?
Use a balanced view. Contribution margin without quality can conceal risk; quality without adoption can conceal low value. Combine client outcomes, defect and incident measures, time-to-value, support burden, and contribution.
Copyable client-scoped operating record
Client: [Actual immutable identifier and program.] Scope: [Records, configuration, destinations and period.] Evidence: [Source, uncertainty and version.] Access: [Actual user, credential and permitted resource.] Ownership: [Approver, destination acknowledgement and incident owner.] Economics: [Actual usage, billing, shared allocation and missing inputs.] Decision rule: [Client-specific quality, offboarding and pause criteria.]
Authentication does not establish tenant isolation
AWS’s tenant-isolation guidance distinguishes authentication and authorization from tenant isolation. Its architecture guidance is not a certification of BrandWell or an agency implementation. Verify the actual resource paths, client context and boundaries in the systems you use.
If Client A and Client B both have a record numbered 42, a shared lookup using only 42 can resolve the wrong object. Preserve the actual scoped identifiers and tested authorization at the resource, export, report and destination boundaries. A client name printed on the screen does not establish isolation.
A critical cross-client failure must not be averaged away
In a fictional test set, 99 cases pass but one exports another client’s records. A 99% pass rate does not authorize that release. Contain the affected path, preserve evidence, identify the owner and verify the corrected behavior before closure.
Portfolio contribution can hide a losing client
A fictional Client A pays $2,000 with $800 direct costs; B pays $1,000 with $1,000 direct costs. Shared costs are $600, allocated $400 to A and $200 to B using a stated driver. A’s defined remainder is $800, or 40%; B loses $200. Portfolio remainder is $600 on $3,000, or 20%, but that average does not make B profitable.
An equal $300 allocation changes the client remainders to $900 and negative $300 without changing the $600 portfolio remainder. Review both the allocation and actual workload; a different accounting split does not repair delivery cost.
Retried attempts are not automatically billable unique outputs
A fictional job attempts 100 records: 70 accepted, 20 rejected and 10 with no response. Fifteen retries make 115 attempts, not 115 unique accepted outputs. Reconcile actual destination states, duplicate handling and the written billing unit before invoicing. Unknown responses are not success.
Capacity needs client-specific work and skills
Five fictional clients require two routine hours and one specialist hour each: 10 routine and five specialist hours. Twelve routine and four specialist hours provide 16 total hours, but leave a one-hour specialist gap against 15 required. Verify actual roles, timing, peaks and exceptions instead of dividing headcount by a client count.
Offboarding includes more than removing a login
Record actual credentials, jobs, exports, reports, support copies, recipients, retained records and backups in the approved offboarding scope. Verify revocation and documented retention or deletion behavior. Do not claim deletion from every copy unless the actual implementation and evidence support it.
Use current products within verified rights
MarketPulse research starts at $500/mo. Review actual topic matches, saved ICP filters and allowed use for each client. TrafficID is separate own-site visitor work. AIMEE can organize supplied context through configured tools; owners approve exports, messages, audience uploads and CRM writes. Custom multi-client interfaces and delivery require separately verified rights and implementation. The invented service costs above are not BrandWell prices or typical performance; general overhead, tax and financing are excluded.
Review current research: explore MarketPulse and current plans.
Reviewed and updated October 3, 2026.


Farnaz Kia