Shopify POS setup & migration scope template (for agencies)
POS projects don’t fail because someone forgot a setting.
They fail because the scope didn’t define:
- who sources and configures hardware
- what happens when internet drops (offline mode expectations)
- how inventory sync behaves across locations
- how staff permissions are managed
- what “go-live” support actually includes
POS is operational. Your scope needs to be operational too.
Below is a copy/paste Shopify POS scope template you can use in Google Docs.
If you want it to assemble itself from inputs (locations, hardware mix, sync model, payment methods), RuleDox can generate a near-complete POS scope draft inside Google Docs.
Assemble a POS scope in Google Docs → https://ruledox.app/live-demo
Who this template is for
- Shopify agencies implementing Shopify POS for retail stores
- Teams migrating from legacy POS to Shopify POS
- Multi-location retailers with inventory complexity and staff roles
Who it’s not for
- Single iPad “basic POS” setups with no inventory/process complexity (still worth scoping, but smaller)
TL;DR (POS scoping anchors)
A POS scope should define:
- locations/registers
- staff roles/permissions
- hardware list + sourcing responsibility
- inventory sync model
- payment/tender types
- offline expectations
- training + go-live plan
- support window and escalation path
How to use: Copy this section into your scope doc. Delete what you don’t offer. Replace bracketed fields.
1) Project overview
Client: [Client name]
Project: Shopify POS setup / migration
Locations: [# of locations]
Registers per location: [#]
Objective: [e.g., unify in-store and online inventory and enable staff to sell/return across channels]
2) Locations and registers
Define what is being configured:
- Location list: [Location A, Location B]
- Register count per location: [X]
- Special setups: [pop-up/event, warehouse pickup, etc.]
3) Staff roles and permissions
Define role model:
- Roles: [cashier, supervisor, manager, admin]
- Permission differences: refunds, discounts, returns, inventory adjustments
Deliverables:
- roles configured
- initial staff onboarding guidance
4) Hardware requirements
Hardware must be explicit.
Hardware in scope (by location/register):
- POS terminal/iPad model
- card reader model
- barcode scanner
- receipt printer
- cash drawer
Sourcing responsibility:
- Hardware purchased by: [client/agency]
- Lead time assumptions: [X]
Deliverables:
- hardware compatibility confirmed
- setup checklist provided
5) Catalog and inventory sync rules
Inventory issues are the #1 hidden risk.
Define:
- inventory sync model: [shared pool / per-location pools]
- stock transfers: [in scope/out of scope]
- oversell/backorder behavior: [defined]
- returns/exchanges rules: [defined]
6) Taxes and payment methods
- Payment methods: [card, cash, split payments, custom tenders]
- Tax handling approach: [client provides rules; agency configures]
7) Offline mode expectations
Define what must work offline:
- can staff take payments offline? [yes/no]
- can they create orders? [yes/no]
- how are offline transactions reconciled?
8) Workflows to validate (end-to-end)
List the workflows that must work:
- sale (cash/card)
- refund (full/partial)
- exchange
- discount application
- inventory adjustment
- buy online pick up in store (if applicable)
9) Training plan
Define who is trained and how:
- training session(s): [duration]
- staff groups: [cashiers/managers]
- training artifacts: [SOPs, cheat sheets]
10) Go-live plan
Define launch window:
- go-live date range
- cutover steps (if migrating from another POS)
- freeze window and responsibilities
11) Support window
- support window post go-live: [e.g., 3–5 business days]
- escalation path (agency → Shopify support → hardware vendor)
12) Out of scope (exclusions)
Unless explicitly listed:
- sourcing and logistics of hardware (if client-owned)
- complex custom reporting and BI builds
- custom POS app development
- deep accounting/ERP implementations
- operational process redesign (consulting)
13) Assumptions
- client provides store staff availability for training
- client provides network/Wi-Fi readiness
- client provides approvals within [X] business days
14) Change request triggers
A change request is triggered by:
- adding new locations/registers
- changing inventory sync model mid-project
- additional payment methods/hardware not listed
- new workflows (BOPIS, ship-from-store) introduced mid-scope
Variables (inputs) that change POS scope
- Locations (single vs multi)
- Registers per location
- Hardware mix
- Inventory model (shared vs per location)
- Payment methods (cash, split, custom tenders)
- Offline tolerance
- Workflow complexity (returns/exchanges/BOPIS)
- Training needs (staff count + turnover)
Common POS scoping mistakes
1) Hardware is treated as “we’ll figure it out”
Fix: list hardware models and who owns procurement.
2) Offline behavior is ignored
Fix: define what must work offline and how reconciliation happens.
3) Inventory sync rules aren’t explicit
Fix: decide shared vs per-location pools and define transfers/returns.
4) Training is assumed
Fix: define training deliverables and staff groups.
How RuleDox helps
POS scopes depend on a few variables (locations, registers, hardware, inventory model). RuleDox can assemble the correct scope sections and exclusions from those inputs inside Google Docs.
Assemble a POS scope in Google Docs → https://ruledox.app/live-demo
Related templates
- Migration scope: https://ruledox.app/content/shopify/shopify-migration-scope-of-work
- App integrations scope: https://ruledox.app/content/shopify/shopify-app-integration-scope
- Store build scope: https://ruledox.app/content/shopify/shopify-store-build-scope-of-work
FAQ
Is Shopify POS scope mostly about software configuration?
No. It’s about operational workflows, responsibilities, hardware, and training.
Should POS be scoped separately from a store build?
Often yes. POS has different risks, stakeholders, and acceptance tests than the storefront.