Buy a development project for defined changes that can be tested and handed over; buy ongoing operations when someone must perform recurring actions. Redesigning a Salla storefront does not automatically resolve late fulfilment, stale quantities or unanswered delivery enquiries. You may need both, but their responsibilities should be explicit.
“I need someone to handle the store” combines different kinds of work. Before sending that request to suppliers, observe a normal working week and list actual tasks rather than job labels. This makes Salla store launch and rebuild proposals comparable and prevents daily operational staffing from being assumed inside a bounded build.
Separate an output from a recurring responsibility
A project produces an outcome that can be accepted: configured categories, an approved theme, an agreed product upload, a tested purchase journey and staff handover. Operations involve repeated action as orders and circumstances change: reviewing quantities, packing a box, following up a carrier or implementing an approved return decision. Providing a button does not mean the implementer will press it for the merchant every day.
Marketing is a third category, including community content and customer-message logic. It may be project-based or recurring depending on the agreement. Avoid grouping everything under “maintenance.” Technical configuration, customer complaints and content campaigns require different skills, permissions and approvals.
Salla's guide separates receiving, preparing and handing an order to the carrier. Assigning those stages to your team is part of defining operations. Salla order-management stages.
Worked hypothetical example: 18 requested tasks
The numbers illustrate classification; they are not a service package or universal allocation. A merchant submits 18 tasks. The team separates them into three groups of six:
| Bounded implementation | Recurring internal operations | Separately scoped marketing |
|---|---|---|
| Configure the approved theme | Update inventory quantities | Prepare a content calendar |
| Load the product sample | Pick and pack orders | Produce social content |
| Organise categories | Hand shipments to the carrier | Apply community response rules |
| Configure shipping rules | Follow up returns | Map lifecycle-message logic |
| Test payment methods | Answer order-specific questions | Test message triggers |
| Conduct staff handover | Approve new prices | Review follow-up handoffs |
Classification does not mean one supplier provides every item. Operations may remain internal, implementation may be contracted, and specific marketing work may be commissioned separately. The merchant needs a named owner, execution frequency and authority for every task, not a broad label concealing responsibility gaps.
In this example, slow packing does not initially call for a new theme. The owner first needs to establish who receives the order, verifies its status and prepares it, and what prevents timely action. If the investigation finds that the employee cannot see the selected variant, that becomes a specific implementation defect. Physical fulfilment remains an operational responsibility.
Turn complaints into acceptably scoped changes
When employees say the store is difficult, ask for the task, step and evidence. Does adding a product require repeated formatting? Can the employee not locate the ordered colour? Does supplier information arrive incomplete? These could call for configuration or training, journey investigation, or a better data-intake process respectively.
Product discovery and requirements connects the complaint with an action and acceptance criterion. For example: “The employee can retrieve the ordered variant from the test order without consulting a separate message.” That is testable. “Improve store management” allows each party to imagine a different deliverable.
Include the frequency and consequence of the problem. A rare inconvenience may not justify a large rebuild, while a small recurring error in fulfilment may deserve immediate attention. Use actual observations supplied by the merchant rather than assuming that a modern-looking design will solve the most important issue.
Define the boundaries of marketing services
Social content and community management concerns platform-appropriate content and response and escalation rules. Do not assume it includes every shipment enquiry or authority to approve refunds. Define when the team can provide an approved answer and when it must refer the case to an operational decision-maker.
Marketing automation and lifecycle journeys connects approved data, consent, message logic and handoffs. Setting up a reminder does not remove the need for someone to handle replies, and automation does not correct inaccurate records. Give each journey an owner and route operational exceptions to someone who can act rather than send additional messages about an unprepared order.
A mixed inbox can make these boundaries difficult to see. Agree how a public product question, a private order complaint and a change request move between the people responsible. The goal is continuity for the customer without silently expanding anyone's authority.
What belongs in each agreement?
For development, list pages, features, required inputs, acceptance criteria, approvers and blocking dependencies. Define included revisions and the route for new change requests. For recurring work, list tasks, frequency, volume boundaries, monitoring hours and escalation. Do not assume around-the-clock coverage.
Keep a simple responsibility matrix: task, executor, decision-maker, required information and evidence of completion. One person may hold several roles, but the decision-maker column should not be empty. If a customer response requires a commercial exception or monetary approval, identify the authorised owner before service begins.
Agree what happens during absences and unresolved dependencies. If stock approval has not arrived, should the operator pause publication, escalate, or proceed using a specifically approved fallback? An explicit rule is more useful than blaming the supplier later for an assumption nobody documented.
When should a project and ongoing work be combined?
A staged arrangement can make sense when there is a defined implementation problem and an operating team that needs knowledge transfer: diagnose and change, test and hand over, then start an explicitly agreed support service if necessary. The final stage should not be automatic or vague.
State when the project ends, when recurring work begins and what remains with the merchant in both phases. Avoid ambiguous bundles of “change requests,” treating a supplier's employee as a permanent warehouse replacement, or measuring every operational task solely by sales. Sales depend on many factors; operational acceptance needs evidence that the agreed action was performed correctly within its boundaries.
Frequently asked questions
Does Salla development include daily customer replies?
Not by default. Building or refreshing a store is project work. Any continuing responsibility needs explicit tasks, access and a separate agreement.
Will redesign solve weak sales?
It may address a documented obstacle, but it does not establish that the offer, inventory, operations or marketing are sound. Identify the problem before selecting the purchase.
Must one provider do everything?
No. Clear boundaries and information handoffs matter more. Internal operations combined with specialist implementation can be easier to control.
What signals a vague proposal?
Phrases such as “complete management” without a task list, volume boundaries, approval responsibilities or exception rules. Ask for concrete inclusions and exclusions.
A useful next step
List the tasks that genuinely recur in your store. Separate changes that finish at acceptance from work that remains daily, then request distinct scopes or one proposal that clearly separates them.
Source
Reviewed 26 October 2026: Salla order-management stages. Work boundaries depend on the approved task list; this comparison does not imply that LAB provides daily store operations.
