How does the consent management module work?
The consent management module records which channel (call, SMS, email) you may send a customer a commercial message on, and which sensitive information you may process about them. Under Turkey’s Law No. 6563 on the Regulation of Electronic Commerce, a commercial electronic message (call/SMS/email) cannot be sent without the recipient’s prior consent, and that consent must be registered with İYS (the national Message Management System); a consent that is not registered there is not considered valid (T.C. Ministry of Trade, general information). The module keeps the ledger that obligation requires.
A consent ledger by channel
Every consent row is tied to a specific channel (call/SMS/email) and a specific class (transactional or commercial) — a customer consenting to commercial SMS does not imply consent for email too; each channel is its own row. Once a consent is added or withdrawn, the row is permanent and never overwritten — “when, on which channel, from where” is answered by a timestamp, the acting user and the source. A customer can withdraw consent across all channels with one action; that withdrawal shows on the customer card and closes the channel itself.
Sensitive fields and explicit consent
Some fields on a customer card — for example, information a sector like healthcare requires — sit in a sensitive group that needs explicit consent. This group is off by default: a company first decides to turn the section on, then assigns a separate permission to whoever should be able to see it. Writing to a sensitive field requires a recorded consent date first; without consent, the field does not even open. Every access to these fields leaves an audit row, so “who looked, and when” always has an answer.
Branch/campus scope
Companies with more than one branch, campus or vessel can scope customer access by branch — a branch employee sees only their own branch’s customers. The consent record itself, however, is company-wide: no matter which branch a customer came through, consent is a single fact and applies the same everywhere — the alternative would mean the same person getting a commercial message from one branch while being marked as opted out at another, an inconsistency the design rules out.
Bulk export to İYS
The module can bulk-export recorded consents in İYS’s format — producing the file a company uploads to its own İYS account. Proof of consent today is not a versioned text but the triple of time + acting user + source; which exact consent wording was shown is not separately stored, a deliberate simplification that can be extended later if the need arises.
Example
Picture a school-shuttle company: a parent consents to SMS on the enrolment form but not to email. The system keeps these as two separate rows; the start-of-term announcement can go out by SMS while the same announcement’s email copy never reaches that parent. A year later, when the parent says “I don’t want SMS either now”, one action withdraws it, and no commercial message goes out on any channel from that point on; the school’s administrative messages (the transactional class, e.g. “your shuttle is running late”) are unaffected by that withdrawal, because transactional and commercial are separate classes.
Who uses it
The people updating the consent ledger day to day are usually sales and customer service — they can change a consent preference on the spot during a call. Running the export before a bulk send is usually marketing or management’s job; that screen is protected by its own permission, separate from the permission to add or remove a single consent — a user might be able to update consent one customer at a time without being able to run a bulk export. The sensitive-information group deliberately has no image or file field — consent-requiring information is kept as text, never as a document or photo — a deliberate limit that keeps the risk that kind of data carries as small as possible.
How it works in Rotenta
- From the customer card’s Permissions section, a consent is added for a channel (call/SMS/email) with a class (transactional/commercial).
- The consent row is stored permanently with a timestamp, the acting user and the source.
- To write sensitive information, the Sensitive info section must first be turned on at the company level, then the user needs their own permission for that section.
- When a customer wants to withdraw consent, a single “Withdraw” action closes the relevant channel.
- In multi-branch companies, customer access is scoped from the Branches screen; the consent record itself is unaffected and stays a single company-wide fact.
- Before a bulk send, the Export action downloads the consent list in İYS’s format.
You can read about the customer card these consents live on in customer management, and about who can see which section in roles and audit trail. Our module guide shows how this module fits together with the rest; to talk through migrating your existing consent ledger during setup, get in touch.
Frequently asked questions
Can a customer consent to SMS but not email?
Yes; each channel is its own consent row, and consenting to one does not imply consent for another.
Does withdrawing consent delete the past record?
No; a withdrawal is added as a new row, so when the earlier consent was given is never lost — only the channel closes from that point on.
Who can see a sensitive information field?
Both the company has to have turned that section on and the user needs their own permission for it; missing either one means the section does not show at all.
Does a transactional notice (e.g. “your vehicle is on the way”) need consent?
No; transactional and commercial messages are separate classes, and transactional notices can continue even if commercial consent has been withdrawn.
Do we have to build the İYS upload file by hand?
No; the module exports recorded consents in bulk, in the format İYS expects, and you upload that file to your own İYS account.
More in this category
- How does vehicle and driver document tracking work?
Warns on an expired or upcoming vehicle/driver document, and blocks trip assignment when a required one has lapsed.
- How does the vehicle and driver (fleet) module work?
One ledger for your vehicles and drivers that trips assign from and that answers who is available, when.
- How does recurring shuttle planning work?
A route and weekly plan are defined once; public holidays are skipped, one-off exceptions post as billing deductions, and off-plan extra trips enter the statement as their own line.
- How is e-invoicing (e-Fatura/e-Arşiv) integrated?
Tax ID and scenario data carried on the invoice record flow straight through; send status and the tax authority's reference show on the panel in real time.
- How does the Excel data import module work?
A module that validates and previews your existing spreadsheets, isolates the bad rows, and can undo an import if needed.
- How is workflow automation set up?
Trigger + condition + action rules ship as ready templates, every run is recorded as evidence, and a rule bound to a closed module shows as visibly inactive, never silent.
- How does the customer management (CRM) module work?
One card for people and companies, encrypted sensitive fields, tagging and notes — how Rotenta's CRM module is laid out on screen.
- How does the accounting module: accounts, invoices, cash work?
Current account, invoice, cash and instalment tracking brought together in one accounting module, from proforma to day-close.
- How do PDF outputs and letterhead documents work?
One core engine that puts your letterhead on invoices, statements, receipts and passenger lists, and logs every document it produces.
- How are staff shifts and timesheets managed?
Timesheets are produced from realised trips, deductions carry evidence and a dispute path, staff on leave cannot be reassigned, and period close freezes the past.
- How do reports and profitability analysis work?
Every list you own exports at full fidelity, aging buckets of 0-30/30-60/60-90/90+ days sit on one screen, and period profitability drills all the way down to the source trip.
- How does booking and capacity management work?
A resource x time-slot booking engine that blocks double-selling, tracks option deadlines and converts a confirmed request straight into a trip or service record.
- How do roles, permissions and the audit trail work?
Roles decide who can see what, and the audit trail keeps a permanent record of who changed what and when.
- How does the trip and transfer operations module work?
One record that follows a trip from planning to completion, carrying its passengers, driver, vehicle and price lines together.
- How do contracts and progress billing work?
The contract is the single price source; progress billing is calculated automatically from trip records, penalty clauses apply on their own, and an approved statement becomes an invoice in one click.
- How do quotes and proposals work?
Quote lines read from the published rate list, margin is visible to authorised users, a five-state lifecycle is tracked, and an accepted quote converts to an invoice in one click.
- How does bulk messaging and consent compliance work?
Consent is checked at send time against İYS, the national record; every commercial message carries an opt-out link, and delivery state is kept as evidence.
- How is U-ETDS reporting done?
Every trip already carries the fields U-ETDS reporting needs; send status shows on the trip card and never shows an optimistic 'sent' before it is confirmed.
- How does the AI assistant module work inside the panel?
An in-panel assistant that works within your own permissions, masks personal data, and asks approval before every write.