Where every customer conversation lives.
The mobile-native engagement platform that unifies contact center, outbound journeys, video banking, and in-app messaging — so every service moment is answered, every campaign lands inside the trusted channel, and nothing ever slips into an unattributable thread.
Voice, chat, email, in-app messages — routed through one queue, handled at one agent desk, logged against one customer profile. No channel-hopping, no context loss.
Trigger-based customer journeys, scheduled campaigns, and transactional notifications — delivered inside the host app so the trusted channel stays the channel.
Live video with the agent who's free right now — for onboarding KYC, wealth advisory, tellerless branch, and high-value transaction verification.
AI-assisted response drafting, intent detection, and real-time knowledge retrieval — keeping the human agent in the loop, keeping the copilot inside your trust boundary.
Banks whose call volumes rise faster than agent capacity, whose customers increasingly prefer chat, and whose regulators increasingly demand auditable resolution.
Institutions that need OJK-compliant video KYC for account opening, card issuance, and priority-client onboarding — without building a video stack from scratch.
Priority and wealth segments where every customer message must feel personal, relevant, and timely — and where one generic blast destroys the relationship.
The unified desk for every inbound service moment and every outbound journey.
Customer engagement and contact-center platforms — category references for context. Most products in this category are SaaS-first and hosted outside Indonesia.
Built for the app first, the web second. Customer data stays where the regulator expects it to stay.
On the quiet disappearance of the institution from its own customer conversation — and what a return looks like.
For most of the history of modern banking, a bank's conversation with its customer began at the counter.
The customer walked in, a teller recognised them, a passbook was stamped, a transaction was noted, a signature was witnessed. If something was promised, it was promised across a wooden counter with a letterhead behind it. If something went wrong, a complaint was made on a numbered form. The record of the conversation — the promise, the complaint, the resolution — lived in the institution's own ledger, under the institution's own roof.
Today, most of the conversations that matter between a bank and its customer happen somewhere else entirely. On a mobile number the bank does not own, in a messaging application the bank does not control, through a call that may or may not have come from the bank's own contact centre. The customer does not know which of these are the institution's voice, and the institution, increasingly, does not know either.
This note is an argument about the return of the conversation to the place it belongs.
Consider, for a moment, the ordinary life of a customer in Jakarta over the course of an ordinary week. On Tuesday a message arrives on WhatsApp from a number she does not recognise, bearing her bank's logo as its display picture, informing her that her card has been used for an unusual transaction and inviting her to confirm or deny it by tapping a link. On Friday her phone rings. The caller identifies himself as an officer of the same bank's fraud team, calling from an ordinary GSM line, asking her to verify the transaction by reading a six-digit code that has just been sent to her by SMS. Each communication is plausible. Neither is distinguishable, with certainty, from the bank's real voice.
She has no principled basis to distinguish which of these communications is real. The authority that was once concentrated in the bank's teller counter, letterhead, switchboard, and seal has, over the course of two decades of digital expansion, dispersed across an ecosystem of channels the bank does not own, cannot authenticate, and in most cases cannot audit. The bank has spent a great deal of money to be present wherever the customer is — and in doing so, has quietly ceased to be the reliable author of its own conversations.
The bank has spent a great deal of money to be present wherever the customer is — and in doing so, has quietly ceased to be the reliable author of its own conversations.
This is not a failure of any particular technology. The contact-centre platform works. The campaign-engagement platform works. The communications-as-a-service provider delivers its messages. The video-KYC vendor captures its enrolments. Each system is doing precisely what its vendor sold it to do. The failure is one of composition. No single system was designed to produce a coherent account of the customer. Coherence, in the current architecture, is the institution's problem — and increasingly, it is an unsolved one.
The customer's experience of this fragmentation is, at best, confusion. At worst, it is the opening through which fraud walks. When the institution cannot itself say with authority which channels are genuinely its own, it cannot reasonably expect the customer to tell the difference. Impersonation has become trivially cheap; spoofed WhatsApp business profiles are purchased in bulk, contact-centre scripts are rehearsed with a plausibility that approaches the institution's own, and the customer bears the final cost when an instruction is followed that ought never to have been given.
The institution that wrote cheques, sent statements, and answered complaints under its own name has — without any single decision to do so — handed the running of its most important customer conversations to infrastructure it does not own. Most boards have not yet named this as a strategic problem. Supervisors have already begun to.
Fragmentation is not, in itself, an aesthetic problem. If the costs were purely aesthetic, no board would need to read this note. The costs are structural. They are visible in the regulatory evidence the institution cannot produce, in the fraud it cannot pre-empt, in the customer insight it cannot recover, and in the operational tax it pays every year to maintain the seams between systems that were never designed to meet. It is to those costs that the next chapter turns.
The honest measure of an institution's communications architecture is not whether it works on an ordinary day. It is whether the institution can answer, on demand, the questions a supervisor will one day ask. What did we say to this customer, and when? What consent did she give, on which channel, and what precisely was she told she was consenting to? When the dispute was raised, what was our reply, how promptly, and through which officer? These are not exotic questions. They are becoming the standard vocabulary of consumer protection supervision in every jurisdiction that matters to Indonesian banking.
What would we actually be able to produce — in days, not in weeks — the first time a supervisor asks us for the complete communication trail of a single disputed transaction?
For most institutions, the honest answer is: not much. The complaint lives in the case-management system. The first alerting text message lives in the aggregator's billing log. The customer's acknowledgement lives in a WhatsApp thread on a relationship manager's personal device. The remediation call lives in the contact centre's voice recording — if it was recorded at all, which depends on which contact centre, which agent, and which shift. The disclosure sent in the app lives in the engagement platform's event archive. Stitching these together into a single coherent record — one that survives contact with a regulator's question — is typically several days of manual reconstruction, and almost always incomplete. The institution does not have the conversation. The institution has six partial shadows of the conversation, each retained under a different policy, in a different format, on a different vendor's infrastructure.
This is no longer a hypothetical problem. Since 2021, off-channel communications enforcement in the United States — personal-device messaging by bankers, brokers, and swap dealers, outside the firm's archival systems — has produced the largest sustained wave of record-keeping penalties in decades, affecting most of the world's largest financial institutions. The pattern moved quickly from firm-level settlements to personal supervisory accountability at major broker-dealers. In the United Kingdom, the Financial Conduct Authority has issued supervisory correspondence on off-channel communications and signalled that enforcement is a forward priority; major firms are already restructuring their archival posture in anticipation. Indonesia is not yet at that point, but the legal infrastructure is now in place: OJK Regulation 22 of 2023 on consumer protection establishes consent, retention, and handling obligations that a WhatsApp group on a relationship manager's personal phone cannot satisfy; the Personal Data Protection Law of 2022 establishes data subject rights — to know, to access, to correct, to erase — that will require institutions to maintain complete and retrievable communication records as implementation regulations mature.
The institution does not have the conversation. It has six partial shadows of the conversation — each under a different policy, in a different format, on a different vendor's infrastructure.
The second cost is fraud. Every channel the institution does not control is a channel the impersonator can occupy with equal credibility. When the institution's real contact centre calls from an ordinary GSM line, so does the fraudster. When the bank runs a promotional campaign on Instagram, so does the scam account. When a recovery team messages a customer on WhatsApp, so does the social engineer. The customer, faced with no principled way to verify authenticity, learns a rational distrust — a distrust the institution itself has no practical means to disarm. Fraud is the most visible cost of fragmentation. It is not the largest.
The third cost is the slow haemorrhage of learning. An institution that can observe only a part of its customer conversation can learn only a part of what the customer is trying to tell it. The contact-centre reporting system sees call outcomes but not the mobile journey that preceded them. The engagement platform sees click-through rates but not the complaints that followed. The survey tool knows the customer was dissatisfied but cannot recover the specific agent, the specific channel, the specific moment that produced the dissatisfaction. Over time, the institution accumulates enormous activity data and startlingly little actionable insight. The activity lives; the meaning escapes.
The fourth cost is the ordinary one of money. Five categories — inbound contact centre, outbound engagement, communications delivery, customer surveys, video-KYC — mean five vendors, five contracts, five integrations, five support escalation paths, five security reviews, five renewal negotiations, and in most institutions, five separate teams of people whose principal work is maintaining the seams. This is a standing operational tax, and in most institutions it grows, not shrinks, over time.
Taken together, these costs are what fragmentation means as a strategic matter. They are the reason a note of this kind is worth a director's time. The ordinary next question — what to do about it — is the subject of the third and fourth chapters.
The following is a single case. The customer is a long-standing retail account holder of a mid-tier Indonesian bank. At 14:02 on a Tuesday, she receives a notification that a transaction of IDR 12,400,000 has just been authorised on her card at a merchant in another country she has never visited. The transaction is not hers. She has ten minutes, perhaps fifteen, before the window for recall closes. What happens next depends entirely on the architecture her bank operates underneath the moment of her alarm.
The case is ordinary. The two timelines — fragmented and unified — are not invented; they are composites of how institutions in each architecture ordinarily perform.
| ARCHITECTURE A The fragmented timeline | |
| 14:02 | Alert delivered as SMS via aggregator. No read receipt is available to the bank. |
| 14:05 | Customer opens SMS, reads it, panics, calls the number printed on the back of her card — which routes to the main IVR. |
| 14:09 | Hold queue. Eight minutes of music. The IVR does not know a fraud alert was just sent. |
| 14:17 | Agent picks up. Re-authenticates the customer through the bank's standard contact-centre process. Customer explains from scratch; the agent has no visibility into the alert that triggered the call. |
| 14:22 | Agent initiates card block. By the time the block propagates, the disputed transaction window has closed and the transaction has settled; recovery will now run through chargeback. |
| 14:30 | A parallel number — spoofed, claiming to be the bank's fraud team — calls the customer to "verify". She hangs up, but her trust in her actual bank has declined. |
| Day 2 | Complaint raised through a different system. No link to yesterday's call. |
| Day 14 | Regulator forwards the customer's complaint. Compliance begins manual reconstruction across four systems. |
| Day 28 | Response to regulator is filed — incomplete. Missing: read receipt on the original alert, agent call recording, device context at the moment of alert. |
| Fraud partially recovered. Customer retained but damaged. Regulator unsatisfied. Complaint file carries forward. |
| ARCHITECTURE B The unified timeline | |
| 14:02 | Alert delivered as a signed in-app notification — the payload is signed by the bank and verified inside the authenticated app on receipt. A read receipt is emitted the moment the app renders the alert. |
| 14:03 | Customer taps "This was not me". A single button. Authorisation block is executed within seconds; card network propagation follows immediately. |
| 14:03 | In-app message appears: "We have blocked the card. A fraud specialist is available now — tap to speak." She taps. |
| 14:04 | Voice call opens inside the app. Agent already sees: her identity, her journey, the alert she just acted on, her device posture, her last three interactions. |
| 14:07 | Agent captures her statement. Draft dispute form, pre-filled, presented in-app. She signs with biometric. |
| 14:09 | Entire conversation — alert, action, call, signature, dispute — stored as a single correlated record in the unified telemetry. |
| 14:11 | Post-resolution survey fires in-app. She rates the experience. Rating is bound to the same conversation ID. |
| Day 2 | Provisional credit restored pending chargeback resolution. Automatic in-app confirmation. Conversation record extended with the provisional-credit event. |
| Day 14 | Regulator request received. Complete record exported in one click — alert, action, call, signature, resolution, survey. |
| Fraud prevented before settlement. Customer impressed and trust strengthened. Regulator receives a complete, defensible record. |
What the two timelines reveal is not a difference in how hard the institution's people work. The people in Architecture A work considerably harder. The difference is in what the architecture itself does on their behalf. In the fragmented architecture, the institution's people are asked to bridge, by hand, gaps that no one person can bridge in real time. In the unified architecture, the gaps do not exist; the conversation is a single object from start to finish, and every capability of the institution composes against it.
The difference between the timelines is not how hard the institution's people work. It is what the architecture itself does on their behalf.
A director reading this note should take from it a simple structural observation. The institution is currently absorbing the full cost of Architecture A — in regulatory exposure, in fraud losses, in customer trust, in operational overhead, in the annual renewal of five separate vendor contracts. The question of whether to move to Architecture B is not a question about a new product. It is a question about whether to continue absorbing that cost indefinitely.
The mistake of the past two decades has been to treat the customer's channel as a centrifugal problem. If the customer is on WhatsApp, build a WhatsApp capability. If the customer is on SMS, rent a short code. If the customer is on Instagram, appoint a social-media team. The institution chases the customer across an expanding list of external channels, fortifies each piecemeal, and in the process steadily erodes its own ability to speak with one voice. The logic feels natural in the moment; it produces, over time, an institution that has lost the coordinates of its own customer conversation.
The counter-proposition is simple. The institution already owns one channel the customer opens every day, has already authenticated, already trusts, and already has on the home screen: the institution's own mobile application. That channel inherits every guarantee the institution has already built — identity, device posture, policy, telemetry, audit. It has the customer's full attention, no impersonator can enter it, and its evidence is, by construction, complete. The strategic shift is not technological. It is a decision about where the conversation belongs. The conversation belongs where the institution can hold itself accountable for it — and the only place the institution can fully hold itself accountable is inside the application it owns.
Stop chasing the customer across channels the institution does not own. Instead, pull the conversation home, into the one channel that inherits the institution's own trust — the application on the customer's phone. This is not a product decision. It is a decision about where the institution is willing to take responsibility for its own voice.
This shift is not new. It is the same shift that the teller counter and the letterhead together represented a generation ago, in a different medium. The branch and the letterhead were never chosen because they were the most convenient channels for the customer; they were chosen because they were the channels over which the institution could stand behind its own word. The mobile application, for a modern regulated institution, is what the branch counter and the letterhead together represented then — the channel over which the institution can hold itself to its own standard. What has been missing is an engagement architecture that treats it that way: one that consolidates contact centre, outbound engagement, surveys, video service, and AI copilot into a single fabric operating inside the application, under the institution's own identity, policy, and audit.
This is the work Nexilis Reach exists to do. It is not a contact-centre product with a mobile add-on. It is not an engagement platform that ships notifications to a device. It is an engagement fabric whose premise is that the customer conversation belongs inside the application, and whose architecture is the consequence of taking that premise seriously. The product brief that accompanies this note describes the architecture in detail. This note is the argument for why that architecture is worth the board's attention in the first place.
There is one additional consideration a board ought to weigh in the Indonesian context. Reach is built by an Indonesian company, under Indonesian law, hosted in Indonesia, engineered in Indonesia. For an institution subject to data-sovereignty obligations, domestic-content expectations, and the supervisory reach of Bank Indonesia and the Financial Services Authority, this is not an incidental property. It is the property that makes the architecture defensible in every conversation the institution will have with its regulator over the next decade. No foreign-headquartered incumbent can match it without material rework; the institutions most committed to their own sovereignty will find this the most consequential consideration of all.
The mobile application is, for a modern regulated institution, what the branch counter and the letterhead together represented a generation ago — the channel over which the institution can stand behind its own word.
The decision this note invites is not to buy anything. It is a decision to examine whether the current architecture — five vendors, five categories, six partial shadows of every conversation — is still the architecture the institution wants to run for the next decade. An honest examination, for most institutions, produces a single answer. The conversation has left the building. It is time to invite it home.
An institution that has read this note and found it recognisable is the right institution for a short strategic conversation — not a product demonstration, not a vendor pitch, but a structured discussion about the institution's current engagement architecture and what it is costing. The conversation can begin at whatever altitude fits the institution's situation: a thirty-minute framing discussion with a single executive sponsor; a ninety-minute strategic session with CEO, CX leadership, compliance, and digital operations in the same room; or, where the architecture question has already been recognised internally, a direct technical evaluation.
If, at the end of that conversation, a technical evaluation is the appropriate next step, the product brief is the document for the evaluation. If it is not, the conversation will still have been worth having. It is rarely wasted time to examine the architecture of the customer conversation — whatever the eventual decision.
PT Easysoft Indonesia
Jakarta, Indonesia · nexilis.io
nexilis.support@nexilis.io
This note and the architectural claims it contains are the confidential property of PT Easysoft Indonesia. Distribution to parties outside the receiving institution requires written authorisation. The accompanying Product Brief provides the technical reference for institutional evaluation teams. Detailed regulatory control mappings and implementation references are available under mutual non-disclosure.
The mobile-native customer engagement platform that unifies contact centre, outbound journeys, surveys, and video service inside the one channel the institution already owns — its own application.
Reach brings the contact centre, the campaign orchestrator, the survey tool, the video KYC booth, and the AI copilot into a single capability — one that lives inside the same application the customer has already authenticated, already trusted, and already opened.
Nexilis Reach is a customer engagement platform built for regulated institutions whose mobile application is their most important channel. It is not a contact-centre product with a mobile add-on, nor an engagement platform that ships notifications to the device. It is an engagement fabric that operates inside the institution's own application, inheriting the identity, device posture, and audit guarantees that application has already put in place.
Reach consolidates five categories that most institutions currently buy from five different vendors: inbound contact centre, outbound engagement and campaigns, customer surveys and in-moment feedback, video service and video KYC, and AI-assisted agent tooling. Each of these has a mature global category leader. Reach does not try to beat each leader on their strongest feature. It tries to beat the fragmentation that buying five different leaders inevitably produces.
What Reach is, in one paragraph
An embedded engagement platform that replaces the institution's patchwork of CPaaS, CCaaS, CEP, survey, and video providers with a single fabric — designed to run inside the mobile application the institution already ships, under the institution's own identity, telemetry, and consent model. Every customer conversation, whether initiated by the institution or by the customer, ends up in one evidence-grade record.
Who Reach is for
Retail and digital banks whose customers have already installed the mobile application and whose regulators now require auditable communications for critical journeys.
Insurance, multifinance, and wealth managers where the relationship manager–client conversation is itself a franchise asset and currently runs on WhatsApp.
Public service institutions (social security, tax, public utilities) whose constituent conversations must remain on sovereign-hosted infrastructure.
Regulated enterprises where off-channel communications have already drawn supervisory attention and where a single audit story is worth the migration cost.
The customer conversation that matters most belongs inside the application the institution already owns — not on SMS, not on WhatsApp, not on a contact-centre desktop the customer never sees, and not on an impersonator's spoofed number. Every category Reach occupies has come to run, for one reason or another, outside the institution's trust perimeter — some because they drifted there, some because they were born there.
What Reach is not
Reach is not a customer relationship management system, a core banking platform, a fraud detection engine, a payment gateway, a loan origination platform, or a mobile application development framework. It integrates with each of these and derives value from being adjacent to them. It does not replace them.
The sovereignty posture
Reach is built by an Indonesian company, under Indonesian law, hosted in Indonesia, engineered in Indonesia. Customer data does not leave the country unless the institution explicitly configures an exception. For institutions subject to PADG 24/2022, POJK digital-banking obligations, and UU 27/2022, this is not a feature; it is a structural fit that no foreign-headquartered incumbent in the competitive landscape can match without material architectural rework. For BUMN and government-owned institutions, the domestic-content (TKDN) posture is explicit and documented.
What consolidation to one fabric does — and does not — imply
Reach replaces five vendor relationships with one. The obvious concern is concentration: one vendor, one failure domain, one lock-in. Reach's architecture is designed to keep this concern answerable. Every event, consent record, conversation transcript, and journey definition is streamed in real time to the institution's own data lake in standard formats. Reach can be migrated off the same way it is migrated on — progressively, journey by journey. The institution owns its data at all times, and the coexistence integration model means Reach never takes a dependency the institution cannot unwind.
The customer conversation has dispersed. Reach is a response to what that dispersal costs.
The critical conversations between a bank and its customer — fraud rescue, consent capture, dispute resolution, complaint handling, advisory guidance, marketing promises — no longer travel on any single channel the bank fully controls. They run across WhatsApp groups hosted by relationship managers, SMS short codes rented from aggregators, outbound voice campaigns dialled from untraceable GSM lines, Instagram direct messages that impersonate the institution with alarming fidelity, and a contact-centre desktop whose view of the customer begins only when the call connects. No single party sees the complete conversation.
Five costs of fragmentation
Regulatory exposure
Since 2021, off-channel communications enforcement in the United States has produced the largest sustained wave of record-keeping penalties in decades, affecting most of the world's largest financial institutions — investment banks, broker-dealers, and swap dealers. In the United Kingdom, the Financial Conduct Authority has issued supervisory correspondence on off-channel communications and signalled that enforcement is a forward priority; major firms are already restructuring their archival posture in anticipation. Indonesia's POJK 22/2023 on consumer protection and the Personal Data Protection Law (UU 27/2022) set the direction locally — consent must be captured, communications retained, complaints auditable. A WhatsApp thread on a relationship manager's personal phone is none of these.
Fraud and impersonation
When the institution's real contact centre calls from an ordinary GSM number, so do the fraudsters. When the bank markets promotions on Instagram, so do the scam accounts. The customer has no principled basis to distinguish authentic channels from counterfeit ones. The institution has handed this verification burden to the customer — and the customer, understandably, fails it.
Evidence fragmentation
A typical complaint touches the mobile app, the contact centre desktop, an SMS, a call log, and at least one internal email thread. No system stitches these together. When the regulator asks the institution to produce the full communication trail for a single dispute, the answer is typically several days of manual reconstruction — and often an incomplete record.
Learning loss
Every external conversation the institution cannot observe is a lesson the institution cannot learn. The contact centre sees call outcomes but not the app journey that preceded them. The CEP sees campaign clicks but not the service complaint that followed. The institution accumulates the activity but loses the insight.
Vendor sprawl
Five categories, five vendors, five contracts, five integrations, five support teams, five renewal cycles, five security reviews. The institution ends up paying a premium for the privilege of maintaining the seams between systems that were never designed to work together.
A conversation that lives outside the application is a conversation the institution cannot audit, protect, learn from, or prove.
Why fragmentation is becoming a compliance problem, not just an operational one
In the United States, off-channel communications enforcement has moved from firm-level settlements to individual accountability — supervisors and relationship managers at major broker-dealers have been personally fined. The same pattern has historically preceded equivalent enforcement in other jurisdictions. POJK 22/2023, POJK 6/2022, POJK 11/2022, and the PDP Law give Indonesian supervisors the tools to act when a similar enforcement priority emerges locally.
Reach is structured as a stack of capabilities, not a collection of products. Each layer operates under the same identity, policy, and telemetry model.
Reach's architecture is deliberately layered. A layered architecture is slower to build than a federated one, but it produces something a federated architecture cannot: a single customer conversation that is coherent across every capability the institution deploys. The seven layers below can be adopted progressively — Foundation tier begins with layers 1 through 3; Enterprise tier runs all seven.
Why layered, not federated
A federated architecture — separate best-of-breed products for each capability — is faster to deploy and often cheaper at year one. It produces, as a byproduct, the fragmentation Reach exists to solve. The layered architecture trades initial simplicity for long-term coherence: the same identity, the same policy, the same telemetry across every capability. By year three, the federated institution is paying its vendors to maintain the seams. The layered institution has no seams to maintain.
Resilience, tenancy, and revocation
A platform embedded in a regulated mobile application must answer, before evaluation begins, three operational questions that evaluators routinely press on. Reach's answers are as follows.
Failure posture. Reach is designed to fail to a safe local mode. If the Reach control plane is unreachable, the host app does not block the customer journey; it degrades to a cached-policy path with a signed timestamp, re-syncs when connectivity returns, and preserves a complete record of the offline interval. For journeys where fail-closed is preferred (high-value authorisation, consent capture), the institution configures this explicitly per journey.
Tenancy and isolation. In Nexilis-managed SaaS deployments, tenants are logically isolated at database and schema level, with per-tenant encryption keys; bring-your-own-key (BYOK) is supported via institution-controlled KMS. In private single-tenant and on-premises deployments, isolation is absolute. Tenant-boundary audit evidence is produced on demand.
Revocation and kill-switch. A compromised agent session, tenant connection, or app installation can be revoked from the administrator console; revocation propagates to all sessions within seconds and is logged as a first-class event. The institution retains the revocation authority.
Disaster recovery. Indonesia-hosted deployments include a secondary regional availability zone within-country, with documented RPO and RTO commitments appropriate to each tier. Cross-region failover preserves the audit log without gap.
A reference map of the features Reach delivers, organised by layer and by buyer persona.
| Layer | Capability | Primary buyer |
| L1 Orchestration | Unified identity binding to host app (FIDO2, device attestation via Sentinel) | CISO, Enterprise Architect |
| L1 Orchestration | Consent lifecycle and preference centre (PDP Law, POJK 22/2023) | Data Protection Officer, Compliance |
| L1 Orchestration | Unified event bus and telemetry schema | Enterprise Architect, Data Platform |
| L2 Inbound | In-app contact centre (voice, video, chat) with agent desktop | Head of Contact Centre, CX |
| L2 Inbound | Intelligent routing (skill, tier, language, device risk) | Contact Centre Ops |
| L2 Inbound | Supervisor monitoring, QA, workforce management | Contact Centre Ops |
| L3 Outbound | Self-service campaign builder and journey designer | Head of Marketing, CMO |
| L3 Outbound | Push, in-app message, SMS fallback, rich notification | CX Ops, Marketing Ops |
| L3 Outbound | A/B testing, frequency capping, suppression, consent gating | Marketing Ops, Compliance |
| L3 Outbound | Partner ecosystem promotions with attribution | CMO, Partnership Lead |
| L4 AI Copilot | Conversational AI with Bahasa Indonesia NLU | CX, Product |
| L4 AI Copilot | Agent assist (draft, next-best-action, retrieval) | Contact Centre Ops |
| L4 AI Copilot | Retrieval-augmented generation over institution's own knowledge base | Data Platform, CX |
| L5 Surveys | NPS / CSAT / CES triggered by journey event | CX, Insights |
| L5 Surveys | In-moment feedback bound to conversation ID | CX, QA |
| L6 Video | Embedded video KYC with liveness and document capture | Onboarding, Risk |
| L6 Video | Video teller and expert consultation with recording | Retail Banking, Wealth |
| L7 Analytics | Operational dashboards and agent performance analytics | Contact Centre Ops, CX |
| L7 Analytics | Regulatory evidence exports (complaint, consent, communication trail) | Compliance, Audit |
Reach does not compete on per-feature depth against any single category leader. It competes on a different axis entirely — coherence under one identity, inside the institution's own application.
The incumbent engagement landscape is organised by category. An institution that wants what Reach offers must currently buy a CCaaS product, a CEP product, a CPaaS product, a survey product, and a video KYC product — and integrate them. Reach's competitive position is not the best contact centre; it is the only contact centre whose customer conversation continues, uninterrupted, into a campaign, into a survey, into a video expert call, and into a regulatory audit, all under the institution's own identity.
| Incumbent | Category | Structural limitation | Reach's answer |
| Genesys Cloud CX | CCaaS | Desktop-first, heavy to mobile-embed; no device posture; routes to agents but not to device context. | Mobile-native from L2 down; device posture inherited from Sentinel. |
| NICE CXone | CCaaS | Enterprise but generic; no in-app trust layer; no regulatory-specific conversation evidence. | Evidence-grade log purpose-built for BFSI supervisory questions. |
| Amazon Connect | CCaaS | Toolkit-oriented; requires custom build; no banking-specific templates; heavy engineering cost. | Pre-built for BFSI journeys; self-service where possible. |
| Twilio Flex + Engage | CCaaS + CEP | Strong APIs, no consolidated identity across inbound and outbound; no regulatory evidence export. | One identity, one audit, one consent model across both directions. |
| Braze | CEP | Outbound-only; no contact centre, no voice, no video; no evidence model for supervisory use. | Outbound is one layer of a fabric, not a standalone product. |
| CleverTap | CEP | Same shape as Braze with stronger APAC presence; mobile-native but engagement-only. | Same coverage plus contact centre, surveys, video KYC, AI copilot. |
| MoEngage | CEP | Strong in Indonesia but engagement-only; no consolidated service layer. | Engagement is a feature, not a product. |
| Qualtrics / Medallia | VoC / Surveys | Separate system of record for feedback; not bound to the conversation that produced it. | Feedback is inseparable from the conversation — same event bus. |
| Jumio / Onfido | Video KYC | Hosted outside the institution's app; recordings live in vendor cloud. | Video inside the app, recording in the institution's storage. |
| Salesforce Service Cloud | Customer 360 + CCaaS | CRM-first; heavy desktop footprint; mobile-embed is a secondary capability; no in-app trust layer. | Mobile-native; inherits the institution's identity rather than imposing its own. |
| Infobip | CPaaS + CEP | Strong APAC presence; channel-focused; no consolidated contact centre, no video service, no evidence model. | Single fabric across channels with regulator-ready evidence from day one. |
The incumbents are not wrong. They are partial. Reach's claim is that partiality, not product quality, is the limiting constraint of the current architecture.
Where point solutions may still be the right answer
Reach is built for coherence across the customer conversation, not for maximum feature depth in any single category. Institutions whose strategic constraint is a specific best-of-breed capability — global-scale SMS pricing, longitudinal voice-of-customer research, the deepest workforce management feature set — should evaluate point solutions alongside Reach. For institutions whose strategic constraint is the fragmentation of the conversation itself, Reach is the more defensible architecture.
The table covers the most-encountered incumbents in Indonesian BFSI engagement procurement. A longer comparative analysis, including Avaya Experience Platform, Sinch, and on-premises Genesys PureConnect, is available under NDA as part of the technical evaluation package.
Build, buy, or partner
An institution with strong internal engineering can plausibly build its own orchestration layer and keep best-of-breed vendors underneath; an institution with a deep systems-integrator relationship can plausibly ask its SI to assemble the fabric. These are legitimate paths. Reach is the faster path where the institution's strategic constraint is time-to-coherence rather than engineering capacity, and where the regulatory evidence burden is large enough that the cost of assembling the platform from parts exceeds the cost of buying the platform pre-assembled. Where either path is the better answer, Reach will say so during the executive briefing.
On the direct-AI alternative
A 2026 evaluator will reasonably ask: why Reach's AI layer rather than a direct integration of OpenAI or another foundation-model provider into the institution's own stack? The honest answer is that the foundation model is the easy part. What Reach contributes above the model is conversation context, coherence with the identity and audit fabric, the retrieval layer over the institution's own knowledge base, the sovereign deployment option, the safety architecture around customer-facing generation, and the evidence retention the regulator will eventually ask about. Institutions whose constraint is raw model capability will still buy foundation-model access directly; institutions whose constraint is regulator-ready agentic service will find Reach's position defensible.
Reach is designed to sit beside the institution's existing systems for the duration of the migration, and to absorb them only when the institution chooses.
No BFSI institution with a working contact centre, a working CEP, and a live customer base is going to replace its engagement stack in a single programme. Reach's integration model is built for a two-to-three-year migration in which the institution runs Reach alongside the incumbents, moves journeys one at a time, and retires legacy systems at its own pace.
Integration surface
| System | Integration pattern | Year-one behaviour |
| Core banking | SNAP adapter (BI), REST/SOAP gateway, message queue | Reach reads customer and transaction context; writes nothing to the core. |
| Existing CCaaS | Coexistence via SIP trunking and agent federation | CCaaS continues for external-initiated calls; Reach owns in-app initiated contact. |
| Existing CEP | Event bridge on the campaign event bus | CEP continues for email and SMS-broadcast campaigns; Reach owns in-app journeys. |
| CPaaS (Twilio, Sinch, Vonage) | Fallback delivery channel via provider API | Reach sends via CPaaS only when the customer is offline; usage declines as app engagement rises. |
| Identity provider (IdP) | OIDC with FIDO2 second factor; device attestation via Sentinel | Reach inherits the institution's existing IdP; no parallel identity. |
| Complaint / case management | Bidirectional event exchange; case-ID federation | Reach produces the communication trail; case system retains the case-of-record. |
| Analytics / data lake | Streaming export via Kafka / Kinesis / Pulsar | Every Reach event replicated to the institution's lake; no vendor data lock-in. |
Data residency and sovereignty
Reach supports three hosting models: Nexilis-managed SaaS in Indonesia (Kominfo PSTE-compliant, PADG 24/2022-aligned), private single-tenant in the institution's cloud (AWS Jakarta, GCP Jakarta, Azure Indonesia Central), and fully on-premises for institutions with classified data obligations. All three run from a single codebase with model-specific deployment profiles; release cadences, support models, and operational runbooks differ by model and are documented per engagement.
Event platform
Reach runs its internal event bus on Apache Pulsar with CloudEvents-formatted payloads. Events are produced onto the Reach bus and exported, via streaming connector, to the institution's own event platform (Kafka, Kinesis, Pulsar, or equivalent). The institution owns every event that passes through Reach; exportable, portable, no vendor data lock-in.
What administrators, supervisors, compliance officers, and marketing operators actually see and use.
Administrator console
The administrator console is a web application for platform operators: tenant configuration, user and role management, policy authoring, consent template design, retention rules, data subject request handling, and integration management. All actions are themselves audited; the administrator console produces evidence the same way the customer-facing layers do.
Agent desktop
The agent desktop is purpose-built for in-app conversations. When a customer initiates a service moment, the agent receives the customer's identity, recent journey, device posture, open products, and outstanding issues before the conversation opens. The agent writes a resolution record; the record is the audit trail. There is no separate wrap-up dictation, no separate call-notes field, and no separate system of record to reconcile.
Insider risk is addressed as a first-class concern. Agent sessions are bound to a specific device and a specific shift; sensitive fields (full card number, full identity number, contact details) are masked by default and require just-in-time step-up authentication to reveal; a tamper-evident screen recording of every sensitive action is captured and retained under the same policy as the customer conversation; agent-side DLP prevents copy-out of sensitive content.
Campaign studio
The campaign studio is a self-service environment for marketing operations. Journeys are designed visually; segments are built against the unified telemetry; consent gates and frequency caps are enforced at design time, not at run time; A/B tests are scoped automatically. Marketing operations can ship a journey without engineering involvement — which, in most institutions, is the single largest blocker today.
Supervisor and workforce tools
Supervisors see live queues, agent states, real-time conversation quality indicators, and the standard operational KPIs of a modern contact centre: AHT, FCR, service level, ASA, occupancy, adherence, and shrinkage. Workforce management produces schedules against forecasted volume, honouring agent skills and compliance constraints. For institutions with existing enterprise WFM investments (NICE WFM, Verint, Calabrio), Reach publishes the events those systems need and coexists with them rather than replacing them. Quality review samples conversations across channels uniformly; the sample frame is the unified conversation record, not the channel-specific one. AI-assisted quality review is available in the Enterprise tier.
Compliance cockpit
The compliance cockpit is the interface for Data Protection Officers, complaint handlers, and audit teams. It produces three specific outputs on demand: the complete communication trail for a single customer, the consent history for a specific marketing touch, and the off-channel attestation report that supervisors now expect to receive within days rather than weeks.
What the operator does not have to do
Reach is designed to remove, not add, operational work. The operator does not reconcile conversation records across systems, does not build consent templates per channel, does not manually export compliance evidence, does not maintain per-channel identity, does not run separate A/B tests for in-app versus push, and does not maintain a separate knowledge base for the chatbot and the agent. Each of these, in a federated architecture, is a standing operational tax.
Reach was designed to satisfy the customer-communications and consent obligations of Indonesian financial services regulation and the data protection law, with direct mappings to specific provisions.
| Regulation | Relevant requirement | Reach capability |
| OJK POJK 11/2022 Digital Banking Resilience | Mobile channel integrity, tamper detection, incident response, customer authentication | App-integrity inheritance from Sentinel, single-session audit log across all Reach-owned channels, incident evidence export |
| OJK POJK 22/2023 Consumer Protection in Financial Sector | Consent capture, complaint handling, record retention, responsible marketing | Unified consent lifecycle, evidence-grade complaint trail, retention under policy engine |
| OJK POJK 6/2022 Consumer Conduct | Clear communication, accurate disclosure, complaint resolution timelines | In-app disclosure templates, SLA enforcement on resolution windows |
| UU 27/2022 (PDP Law) | Lawful basis, consent, data subject rights (to know, access, correct, erase), retention, data residency | Consent lifecycle, subject-request console, retention policy, Indonesia hosting — posture adjusted as Kominfo implementing regulations mature |
| SEOJK on Digital Banking Risk Management current instrument | Audit trail and evidentiary retention for digital channel communications | Single audit log across inbound, outbound, survey, video, and AI interactions |
| Bank Indonesia SNAP open banking payment standard | Secure consumption of SNAP APIs from the mobile channel | SNAP-compatible client adapter with attestation-bound authentication via Sentinel |
| Bank Indonesia PADG 24/2022 under PBI 23/6/2021 | Data localization for payment system providers | Indonesia-hosted deployment; data plane, control plane, and archival storage in-country |
| Kominfo PP 71/2019 (PSTE) and current implementing instruments | Data sovereignty for strategic electronic systems | Indonesia-hosted SaaS; institution-hosted deployment supported |
| US SEC Rule 17a-4 / FINRA 3110 reference precedent | Record retention for broker-dealer communications; off-channel enforcement precedent | Evidence-grade archive of every conversation across every channel Reach owns |
| GDPR (reference) | Lawful basis, consent, right to be forgotten, breach notification | Same consent architecture applies; GDPR posture available for multinational deployment |
Detailed control mapping
A detailed control-mapping document, showing each regulatory provision and the specific Reach layer or capability that satisfies it, is available under mutual non-disclosure as part of the technical evaluation package. Institutions with active procurement cycles receive this package promptly on NDA execution.
Reach is packaged in three tiers. Each tier is a proper subset of the next — investments made at a lower tier are preserved on upgrade.
Service levels, support, and implementation
Foundation includes a 99.9% control-plane availability SLA with business-hours support. Growth includes 99.95% availability with 24×7 support and a dedicated customer success manager. Enterprise includes 99.99% availability on customer-facing integration with priority engineering access and named incident management. Production go-live from contract signature typically lands between three and nine months depending on integration scope; professional services are scoped per engagement and, as an indicative guide, run between twenty and sixty per cent of first-year licence for a typical deployment.
Scale, channel, and multinational deployment
Tier seat and MAU figures are licensing envelopes, not technical ceilings; the platform scales well beyond Enterprise tier ranges and every engagement produces a formally agreed capacity plan. Reach is available directly from Nexilis and through established Indonesian systems integrators; L1 support sits with the integrator where one is engaged, with L2 and L3 at Nexilis. For multinational deployments, pricing is quoted in USD and taxation follows the customer's jurisdiction.
On pricing by envelope rather than volume
Reach does not price by message volume; campaign volume scales within the tier envelope rather than producing a usage surprise at month-end. Telecommunications pass-through costs — SMS aggregation, voice termination, video bandwidth — are billed at cost plus a declared margin, on the principle that the institution should not pay the vendor a premium on what the vendor itself pays a carrier. Institutions that prefer usage-based pricing — particularly those running very heavy outbound volumes where vendor cost alignment is the primary concern — can request a usage-linked alternative; the tiered envelope is the default because, for most institutions, it produces more predictable annual planning.
On escape velocity and data ownership
Every conversation record, event, consent history, and journey definition held in Reach is streamed in real time to the institution's own data lake in standard formats, and is exportable at any time. The institution owns its operational data; there is no vendor data lock-in; Reach can be migrated off the same way it is migrated on — progressively, journey by journey, in the same coexistence mode that allowed migration in.
On vendor viability
PT Easysoft Indonesia is a focused Indonesian technology company with a single platform codebase and a product family built entirely in-house. Source-code escrow is available for Enterprise deployments; continuity provisions are written into the master agreement on request. The sovereign-vendor posture is a deliberate strategic choice, not an accident of size: a smaller Indonesian-headquartered engineering organisation, operating close to its regulators and its customers, is able to move on Indonesian BFSI requirements faster than any of the global incumbents in the competitive landscape.
On reference customers
Reach is a newly consolidated product assembled from components of the Nexilis platform that have been deployed in production with Indonesian financial services and government institutions since 2023. Anonymised reference narratives covering specific component deployments are provided under NDA during technical evaluation. As named references accrue, they will be shared directly with the relevant evaluation team.
On SMS fallback and the trust boundary
The Reach thesis is that the customer conversation belongs inside the institution's own application. SMS fallback, where included, is not a substitute channel — it is a delivery-of-last-resort for moments when the customer is genuinely offline or has not yet opened the app. Every SMS-delivered touch is accompanied by a signed in-app counterpart that supersedes it the moment the customer reconnects. The fallback exists because no platform can assume 100% of customers are always-on; it is the exception the institution manages actively, not the default architecture.
How an institution evaluates Reach, from first conversation to production engagement.
In Indonesian formal procurement, where the institution issues a Request for Information and a Request for Proposal, the executive briefing, technical evaluation, and proof of concept described here fit naturally into those procurement gates. Nexilis responds to structured procurement on the institution's own timetable.
Jakarta, Indonesia · nexilis.io
nexilis.support@nexilis.io
This document and the product architecture it summarises are the confidential property of PT Easysoft Indonesia. Distribution to parties outside the receiving institution requires written authorisation. Specific architectural details, third-party security assessment summaries, and regulatory control mappings are provided to qualified institutional evaluators under mutual non-disclosure as part of the technical evaluation package.
These documents render live on this page — there is no separate file to download, so what you read here always matches the current product. Deeper technical detail is available under NDA. Request a briefing.
Fifteen minutes walks you through the unified agent desk, the journey builder, and what deployment looks like alongside your existing CX stack.