A Salla handover is complete when the merchant controls the accounts and decisions, employees can perform the agreed tasks, and unresolved boundaries are explicit. A public URL or a video tour of the storefront does not prove this. Request an ownership register, a concise operating guide and a task demonstration performed by the receiving employee.
Agree these deliverables when commissioning Salla store development, not on delivery day. Transferring subscriptions or recovering access may involve dependencies outside the implementer's control. If verification goes to an unavailable person's phone, another shared password does not resolve the ownership problem.
Access is not the same as control
An employee may open the dashboard without controlling recovery or renewal. For each dependency, record the owner, responsible employee, access route, recovery route, renewal date and payer. Do not put passwords or recovery codes into a broadly circulated handover document.
Inventory the Salla account, domain, paid themes and apps, payment and shipping providers, and any in-scope measurement accounts. Control of one does not automatically establish control of the others. Resolve personal-versus-business ownership through each provider's supported process.
Salla documents account details, two-factor authentication and registered devices. Use official owner-controlled routes to verify access and recovery rather than preserving a permanent dependency on the implementer's device. Salla account management.
Request a settings and dependency register
| Deliverable | What it should explain | Sign of incomplete handover |
|---|---|---|
| App register | Purpose, fees and owner for each app | Nobody knows why an app is installed |
| Selling configuration | Approved pricing, options and publication rules | Provisional values remain |
| Payment and shipping | Provider, activation state and known limits | Logos without test evidence |
| Customisation notes | What changed, where and how to retest | Undocumented code |
| Test results | Scenarios, outcomes and unresolved items | A generic “the store works” statement |
| Support routes | Issue types and escalation ownership | Suppliers referring issues to each other |
Do not request a screenshot of every dashboard screen merely to create a large document. Focus on settings employees will change, operational dependencies and decisions the interface cannot explain. Why is a region excluded from delivery? Who approves a changed promotion threshold? Those answers prevent a new employee from “fixing” an intentional configuration.
Keep an accurate list of external commitments. Renewal charges, provider response terms and app support are not automatically controlled by the developer. A useful register distinguishes confirmed terms from decisions still waiting on a supplier.
Test training through employee action
Define training around roles. Product staff may need to update descriptions, options and quantities; order staff need to identify the right record, interpret its status and follow the approved process. Do not grant broad permissions simply because one shared training session is easier.
Use demonstration followed by execution. The implementer explains a task, then the employee performs it on an appropriate test record and explains how they verified the result. Provide a short written reference. Watching an hour-long recording does not establish that someone can confidently perform a task a month later.
Operating instructions and help text can be scoped through content strategy and production. The guide should reflect the approved store configuration and actual roles, not generic copied directions telling everyone to use the owner's account. Agree an editable format and an owner for future changes.
Worked hypothetical example: a handover session
This scenario is illustrative, not a claim about a previous client delivery. A homeware merchant attends with one product employee and one order employee. Before the session, the owner confirms account and recovery access through the official process, without deliberately risking an account lockout.
The product employee changes a test description, attaches an approved image and adjusts a quantity, then checks the customer-facing result. The order employee opens a test order, identifies the required variant, address and state, and explains what to do when payment remains incomplete. No real shipment or financial action is created merely to finish training.
The session reveals that an important notification still goes to the implementer's email. The team records a handover blocker for that workflow, corrects the destination with owner approval and retests it. A promise to forward messages manually is not treated as completed transfer. Temporary implementation access is then reviewed, leaving only what the agreed support scope requires.
The acceptance record includes which employee performed each task and what help remained necessary. If a role still cannot complete its essential work, schedule the missing instruction rather than labelling attendance as successful training.
Distinguish defects from new changes
Specify any agreed defect-remediation period, how issues are reported and the evidence required. Differentiate an accepted function that stops working from a new commercial rule that was never part of the build. A problem inside an external provider is not automatically a commitment to repair that provider's system; define the implementer's diagnostic and escalation role.
Handover also does not mean daily store operation on the merchant's behalf. Fulfilment, inventory counting, delivery enquiries and returns need explicit operational owners. Ongoing maintenance, marketing and support are separate scopes requiring agreement, not assumed inclusions in store construction.
Make the acceptance record useful
Ask software quality assurance to connect tasks with outcomes and list launch blockers and accepted differences. Record who approved product information, who completed operating tasks, which dependencies were verified and who owns each deferred item.
Do not let a signature conceal undisclosed failures. If a material issue remains, use a clearly bounded conditional acceptance or defer closure according to the agreement. Both parties need to know what is genuinely complete rather than depend on unwritten assistance after a nominally final delivery.
Frequently asked questions
Is the owner's password sufficient?
No. Ownership, recovery, renewal and connected dependencies must also be established, with appropriate role access. A shared password can conceal weak control rather than resolve it.
Should developer access be removed immediately?
Review the actual need after acceptance. Retain only approved access for defined support and revoke unnecessary access through the supported process without accidentally disabling an active dependency.
Must the operating guide be long?
No. It should cover important tasks and decisions using the real configuration. Useful brevity is better than dozens of unexplained screenshots.
Who updates the guide later?
Name someone inside the business or within an explicit maintenance agreement. Instructions that do not evolve with the operation can become a source of errors.
A useful next step
Identify the people responsible for products, orders and accounts. Request a handover plan that tests their tasks and clarifies ownership, support and unresolved work before launch.
Source
Reviewed 26 October 2026: Salla account management.