Aydınlatma metni yükleniyor…
For businesses managing several locations around Bağdat Avenue, Suadiye and Caddebostan, the hardest web-software question is not branch count but where decisions belong. Some price, inventory, menu, service, campaign and booking data should come from head office; some must adapt to real local conditions. Without boundaries, head office overrides reality while locations create disconnected copies.
This guide does not use the district as evidence of an office or local results. It helps genuinely multi-location brands prepare an implementable brief for the head-office/location data model, permissions, integrations and outage behaviour.
Divide decisions among head office, locations and systems
Classifying all data as “central” or “local” is too broad. Product identifiers and brand copy may be central while inventory, daily availability or temporary closure belongs to a location. Price may follow central policy with local change allowed only inside a defined range.
For each field, record master source, view and edit rights, approval, validity period and reversion. A local change should be a traceable override with reason, duration and owner rather than an uncontrolled copy.
The head-office/location operating envelope: five boundaries
Kumsal Ajans developed this operating envelope to define every data group through five boundaries: central standard, local flexibility, publication condition, outage mode and reconciliation evidence. A vague requirement such as “locations can update it” becomes a testable business rule.
| Data | Central standard | Local flexibility |
|---|---|---|
| Product/menu | Code, name and brand copy | Availability and temporary hiding |
| Price/campaign | Policy and validity | Allowed range or participation |
| Inventory | Product and unit rules | Count, reservation and correction |
| Booking | Service, state and cancellation model | Capacity, staff and buffers |
| Location data | Brand and required fields | Hours, notices and access notes |
Localise products, menus and services without cloning
The central catalogue can own identity, categories, base descriptions and media rules. The location layer adds availability, preparation time, daily choices or temporary state. It should extend the central identity rather than copy and detach it.
Define whether local values survive a central update and what happens to booking or order history when a product is removed. In multilingual operations, central-copy changes and local additions need separate outdated-translation alerts.
Make price and campaign authority explicit
State who may change price, within which range and dates, and through which approval. Acceptance examples should cover participating locations, excluded products, channel differences, overlapping-discount priority and automatic expiry.
The displayed and transaction-time price should come from the same trusted rules. Never accept totals or discounts submitted by the interface as authoritative. OWASP recommends re-deriving sensitive business values server-side from trusted data (OWASP Business Logic Security).
Express inventory and booking through capacity
Inventory includes reserved, unavailable, in-transit, damaged and uncounted quantities. Booking capacity combines people, tables, rooms, equipment and preparation time. In both cases, the sellable or bookable value should be derived through business rules rather than read from a raw number.
A repeated device request must not create a second transaction; concurrent demand must not push capacity below zero; cancellation must reverse the correct movement. Put transaction identifiers, state transitions and final validation in technical acceptance.
Build roles from actions, not menu labels
“Head-office admin”, “location manager” and “staff” are insufficient definitions. Specify who can view price, propose a change, approve, publish, reverse, access customer data or export a report. Include multi-location assignment, temporary cover and role removal.
Hiding a menu is not authorisation. Validate every request server-side against user, location, field and current state. Critical changes may require a second approver, reason or time-limited permission.
Design outage modes beyond a closed website
When the central connection fails, may a location show the last menu? Can it accept bookings? Should unverified inventory become an enquiry? Select safe continuation, read-only, queue or stop for every function.
Queued operations need order, unique identity, timestamp and retry state. When central and local users changed the same field, define automatic precedence, human review and alert conditions. Silent “last write wins” makes data loss invisible.
Integrations need reconciliation and operating evidence
Compare central totals and local movements daily or at a justified interval. Classify missing, duplicate, rejected and pending records separately and assign an owner and resolution time. Success means consistent business outcomes, not merely an API response.
OWASP recommends consistent application-event classification with identity, time, outcome and enough context for traceability (OWASP Logging Cheat Sheet). Avoid unnecessary personal data and secrets while enabling the team to answer who changed what at which location.
Do not expose customer data to all locations by default
Every branch may not need access to all customer, appointment and loyalty data. Define purpose, field scope, retention, export and permission removal. Turkey's Personal Data Protection Authority includes explicit purpose, minimisation and limited retention among its general processing principles (KVKK general principles).
This section is general scoping guidance, not legal advice. Qualified legal and information-security reviewers should assess the business model, data categories and transfer parties.
Deliverables to require in proposal and handover
- Field-level central/local ownership and override matrix
- Product, price, inventory, booking and location-data dictionary
- Role–action–location permission table
- Approval, publication, reversal and expiry state models
- Outage, queue, retry and conflict-resolution plan
- Reconciliation reports, alerts, logs and ownership chain
- Personal-data access, retention and permission-removal decisions
Develop the technical brief with the off-the-shelf and custom web software guide and review the Kumsal Ajans web software service for implementation scope. Sound multi-location software protects shared standards while giving verified local reality a controlled operating space.