Ecommerce staff permissions should reflect the work each person performs, rather than give everyone the owner's login. When commissioning ecommerce website development in Kenya, define those responsibilities before launch. The person packing orders may need a different view from the person changing prices, handling customer questions or approving a refund.
This article helps a business owner prepare a store-access brief. It is an operations planning guide, not instructions to change a live account without authorisation. Use it alongside your ecommerce development discussion to agree a manageable system for the people who will run the shop.
Start with tasks instead of job titles
List the actions that happen during a normal order. Someone reviews the order, confirms the available stock, prepares the goods and records dispatch. Another person may answer a delivery question or approve an exception. In a small business, one employee might perform several of these tasks, but the tasks should still be documented separately.
Ask what each task requires the person to see and change. A packing team might need product quantities and delivery details. That does not automatically mean it needs payment settings or the ability to export the entire customer list. An accounts reviewer may need financial records without permission to redesign the storefront.
Write the intended boundary in everyday language. For example, an illustrative fulfilment role could prepare an order and record dispatch but could not change the total charged. This is a proposed responsibility to discuss with the developer, not a statement that every ecommerce platform offers that exact role.
Prepare a small access matrix
Use a worksheet with one row per task and columns for viewing, editing, approval and the responsible person. Begin with products, prices, stock, orders, customers, discounts, reporting and system settings. Add integrations or branch operations only if they are part of the actual store.
For each row, name who performs the action and who approves sensitive changes. If the owner is unavailable, identify the agreed substitute. A permission design that depends on one person being permanently online can create unnecessary delays, even when its technical settings are restrictive.
Include exceptions. Decide how staff should handle a price error, a damaged item, a duplicate order or an incorrect delivery address. A person who cannot authorise an exception needs a clear escalation route. Otherwise, employees may share a more powerful account just to get the day's work finished.
Keep the matrix short enough to maintain. It should explain responsibilities and expose gaps, not become a catalogue of every button in the admin interface. Review it with the staff who will actually perform the work before implementation.
Check what the chosen platform supports
Do not assume that a role name means the same thing across systems. Ask the developer to demonstrate the proposed role against your task list. Confirm any dependencies, plan restrictions and features that require custom development before approving the scope.
For example, Shopify's store-permission documentation groups permissions by store function and explains that related tasks can require additional permissions. It also describes limits to narrowing access within a store. Review the current documentation for your platform instead of promising that any arbitrary boundary can be configured.
For a custom build, include access requirements in the development brief. A hidden button is not enough to establish that a restricted action is protected. Ask the developer how the server checks authority and how changes to staff access take effect. Have those controls reviewed as part of the agreed implementation and testing work.
Keep payment approval separate from packing work
Document who may inspect payment status, who can request a refund and who can approve a financial adjustment. Do not treat these as one generic order-management permission. The appropriate separation depends on the store and platform, but the business should understand the arrangement it is accepting.
Specify that a customer's claim of payment is a question for verification, not a reason for warehouse staff to mark an order paid. Ask your developer to explain the actual payment confirmation flow and how staff deal with delayed or unmatched payments. Record where unresolved cases are reviewed.
Also decide who may change payment integration settings. The person who processes daily orders does not necessarily need access to provider credentials or payout configuration. Keep credentials out of the planning worksheet and ordinary support messages. Use the approved access-management process for technical work.
Limit customer information to the task
Identify which customer details each workflow requires. Dispatch staff may need delivery contact information for a particular order, while a catalogue editor may need no customer information at all. Request the appropriate separation instead of defaulting to a full customer database for every account.
Consider exports, not only individual screens. A user who can download a large file may have broader practical access than the visible dashboard suggests. Agree who can export records, why the export is needed and how staff should handle the resulting file. Avoid using real customer data in training screenshots.
Prepare demonstrations with fictional records in an isolated environment. Show the team the workflow without exposing unrelated customer information. This also makes it easier to repeat training when a new employee joins. Keep any legal or retention requirements as a separate reviewed business requirement rather than guessing them from a software setting.
Design the daily handoff between staff
A permission structure should support a clear order handoff. Decide how the packing team knows an order is ready, how support can see a dispatch update and who resolves an item that is unavailable. Restricting access without defining the handoff can leave each team waiting for information it cannot obtain.
Use status labels with agreed meanings. A label such as ready should state ready for what: payment review, packing, collection or dispatch. Do not use a single status to imply all those steps have been completed. Ask the developer to explain whether a change also sends a customer notification.
If your store handles multiple pickup or delivery arrangements, include those in the brief. The delivery-zone planning guide covers the customer-facing delivery decisions. Your staff-access worksheet should identify who maintains those rules and who can approve an exception.
Plan staff changes and temporary support
Record who creates staff accounts, approves a role change and removes access when responsibilities end. The process should cover temporary help and external developers as well as permanent employees. Set a review point for temporary access instead of allowing it to become an unexplained long-term arrangement.
Keep account ownership with an authorised business representative. Ask how the business can recover access and which recovery details must stay current. Do not put passwords in a shared document to solve continuity. Document the responsible person and the approved recovery procedure instead.
When a provider finishes a task, check that the agreed work is delivered and review the access still required. Preserve the business's legitimate administrative access throughout a handover. Removing an account without knowing what it controls can interrupt useful integrations or ongoing support.
Test permissions with realistic scenarios
Prepare both allowed and forbidden scenarios. A catalogue editor should complete the agreed product change, and should be prevented from completing an unrelated restricted task. A fulfilment user should see enough information to prepare an order without receiving unnecessary control over finance or system settings.
Ask for the results in plain language. Record the role, task, expected result, observed result and unresolved issue. Include the case where a user's role changes or access is removed. Confirm that the test covers the actual server behaviour, not only whether a menu item disappears.
Use sandbox payments and isolated records where needed. Do not submit unapproved production orders or customer messages merely to demonstrate a role. Existing stores should agree a controlled validation plan with their provider before any test that could affect real fulfilment or accounting.
Frequently asked questions
Is a shared owner login acceptable for a small team?
Individual access makes responsibility clearer and allows changes when a person's duties change. Ask your provider what the selected platform supports and plan practical account ownership rather than sharing the most powerful login for convenience.
Can a role be restricted to one product or order?
That depends on the platform and implementation. Demonstrate the exact requirement before assuming it is available. A general product-editing role may be broader than the business expects.
Does a smaller permission list always make the workflow better?
No. Staff still need to complete their assigned work. Combine appropriate boundaries with approval routes, training and clear handoffs so employees are not encouraged to work around the controls.
What should we include in the development enquiry?
Send the staff task list, proposed approval responsibilities, existing platform and any workflows that currently require shared access. Use the store development enquiry to discuss the scope. For the wider website relationship, the handover checklist helps identify ownership and support responsibilities.
