Aydınlatma metni yükleniyor…
For brands operating stores, showrooms, clinics or appointment-led services around Nişantaşı and Teşvikiye, a website rarely works alone. Inventory may live in a commercial system, availability in a calendar, customer records in CRM, loyalty balances in another application and product copy with the content team. Web software should not create another uncontrolled copy. It should make clear where each value is read, where it may change and which source wins when systems disagree.
This guide does not use the district as evidence of an office or local results. It helps retail and service teams prepare an implementable brief covering inventory, appointments, customer data, loyalty and content.
Inventory the data objects before listing integrations
“Integrate ERP, CRM and the calendar” is not a scope. List product, variant, location, stock quantity, reservation, appointment, customer, permission, loyalty movement, campaign and content objects first. For each object, record the required fields, business owner and user task it supports.
One system does not need to own every field. The product code may come from the commercial platform, the marketing title from the content platform, and sellable availability from stock plus reservation rules. Ownership should therefore be decided at critical-field level, not merely at system level.
The data reconciliation contract: six decision columns
Kumsal Ajans developed this data reconciliation contract to connect every data group to six decisions: master source, write authority, sync direction, latency tolerance, conflict rule and post-outage reconciliation. It turns an integration diagram into an operating acceptance document.
| Data group | Decision example | Acceptance evidence |
|---|---|---|
| Inventory | Master, reservation deduction and latency limit | Concurrent request test |
| Calendar | Capacity, duration, buffer and cancellation | Conflicting booking test |
| CRM | Customer matching and update owner | Deduplication scenario |
| Loyalty | Movement ledger, balance and refund order | Repeated request test |
| Content | Product fields, media and approval | Missing-field publication test |
Turn “real-time inventory” into a measurable promise
Decide whether the interface shows a quantity, an available/unavailable state or location-specific availability. If checkout, store pickup or an appointment reserves a product, define the reservation period and release condition. A five-minute delay may be acceptable for one catalogue and cause overselling for limited items in another.
The scope should state whether the last known value may be shown during an outage, whether it carries a timestamp and which alternative the visitor receives. Replace a generic “system works” test with concurrent requests, cancellation, refund and lost-connection scenarios.
Treat appointment availability as a capacity calculation
Availability combines staff, rooms, equipment, service duration, preparation buffers, opening hours, holidays and location capacity. Between the calendar master and the web interface, use an atomic reservation or final revalidation step so two visitors cannot receive the same slot.
For multi-step journeys, the interface alone must not enforce sequence. OWASP recommends modelling workflows through explicit server-side states and allowed transitions (OWASP Business Logic Security). Define draft, pending, confirmed, cancelled and completed states, plus the roles allowed to make each transition.
Define how CRM finds one customer
Email, telephone and store-card data can create several records in different formats. Specify matching keys, normalisation, human review for probable matches and preservation of history after a merge. State which fields a web form may create or update and which remain read-only.
Permission, communication preference and profile information are not interchangeable. If a change in one channel propagates to others, its lawful basis, timestamp and source must remain traceable. Turkey's Personal Data Protection Authority lists lawfulness, accuracy, explicit purpose, data minimisation and limited retention among the general principles (KVKK general principles). Limit fields through a stated purpose and retention decision instead of collecting them “for later”.
Model loyalty as a movement ledger, not an editable number
Earning, spending, cancellation, refund, expiry and manual correction should be separate movements. Calculate the balance from those movements and reverse an incorrect movement rather than silently editing history. A request repeated after a network failure must not award points twice; each transaction needs a unique key and explicit outcome.
Acceptance examples should also define whether rule changes affect historical movements, how rounding and currencies work, and the order when a balance is used across store and web channels.
Separate commercial product fields from editorial content
Allowing content editors to change product code, price or inventory is risky, while titles, descriptions, imagery, guidance and SEO fields may not belong in the commercial platform. Define ownership by field, required values, approval and missing-data behaviour. Decide whether a product deleted at source disappears immediately or becomes an archive page.
Multilingual operations also need rules for publishing before translation is complete, alerting editors when source copy changes and selecting locale-specific media. Synchronisation should not accidentally replace editorial governance.
Choose the sync method according to the data need
Not every value needs real-time delivery. Inventory and appointments may require events or transaction-time validation; content and campaigns may move nightly or after approval. Choose according to acceptable latency, transaction volume and failure cost rather than platform habit.
Define retry limits, progressive delay, timeout, dead-letter handling, manual replay and retrospective reconciliation for every flow. An integration is incomplete if the team cannot explain how missed records are recovered after a source outage.
Logs should answer operating questions
Questions such as “why did this balance not change?”, “which system cancelled the booking?” and “when was inventory refreshed?” need a transaction identifier, source, timestamp, previous/new state and result. OWASP recommends consistent event classification and enough application evidence to reconstruct relevant activity (OWASP Logging Cheat Sheet).
Do not place unnecessary personal data or secrets in logs; define access, masking and retention. Track business indicators separately from technical error rates, including inventory freshness, booking conflicts, CRM review queues, loyalty reconciliation differences and failed content publications.
Deliverables to require in the proposal and handover
- Data-object and field-ownership catalogue
- Master source, read/write authority and sync-direction matrix
- Latency, timeout, retry and conflict rules
- Failure scenarios for inventory, appointments, CRM, loyalty and content
- Personal-data purpose, access, retention and deletion decisions
- Event logs, alerts, business indicators and named owners
- Test data, acceptance scenarios, rollback and manual operation plan
Use the off-the-shelf and custom web software guide to develop the scope and review the Kumsal Ajans web software service for the implementation approach. A sound integration is not the largest number of connected systems; it is agreement about each value's owner, freshness and failure behaviour.