Most CRM decisions do not need millisecond execution. Invest in real-time AI only when a reliable signal loses value before the next processing run, an action can be completed inside that window, and the likely incremental benefit exceeds integration, availability, and control costs. If the decision can wait several hours or a day without changing the outcome, batch is usually cheaper, easier to explain, and easier to operate.
The mistake is buying speed as a platform feature before measuring the value of latency. An event can arrive instantly and still trigger the wrong action because identity is unresolved, inventory is stale, another journey already contacted the customer, or a human team will not respond until tomorrow. Real time is an end-to-end property: signal, decision, authorization, action, and outcome capture must fit the same window.
Define the Latency Value Contract
- Decision — the choice that changes: send, wait, suppress, route, prioritize, or request review.
- Window — time between the signal and the last useful action.
- Decay — economic value lost as each hour passes.
- State — data that must be current to avoid an invalid action.
- Eligibility — permission, frequency, inventory, price, channel, risk, and journey conflict.
- Action — what a system or person can actually execute inside the window.
- Fallback — safe behavior when the event, identity, model, or destination fails.
- Outcome — incremental revenue, margin, retention, or resolution with a comparator.
- Cost — ingestion, processing, availability, support, observability, and human review.
- Owner — accountability for the signal, decision, action, and incident.
The governing rule is simple: technology should not be faster than the operation receiving its decision. If sales reviews alerts once a day, recalculating a score every second does not shorten response. If price and inventory refresh in batch, an instant recommendation can be wrong. The contract surfaces those boundaries before a midsize company buys permanent infrastructure.
Choose batch, on demand, streaming, or edge
- Daily or intraday batch — appropriate for account expansion, early churn, portfolio planning, and journeys without steep hourly decay.
- On demand — recalculates when a customer or operator opens a surface, avoiding continuous processing for sporadic decisions.
- Streaming — useful when a recent event changes eligibility or priority and automation can act within minutes.
- Edge — reserved for same-page or next-page decisions with limited data, hard rules, and immediate fallback.
- Hybrid — keeps profile, value, and policy in batch while recent events adjust a narrow decision.
Adobe documents batch, streaming, and edge as distinct audience-evaluation methods. The executive question is not which method sounds most advanced; it is whether the use-case window matches the evaluation mode. Salesforce likewise documents a customer-data platform that handles both streaming and batch data. Capability creates options. It does not prove that saving another hour changes customer behavior or economics.
Example: a high-value checkout that needs service, not another coupon
Consider a U.S. retailer that receives a high-value checkout event and detects abandonment. Within minutes, delivery, installation, financing, or product-fit assistance may still matter. The action is valid only if the person is recognized, the channel is permitted, inventory and price are current, and no service case or competing journey makes outreach inappropriate. The decision can route help, preserve the cart, show approved guidance, wait, or suppress contact.
Compare that with B2B account expansion. Product use, tickets, renewal timing, and commercial potential may be refreshed nightly or weekly because the account owner cannot act in seconds. Turning that workflow into streaming adds cost without changing execution. The test must show that faster decisioning changes behavior or outcome—not merely that a dashboard refreshes more often.
Prove the need in six weeks
- Week 1 — select one decision, one cohort, and one economic outcome.
- Week 2 — measure the actual signal-to-decision-to-action-to-outcome timeline.
- Week 3 — write the contract, eligibility, exclusions, fallback, and latency budget.
- Week 4 — replay historical events through batch, on-demand, and streaming simulations in shadow mode.
- Week 5 — release one low-risk action inside a limited window while preserving a comparator.
- Week 6 — compare incremental value, error, cost, incidents, and operating load; simplify, expand, or stop.
The pilot does not require a new platform on day one. Use CRM, analytics, messaging, and service logs to reconstruct the timeline. Estimate what would have happened if the decision arrived after 5 minutes, 1 hour, 6 hours, or 24 hours. Then connect only the sources and destinations needed to test the range where value actually changes.
Calculate cost per useful decision, not events per second
Cost rises with streaming sources, real-time identity, volume spikes, low latency, 24/7 availability, multiple destinations, deduplication, consent state, observability, replay, support, and human review. Measure cost per eligible decision executed and per incremental outcome. An architecture that processes millions of events to produce a handful of useful actions can have worse unit economics than a well-designed daily batch.
- Value — incremental gross margin or revenue per executed action.
- Speed — median and tail time from signal to action, not model latency alone.
- Quality — eligibility, duplicates, stale state, false positives, and no-action rate.
- Reliability — event loss, delay, downtime, replay, and fallback use.
- Experience — contact pressure, opt-outs, channel conflicts, and resolution.
- Operations — accepted alerts, human capacity, exceptions, and support hours.
- Economics — total cost per useful decision and incremental outcome.
Assign responsibility for a decision that cannot wait
Marketing defines the window and treatment; CRM governs contact pressure and journey conflict; data owns event quality, identity, and current state; engineering owns integration, availability, and replay; analytics designs the comparator; service or sales confirms capacity; finance validates contribution; legal and privacy review permitted use; the sponsor chooses acceptable downtime. NIST's Generative AI Profile reinforces measurement, evaluation, and ongoing risk management across the lifecycle.
Start with the decision, not the stream
Use the minimum data loop at https://makinai.co/insights/en/cdp-ai-marketing-minimum-customer-data-loop-revenue, next-best action at https://makinai.co/insights/en/ai-next-best-action-crm-personalization, journey QA at https://makinai.co/insights/en/ai-test-broken-crm-customer-journeys, and account expansion at https://makinai.co/insights/en/ai-customer-expansion-account-revenue-loop-b2b. MAKINAI implements CRM, data, and commerce at https://makinai.co/services/en/crm-ecommerce-commerce-transformation. Bring one signal, the current action, and the point at which its value expires; we can test whether real time pays for the integration.
Real time cannot repair an undefined event, ambiguous identity, or action without an owner. Platform metrics do not prove incremental impact, and six weeks is a scope frame rather than a guarantee. Privacy, communication, and automated-decision requirements vary by state, country, industry, and use case; review them before scaling.