Keep every customer updated, across SMS and RCS.
The Update Layer sends from what actually happened, not from a schedule. A booking moves, an order ships, a payment clears: the event triggers the message, uses a rich RCS card where the recipient can receive one, falls back to SMS where they cannot, and returns delivery state and any customer action to the journey that raised it.
- 01 EVENT A booking, order or service event occurs in a connected system.
- 02 ELIGIBILITY Preference, consent and channel eligibility are checked.
- 03 RCS A rich RCS update is composed where supported.
- 04 FALLBACK SMS fallback is used where RCS is unavailable or unsuitable.
- 05 DELIVERY Delivery and customer action return to the workflow.
- 06 ESCALATION Exceptions escalate to another channel or a person.
Updates fail when they are disconnected from the actual journey
A notification that fires from a batch job cannot know the delivery slipped an hour ago. Customers get a confirmation for something that changed, no message when it mattered, and no way to respond to either. The message was delivered; the customer still called to ask what was happening.
What the SMS and RCS Update Layer can do
Eight functional capabilities, described in business language. Scope for any individual environment is confirmed during discovery.
Event-triggered updates
Send selected messages from real changes in booking, order, payment, service or delivery state.
Transactional SMS
Deliver concise alerts and reminders through approved routes, templates and consent models.
RCS rich experiences
Use supported cards, media, buttons or suggested replies subject to carrier, provider and sender approval.
Automatic fallback
Define an SMS fallback path when RCS is unavailable or unsuitable for the recipient.
Template and preference control
Govern content, language, timing, consent and communication preferences.
Delivery and action visibility
Capture delivery state and supported customer actions back into the journey.
Cross-channel escalation
Move an unresolved or high-value interaction to WhatsApp, Voice, Web or a person where configured.
Workflow and API integration
Connect message events to operational systems, queues, data streams and APIs.
From conversation to governed enterprise action
The channel is the surface. Underneath, every product runs the same path, and the same controls apply whichever channel the customer used.
- 01Channel inputSms + Rcs Update Layer
- 02iVaak context & knowledgeIdentity, history, approved sources
- 03Workflow & guardrailsPermitted actions, limits, policy
- 04Enterprise systemCRM, ERP, support, bookings, APIs
- 05Response or handoverAnswer, action or a person with context
High-value transactional update journeys
Representative rather than exhaustive, and not preconfigured for every enterprise. Each is scoped and validated against your own systems during discovery.
Escalate an update into a real conversation
When a customer replies to a delay notice with a question the message cannot answer, a configured escalation moves them to WhatsApp, Voice or a person while retaining the relevant journey context: the order, the event that triggered the message and what they were told.
Meta AI and automationConnect SMS + RCS to the systems you already run
iVaak is a conversational layer over the systems you already operate, not a replacement for them. Every integration is subject to discovery and technical validation; existing connectors and possible API integrations are not the same thing.
Govern every answer and action
Grounding, permissions, escalation, audit and retention are visible parts of the product. Certifications are published only once confirmed by the responsible owner.
Approved knowledge
Responses are grounded in sources you have approved, and unsupported questions route to a person rather than being answered anyway.
Permissions
Every action the conversation can take is permissioned, scoped and capped by rules you define, not by what the model decides to attempt.
Human escalation
Journeys escalate on request, or when confidence, policy or risk conditions require it, with a summary and the available context.
Auditability
Questions, answers and actions are recorded so a conversation can be reconstructed and reviewed after the fact.
Retention controls
Retention, residency and deletion behaviour are configured per deployment and per contract rather than assumed. [VALIDATE]
Deployment choices
Dedicated, white-labelled or on-premise models are evaluated where currently supported and validated. [VALIDATE]
RCS availability, verified sender features and rich capabilities depend on device, geography, carrier, provider and approval. Universal reach or delivery is not promised, which is why a designed SMS fallback is part of every journey.
Deploy around one measurable journey
Start with a single bounded journey you can measure, rather than the whole channel at once. No fixed delivery period is promised; the schedule follows the scope and the systems involved.
- 01DiscoveryJourney, systems, owners and success measure
- 02Workflow mappingIntents, actions, limits and escalation rules
- 03Integration validationAPIs, permissions and data access confirmed
- 04TestReal examples, guardrails and failure paths
- 05Bounded pilotLive on one journey, measured against the baseline
- 06Outcome reviewWhat to extend, what to change, what to stop
Update Layer frequently asked questions
Answers for buyers, operations leaders and technical evaluators. Where scope depends on your environment, that is stated rather than assumed.
What is the SMS and RCS Update Layer?
It is the event-driven messaging part of the iVaak suite, designed for customer alerts, reminders, status changes and structured next actions.
Will every customer receive an RCS message?
No. Availability depends on device, geography, carrier, provider, sender approval and other factors. A designed SMS fallback is essential.
Can it trigger messages from our business systems?
Yes, where the event source exposes suitable APIs, events or integration points.
Can customers reply or take action?
Supported RCS experiences may include suggested actions. SMS response options depend on the configured route and programme.
How are consent and preferences managed?
They are enforced through the applicable regulatory, provider and enterprise rules. No universal compliance model is claimed. [VALIDATE]
Can an update become a WhatsApp or Voice conversation?
Yes. A configured escalation can move the customer to another supported channel while retaining the relevant journey context.
Put SMS + RCS on one real journey.
Trigger reliable transactional updates from real business events, use richer RCS experiences where available and retain an SMS fallback path where they are not.