Connect the transaction to the dealer’s systems

Narell is designed to connect inventory, DMS, CRM, identity, financing, signing, payment and fulfilment workflows. The current implementation distinguishes internal controls, synthetic provider flows and external integrations still requiring acceptance. None of the providers named here is presented as a commercial partner.

Inventory and DMS

Vehicle records, approved prices, seller details and availability are the inputs to a purchase. Narell has inventory publication and transaction allocation controls. External inventory feeds and DMS adapters are planned, with scope agreed for each dealer.

Availability and transaction updates are the outputs to define with the dealer. There is no currently connected DMS vendor or cross-channel DMS lock. Until such an integration exists, the dealer needs an agreed inventory-allocation process.

Customer relationships and CRM

Buyer access and purchase progress are implemented in Narell. External CRM data exchange is planned. A deployment must define which consented customer information enters the transaction and which milestones return to the CRM. The dealer keeps the relationship; Narell does not replace its customer-management system.

Identity

The standalone mObywatel workflow currently uses a synthetic sandbox. A production adapter boundary exists, but official transport, onboarding and acceptance are incomplete. A demo verification does not verify a real person.

The implemented workflow associates a verification request, consent, expiry, result and attribute provenance with the relevant buyer and purchase. Unknown outcomes require review. Live identity evidence must satisfy the approved provider and transaction requirements.

Financing

Leasing and credit applications, offers, signing steps and split funding can be exercised in the isolated sandbox. No live bank, lender or lessor is connected. No real financing application is submitted through the public demonstration.

The transaction keeps vehicle price, applicant information and selected parameters together. It distinguishes an estimate from an offer, and customer contribution from provider disbursement. Real decisions and funding require a contracted, accepted provider.

Electronic signing

An Autenti adapter with KIR mojeID identity constraints is implemented. Merchant configuration, legal acceptance and provider acceptance remain outstanding. This is an implemented adapter, not a live integration, certification or partnership.

The signing workflow sends the intended document and parties, tracks progress, validates completion evidence and retains original and signed document bytes. An uncertain provider result cannot silently conclude a contract. The public sandbox simulates signing.

Payments

Dealer bank-entry reconciliation and controlled refund recording are implemented. The dealer receives the money; Narell does not hold customer funds or initiate transfers. There is no automated bank feed or connected payment provider.

Authorised accounting staff record statement entries, match them to purchases and handle exceptions. Recorded receipts, corrections and refunds determine the remaining obligation. A buyer’s transfer screenshot is not payment evidence.

Registration and fulfilment

Dealer-operated registration, insurance, preparation and handover controls are implemented. These are operational records and release checks, not registration-authority, insurer or transport-provider integrations. Complete evidence handling and operational acceptance remain release work.

See the connected purchase lifecycle and the access and transaction controls. A technical scoping conversation can establish the actual interfaces needed for your dealership.