Recipient visibility
- Central account
- Authorised central groups and sending records can be selected.
- Reseller and sub-account
- Resellers can be limited to records belonging to their own accounts.
← All products
Development on request
Messaging & NotificationsSMS & Reseller Management Software
Review sending preparation alongside recipient records, reseller balances and provider status reports. We will scope the SMS and reseller management panel we will build around your chosen authorised provider's technical conditions and your business's account structure.
- Reseller and sub-account boundaries
- Consent and opt-out records
- Provider status reports
- Discovery
- Scope and quote
- Development
Find balances, recipient lists and delivery states through linked records
Use records to explain which account, list and sender name prepared a send. Separate reseller balance tables, opt-outs in conversations and results in provider panels make a message's history difficult to trace. Duplicate numbers also add checks during preparation. We will plan recipient groups, sending records and accounts together. Submission to the provider and delivery notifications to recipients' devices will have separate fields.
Records that fragment tracking
- Opt-out requests are not rechecked against later recipient lists.
- Reseller balance use is calculated separately from message history.
Connections to choose in the project
- Send preparation can link to its account and recipient group.
- Provider-returned states can link to message records.
From an SMS recipient list to a provider status report
Let us choose recording order around a reseller's bulk or scheduled message. We will examine sender names, list checks and provider-returned states together. These steps help discuss the panel's business rules.
- 01
Prepare the list and sender name
Recipient imports from CSV or spreadsheets can be scoped. Duplicate and invalid-number checks will be separate from choosing sender names approved through the provider.
- 02
Assess the sending request
Message text, template fields, timing and account balances can be considered together. Consent and opt-out checks will be scoped around message purpose and your authorised adviser's assessment.
- 03
Link returned states
If the provider offers access, sending and message-level status retrieval will be examined. Pending, delivered and undeliverable results can be recorded using provider codes.
Separate the sending core from reseller-management modules
We can choose the initial panel around message preparation and record checks. Reseller hierarchies and sending triggered by your own application need different permissions and connections. Together, we will decide which modules enter the first release and which fields belong in later development.
Initial sending scope
- Contacts and message records
- Recipient imports, groups, duplicate checks, templates, scheduled sends and opt-outs can form the starting scope. Status reports will reflect information the provider can supply.
Expansion as needed
- Resellers and branding
- Balance allocation, sub-accounts, reseller logos and domain selection can be added. Your business model will determine hierarchy depth and which resellers use these fields.
Dependent on technical access
- Provider and API
- Sending fields will be examined if an authorised SMS provider offers a connection. A keyed API for your systems and access to İYS, Turkey's commercial-message consent management system, will be assessed separately against technical and legal conditions.
Compare central-account sending with reseller and sub-account use
A central account preparing messages and a reseller managing sub-accounts need different visibility rules. We will select the level for balance-allocation tracking and usage reports. Using the same provider does not mean recipient lists and transactions are visible to every reseller.
| Compare central-account sending with reseller and sub-account use | Central account | Reseller and sub-account |
|---|---|---|
| Recipient visibility | Authorised central groups and sending records can be selected. | Resellers can be limited to records belonging to their own accounts. |
| Balance movements | Central usage and allocation records can be considered. | Balances allocated by parent accounts can be tracked separately from use. |
| Reporting scope | Account breakdowns can be selected for authorised aggregate summaries. | Resellers can report on their own sub-accounts' states. |
Balance movements
- Central account
- Central usage and allocation records can be considered.
- Reseller and sub-account
- Balances allocated by parent accounts can be tracked separately from use.
Reporting scope
- Central account
- Account breakdowns can be selected for authorised aggregate summaries.
- Reseller and sub-account
- Resellers can report on their own sub-accounts' states.
Separate recipient data, balance operations and SMS API access
Sending and exporting the entire contact list should have different permissions. Allocating balances and changing provider connections will also be assessed separately. The software we will build can include user, reseller and sub-account boundaries alongside person-linked action records.
Reseller visibility
Account boundaries can be selected for lists, message histories and sub-account actions. Central authorised roles will be defined separately without assuming sharing between resellers.
Connections and balances
API keys, sender selection and balance corrections can have distinct access. A balance movement's source and relationship to message usage can be assessed separately.
Phone numbers and consent
KVKK, Turkey's personal data protection law, retention and export needs will be considered for phone numbers; you are the data controller. Commercial-message consent, opt-outs, Turkey's İYS system and relevant requirements will be assessed with your authorised adviser.
Handle uncertain consent records and changed SMS sending times
Recipient checks need to continue after the first list import. An opt-out may arrive while a scheduled message waits, or a number's consent source may be missing. We will scope consent states, opt-out records and fresh checks before sending. Timing changes will include decisions on which user's action to record and when lists need checking again. Setting uncertain-consent numbers aside for review can be a project rule. Message purpose and applicable legal conditions will be assessed by your authorised team and adviser.
What weakens recipient checks
- Opt-outs received after preparation of a scheduled list are ignored.
- Numbers without traceable consent are treated as complete records.
Checks to design before sending
- Current opt-outs and consent can be considered again before sending.
- Timing changes and recipients awaiting review can link to records.
Match recipient groups, opt-outs and reseller accounts
Review account ownership and consent sources alongside number lists before transfer. We will assess table formats using sample data in place of real phone numbers. Together, we will select authoritative records for reseller hierarchies and opening balances.
- 01
Separate the fields
Number formats, groups, accounts and consent sources can be mapped. Handling duplicates and marking uncertain consent can enter project checks.
- 02
Verify opening accounts
Compare reseller and sub-account relationships and starting balances in a sample transfer. Your acceptance checks can assess opt-out lists against accounts and message types.
- 03
Examine provider codes
With API access, examine send acceptance, delivery reports and errors. Rules preventing unintended repeat sends on retries will be scoped according to technical capabilities.
Explore resources for linking message requests to business workflows
Consider which account and recipient a message request from your system should belong to. Service and project pages offer examples for discussing triggers and record handovers. Reseller boundaries and consent checks will be specific to your business model's scope.
Start with an account diagram and sample sending record
Prepare shareable reseller hierarchies, blank recipient tables and provider-code examples. Remove real numbers and access keys. Explain how you handle changed opt-outs for scheduled messages today to select the initial checking scope.
- Identify roles allocating balances and preparing messages.
- Give examples of consent-source and opt-out fields.
- Describe provider connections and your own API expectations separately.
The proposal will reflect sending workflows, account hierarchy, checks and connection limits. Software subscriptions, provider transmission terms and support scope will be discussed separately in writing.
How we work
We do not sell an off-the-shelf package: we design the software around your workflow, build the first version in short steps and keep running it after launch.
- 01
Discovery
We listen to how your business works, your team and the tools you use today.
- 02
Scope and quote
Modules, priorities and price are set out in a written quote.
- 03
Development
We show working versions at short intervals and move on with your feedback.
- 04
Setup and migration
We move your existing records across and help your team get started.
- 05
Support
We run the software on a subscription and keep it up to date and secure.
Frequently asked questions
Which infrastructure are messages sent through?
Messages are sent through a licensed operator or an authorised SMS provider. You can contract the provider directly, or the provider is chosen together during scoping; the panel connects to that provider's interface. Delivery and sending conditions depend on the provider.
How are sender IDs obtained?
Sender IDs have to be approved through the provider. That is an administrative process outside the software; the panel is set up to send with your approved sender IDs.
Who is responsible for consent and İYS obligations on commercial messages?
Obtaining recipients' consent for commercial messages and meeting the obligations of İYS (İleti Yönetim Sistemi), the Turkish commercial message management system, are your responsibility, and in a reseller structure each reseller's responsibility for its own sending. The software can provide tools such as opt-out lists, consent records and blocking of opted-out numbers; a connection to İYS is scoped per project. We do not give legal advice.
How is the reseller structure set up?
Each reseller has its own panel, credit balance and customers. Credit is allocated top-down and usage is reported bottom-up; a reseller sees only the accounts beneath it. The number of levels and reseller permissions are decided in the scope.
Can we send from our own systems via an API?
Yes, this can be scoped. With an API using key-based authorisation, your own application can trigger individual messages such as order confirmations or appointment reminders directly.
What is the difference between sent and delivered?
Sent means the message has left the panel and reached the provider; delivered means the operator has reported that it reached the handset. Reports show the status and reason codes returned by the provider for each message.
Which recipient-list version could a scheduled message use?
List preparation and pre-send checks can be separate records. Rechecking current opt-outs and consent will follow your selected workflow and conditions defined by your adviser.
Would correcting a balance change earlier message-usage records?
Correction movements can remain separate from usage records. Discovery will define who may correct balances with reasons and how movements compare with provider reports.
How is the price set?
After a discovery meeting we prepare a written quote covering the scope, the modules and the setup work. The software is provided on a monthly or annual subscription.
Do we receive the source code?
In our standard model the software is provided on a subscription and the source code is not transferred. If you need a different model, it is agreed in a separate written contract.
Who is responsible for what is done with the software?
We build and operate the software. The business using it is responsible for how it is used, the data entered and the content published; the details are set out in the service agreement.
Related products
Built on request
Appointments and Client Management
AI-Assisted Smart Appointment System
We build an appointment system around your business that brings online booking, staff and room calendars, reminders and a waiting list together, with optional AI assistance.
ViewBuilt on request
Digital Publishing & Media
News Portal Software
We build news site software that brings the reporter-to-editor workflow, front page and ad slots, subscriptions, archive migration and editorial logs together in one panel.
ViewBuilt on request
AI & Content Operations
AI-Assisted Content CRM
We build a panel that runs your content from title to publication: AI drafts to your rules, your editor edits and approves, and publishing follows the calendar.
ViewDefine your SMS sending and reseller arrangements together
Share your account diagram and sample records so we can choose the first release of the panel to develop.
- Reseller and sub-account boundaries
- Consent and opt-out records
- Provider status reports