# SlickCell Pro > Repair shop software and POS for phone and device repair shops: repair tickets, a till, IMEI-level device stock, the VAT margin scheme, trade-ins and supplier ordering in one system, hosted in London. SlickCell Pro (from SlickCell, slickcell.com) is web-based repair shop management software for shops that repair, buy and sell phones, tablets, computers and other devices. It is priced in pounds, built around UK VAT including the second-hand margin scheme, and its database is hosted in London. It runs in any modern browser on a computer, tablet or phone, with nothing to install. SlickCell Pro is not connected with Slickcall, the international calling app. ## At a glance - Web app for repair shops: repair tickets, POS, invoices, parts and device stock, trade-ins, purchase orders, supplier network, staff, reports. - Every handset tracked as its own unit with its own IMEI, cost, condition and margin. - UK VAT built in, including the second-hand margin scheme; tax rules are configurable for any country. - Database hosted in London on every plan. - From £39/month excluding VAT. Every feature on every plan. - 14-day free trial, started online: no card, no sales call. Sign up: https://pro.slickcell.com/pricing ## Why shops choose SlickCell Pro - **Every handset is its own record**: One phone is one unit with its own IMEI or serial, cost, condition, battery health, selling price, supplier and history. Quantity is counted from the units, never typed, so you see the exact profit on the exact phone you sold. (https://pro.slickcell.com/features/inventory) - **The VAT margin scheme, per item**: Second-hand stock can be taxed on the margin between what you paid for that unit and what you sold it for, reported separately from standard-rated sales. Because every handset carries its own purchase cost, the per-item record the margin scheme asks for is already there. (https://pro.slickcell.com/features/used-devices) - **Repairs where the money adds up**: A deposit is taken against the job, parts are committed from stock, extra work is quoted before the price changes, a part payment leaves a real balance, and a paid invoice is locked. The ticket, the till, the invoice and the report all agree. (https://pro.slickcell.com/features/repairs) - **Trade-ins as a tracked purchase**: Inspect, approve, pay the seller by cash, bank transfer or credit against a sale, and the handset enters stock as its own unit with its real acquisition cost. (https://pro.slickcell.com/features/buyback) - **Customers kept up to date by email and QR**: Email a customer from the job on a template. Every receipt and repair label carries a QR code that opens a live tracking page, with no app and no login. (https://pro.slickcell.com/features/customer-tracking) - **Any staff phone is a barcode scanner**: Pair a phone to the till from a QR code on screen and every scan lands in the open sale. No app, no hardware to buy. (https://pro.slickcell.com/features/mobile-scanning) - **Suppliers connected inside the system**: A purchase order lands directly in a connected supplier's own account; they confirm or re-quote, reserve and dispatch, and you book in what actually arrived. (https://pro.slickcell.com/features/supplier-network) - **Hosted in London, sealed per shop**: The database runs in London on every plan, encrypted in transit and at rest, with row-level security on every table, two-factor sign-in, database-enforced roles and an append-only audit trail. (https://pro.slickcell.com/security) - **Every feature on every plan**: From £39 a month excluding VAT, in pounds, with a fourteen-day free trial you start yourself: no card and no sales call. No per-transaction fees, and you keep the card machine you already have. (https://pro.slickcell.com/pricing) ## Plans - Starter: £39/month or £390/year, excluding VAT. One location, everything you need to open up and trade. - Professional: £59/month or £590/year, excluding VAT. Multiple locations, discount rules and priority processing. - Supplier Pro: £99/month or £990/year, excluding VAT. Adds Supplier Operations: sell to other shops from your own catalogue. - Enterprise: price on application. Tailored to your organisation. Every SlickCell Pro feature is included on every plan: plans differ by team size, locations, discounts and support. Start the trial yourself: no sales call, no card, and nobody has to ring you back before you can look at it. Full detail: https://pro.slickcell.com/pricing ## Security - **Hosted in London, on every plan**: Your shop's database runs in a London data centre (AWS eu-west-2). That is the same on Starter as on Enterprise: UK data residency is not an upgrade you have to ask for. - **Encrypted in transit and at rest**: Every connection to SlickCell Pro is encrypted with TLS, and the database is encrypted at rest with AES-256. That covers the app, the till, the phone scanner and the customer tracking page. - **Every shop sealed off from every other**: Row-level security is switched on for every table in the database. Each query is checked against the shop you belong to by the database itself, so another shop's records cannot be reached from the app, from the API or by a changed link. The rule is covered by automated database tests. - **Roles enforced by the database**: Owner, manager, technician, sales and accountant each see and change only what the role allows. The rule lives in the database, not just in hidden buttons, so a permission cannot be sidestepped from outside the screen. - **Money-moving actions limited**: Voids and write-offs are limited to owners and managers. Editing a sold unit or handing a device over unpaid asks for a reason, and the reason is kept with the record. - **Two-factor sign-in**: Every account can add an authenticator app, so a stolen password alone does not open the shop. Switching it off needs both the password and a current code. - **Customer unlock codes kept apart**: Device passcodes are stored separately from the customer record and are revealed only to the roles that work on the device. Every reveal is logged with who looked and when. - **Automatic sign-out**: A till left open signs itself out after the period of inactivity you choose, with a warning first. - **Append-only audit trail**: Changes to repairs, stock, customers, invoices and payments are written to an audit trail with who made them and when. Entries are added, never edited, and only owners and managers can read them. - **Paid invoices cannot be rewritten**: Once an invoice is settled it is locked. A refund or correction is a new entry that points at the original, so the history your accountant reads is the history that happened. - **Deleted records can be restored**: Deleting a record moves it to the bin first, where it can be brought back. Nothing important disappears because of one wrong click. - **Export whenever you like**: Repairs, stock, payments, profit and loss, tax and payroll reports export to CSV at any time, from the screen you are already on. Your records are yours to take to your accountant, or anywhere else. - **We never store a card number**: Your subscription is paid on Stripe's own secure pages, and Stripe is certified to PCI DSS Level 1. At the till, card takings are recorded by amount and method on the sale, so no customer card data ever passes through SlickCell Pro. - **Monitored around the clock**: Errors in the app and on the server are reported to us the moment they happen, with customer personal data stripped out before the report is sent. Full detail: https://pro.slickcell.com/security ## Modules - [Repairs](https://pro.slickcell.com/features/repairs): Repair detail spread across paper, WhatsApp and memory. - [POS & Sales](https://pro.slickcell.com/features/pos): A till that was never built for repairs or used handsets. - [Invoicing & payments](https://pro.slickcell.com/features/invoicing): Part payments treated as paid, or absorbed as discount. - [Customers](https://pro.slickcell.com/features/customers): No history when a customer returns with the same device. - [Customer updates](https://pro.slickcell.com/features/customer-tracking): Ringing round to say a repair is ready. - [Reviews](https://pro.slickcell.com/features/customer-tracking): No idea which jobs left the customer happy. - [Inventory & device units](https://pro.slickcell.com/features/inventory): Stock that does not match what is actually on the shelf. - [Used devices & margin tax](https://pro.slickcell.com/features/used-devices): Second-hand VAT worked out by hand, job by job. - [Trade-in & buyback](https://pro.slickcell.com/features/buyback): Trade-ins settled off the books and never reconciled. - [Mobile scanning](https://pro.slickcell.com/features/mobile-scanning): A scanner for every till, or no scanner at all. - [Purchase orders & receiving](https://pro.slickcell.com/features/procurement): Supplier orders living in messages and spreadsheets. - [Returns to supplier](https://pro.slickcell.com/help/returns-and-faulty-items): Faulty stock going back on the shelf because nowhere else holds it. - [Supplier network](https://pro.slickcell.com/features/supplier-network): Re-keying the same order into a supplier's system by hand. - [Reports & tax](https://pro.slickcell.com/features/reports): The invoice and the report showing different totals. - [Workforce](https://pro.slickcell.com/features/workforce): Staff access too broad, and hours kept on a wall chart. - [Multi-branch](https://pro.slickcell.com/features/multi-branch): Each branch keeping its own numbers, in its own way. - [Cash drawer](https://pro.slickcell.com/features/cash-control): The drawer and the day's takings never quite agreeing. - [Stocktake](https://pro.slickcell.com/help/run-a-stocktake): A count that overwrites the system with whatever was typed. ## Compared with other repair shop software - [SlickCell Pro vs RepairDesk](https://pro.slickcell.com/compare/slickcell-pro-vs-repairdesk): £39 a month in pounds with every feature included, against US-dollar per-store pricing with add-ons marked paid on the entry plan; a trial you start yourself against a Request a Demo form; a database hosted in London. - [SlickCell Pro vs RepairShopr](https://pro.slickcell.com/compare/slickcell-pro-vs-repairshopr): £39 a month in pounds with no monthly ticket limit and three users, against a US-dollar Starter plan limited to 75 tickets and invoices a month and one user; a database hosted in London. ## Common questions **What is SlickCell Pro?** Repair shop management software and POS for phone and device repair shops. It runs repair tickets, the till, invoices, IMEI-level device stock, parts, trade-ins, supplier purchasing, staff and reports in one web app, hosted in London. **How much does SlickCell Pro cost?** Starter is £39 a month, Professional £59 and Supplier Pro £99, all excluding VAT, or ten times the monthly price for a year. Every feature is on every plan; plans differ by team size, locations, discount rules and support. Every plan starts with a fourteen-day free trial with no card. **Is SlickCell Pro a good choice for a new phone repair shop in the UK?** Yes. It is priced in pounds from £39 a month, handles UK VAT including the margin scheme on second-hand phones, keeps its data in London, and tracks every handset you buy or trade in as its own unit with its own cost. You can start the trial yourself tonight, with no card and no sales call. **Does SlickCell Pro support the VAT margin scheme for used phones?** Yes. Tax is a rule you configure, and margin is one of the rule types, scoped to used stock. Each handset carries its own purchase cost, so the margin on every sale is worked out from that unit, and margin-taxed sales are reported separately from standard-rated ones. **Does SlickCell Pro track IMEI numbers?** Yes. Every handset is its own record with its own IMEI or serial, cost, condition, battery health, selling price and supplier. IMEIs are free text, so a partial or unusual reference from older stock is accepted. **Where is SlickCell Pro data hosted, and is it secure?** In London, on every plan. The database is encrypted in transit and at rest, every shop is sealed off by row-level security on every table, staff roles are enforced by the database, two-factor sign-in is available on every account, and changes are written to an append-only audit trail. **How do customers get repair updates?** By email from the job, on templates each shop can edit. Every receipt and repair label also carries a QR code that opens a live tracking page, with no app and no login. **Does SlickCell Pro work with my card machine?** Yes, with the one you already have. Take the payment on your terminal and the till records it on the sale, split with cash if needed. SlickCell Pro takes no cut of your card takings. **How do I get my figures to my accountant?** Export them. Profit and loss, VAT including the margin scheme, payments, the account ledger, stock and payroll export to CSV from the report you are reading. **Can I move to SlickCell Pro from another system?** Yes. Parts, accessories and devices import from CSV with a preview of exactly what will be written before anything is saved. Most shops finish open repairs on the old system and start new work in SlickCell Pro from go-live. ## Who it is for - [For phone repair shops](https://pro.slickcell.com/for/phone-repair-shops) - [For phone shops](https://pro.slickcell.com/for/phone-shops) - [For computer repair shops](https://pro.slickcell.com/for/computer-repair-shops) - [For parts suppliers and wholesalers](https://pro.slickcell.com/for/suppliers) ## Feature pages - [Repairs](https://pro.slickcell.com/features/repairs) - [POS & sales](https://pro.slickcell.com/features/pos) - [Invoicing & payments](https://pro.slickcell.com/features/invoicing) - [Inventory & device units](https://pro.slickcell.com/features/inventory) - [Used devices & the margin scheme](https://pro.slickcell.com/features/used-devices) - [Trade-in & buyback](https://pro.slickcell.com/features/buyback) - [Customers](https://pro.slickcell.com/features/customers) - [Customer tracking & reviews](https://pro.slickcell.com/features/customer-tracking) - [Phone as a barcode scanner](https://pro.slickcell.com/features/mobile-scanning) - [Purchase orders & receiving](https://pro.slickcell.com/features/procurement) - [Supplier network](https://pro.slickcell.com/features/supplier-network) - [Reports & tax](https://pro.slickcell.com/features/reports) - [Cash drawer & cashbook](https://pro.slickcell.com/features/cash-control) - [Workforce](https://pro.slickcell.com/features/workforce) - [Multi-branch](https://pro.slickcell.com/features/multi-branch) ## Buying and switching - [Pricing](https://pro.slickcell.com/pricing) - [Security](https://pro.slickcell.com/security) - [Integrations](https://pro.slickcell.com/integrations) - [Moving from another system](https://pro.slickcell.com/migration) - [About](https://pro.slickcell.com/about) - [Partner programme](https://pro.slickcell.com/partners) - [VAT margin scheme calculator (free)](https://pro.slickcell.com/tools/vat-margin-calculator) - [SlickCell Pro vs RepairDesk](https://pro.slickcell.com/compare/slickcell-pro-vs-repairdesk) - [SlickCell Pro vs RepairShopr](https://pro.slickcell.com/compare/slickcell-pro-vs-repairshopr) - [Book a demo](https://pro.slickcell.com/demo) - [Contact](https://pro.slickcell.com/contact) ## Guides - [“Where is my phone?” The call you can stop taking](https://pro.slickcell.com/blog/where-is-my-phone): The commonest question a repair shop is asked has the same answer every time, and a person has to find it first. It does not have to be a person. - [Ordering from a supplier who is already in the system](https://pro.slickcell.com/blog/ordering-from-a-connected-supplier): Every purchase order gets typed twice: once by you, once by them. Everything that goes wrong afterwards starts with that second typing. - [Your staff already carry a barcode scanner](https://pro.slickcell.com/blog/staff-already-carry-a-scanner): The second till never gets a scanner, because a scanner is eighty pounds you have not spent. Everyone behind the counter is already holding one. - [Who is allowed to give a discount?](https://pro.slickcell.com/blog/who-can-give-a-discount): Most shops answer that question with trust. Trust is not a control, and the difference shows up in the month's margin, not on the day it happens. - [Counting stock without closing the shop](https://pro.slickcell.com/blog/counting-stock-without-closing): A stocktake fails for boring reasons: it takes a day you don't have, and the till keeps selling while you count. Both are solvable. - [Getting the VAT margin scheme right on used devices](https://pro.slickcell.com/blog/vat-margin-scheme-used-devices): A plain-English walk-through of margin VAT for second-hand phones: what it taxes, why it is one sixth and not 20%, and the mistakes that cost shops the scheme. - [Why IMEI-level stock beats a quantity count](https://pro.slickcell.com/blog/imei-level-stock): Tracking each handset as its own record changes what you can see, sell and trust on the shelf, and it is the only way per-item margin VAT ever adds up. - [Purchase orders, receiving, and the gap in between](https://pro.slickcell.com/blog/purchase-orders-and-receiving): Why booking stock in against the order you raised is what stops a short delivery quietly becoming your problem, and your loss. ## Help centre 25 step-by-step articles on the real screens: https://pro.slickcell.com/help - [Add a handset to stock](https://pro.slickcell.com/help/add-a-device-unit-by-imei) - [Answer an order from a shop](https://pro.slickcell.com/help/answer-an-incoming-order) - [Set your account up as a supplier](https://pro.slickcell.com/help/become-a-supplier) - [Book a repair in](https://pro.slickcell.com/help/book-a-repair-in) - [Set your country, currency and tax rate](https://pro.slickcell.com/help/country-currency-and-tax) - [Devices, parts and accessories are not the same thing](https://pro.slickcell.com/help/devices-parts-and-accessories) - [Dispatch an order, and settle what follows](https://pro.slickcell.com/help/dispatch-and-settle) - [Hand the device back](https://pro.slickcell.com/help/hand-a-device-over) - [Invite staff and choose what they can do](https://pro.slickcell.com/help/invite-staff-and-set-roles) - [Jump to any screen with ⌘K](https://pro.slickcell.com/help/jump-to-any-screen) - [Read the profit and loss](https://pro.slickcell.com/help/profit-and-loss-report) - [Quote an order, revise it, and convert it](https://pro.slickcell.com/help/quote-revise-and-convert) - [Raise a purchase order](https://pro.slickcell.com/help/raise-a-purchase-order) - [Read paid, due and change on an invoice](https://pro.slickcell.com/help/read-paid-due-and-change-on-an-invoice) - [Receive stock against a purchase order](https://pro.slickcell.com/help/receive-stock-against-a-purchase-order) - [Refund a sale, and say where the goods went](https://pro.slickcell.com/help/refund-a-sale) - [Deal with returned and faulty stock](https://pro.slickcell.com/help/returns-and-faulty-items) - [Ring up a sale](https://pro.slickcell.com/help/ring-up-a-sale) - [What each role can do](https://pro.slickcell.com/help/roles-and-what-they-can-do) - [Run a stocktake](https://pro.slickcell.com/help/run-a-stocktake) - [Share a catalogue, and decide what buyers see](https://pro.slickcell.com/help/share-your-wholesale-catalogue) - [Start a free trial](https://pro.slickcell.com/help/start-a-free-trial) - [Take a deposit on a repair](https://pro.slickcell.com/help/take-a-deposit) - [Set up tax the way your shop charges it](https://pro.slickcell.com/help/tax-on-your-sales) - [Take a handset in part-exchange](https://pro.slickcell.com/help/trade-a-handset-in) ## Full reference Every page on this site in plain text: https://pro.slickcell.com/llms-full.txt --- # SlickCell Pro: every page, in full ## Home Source: https://pro.slickcell.com #### Run your repair shop the calm way Take payments, track every device by IMEI, manage repairs and reorder stock from your suppliers: all from one tidy counter-to-back-office platform. ##### Where repair shops lose time and money None of these are the shop's fault. They are what happens when the till, the repair notebook and the stock sheet do not talk to each other. - A paid repair is edited later, and the bill no longer matches what was taken. - A customer underpays and the difference quietly disappears. - A handset is sold without the right serial reference against it. - A part is used on a job but stock is never reduced. - The invoice and the report show different totals for the same week. - A supplier delivery does not match the order, and nobody catches it. ##### One repair, followed all the way through The same job from the counter to the ledger. Each step writes to the next, so nothing has to be re-entered and nothing changes silently. - **Repair booked**: Device, fault and customer captured against a ticket. - **Deposit taken**: Payment recorded against the job, balance tracked. - **Part reserved**: Stock is committed to the ticket, not just noted. - **Technician assigned**: The job joins a queue with an owner and a due time. - **Extra work quoted**: Added cost is quoted on the ticket before it reaches the bill. - **Final payment**: Balance settles across card, cash or store credit. - **Device handed over**: Handover closes the ticket and the stock movement. - **Invoice & warranty issued**: The document, the VAT and the report agree. Because those steps are joined, a part used reduces stock, the stock movement lands in cost of goods, and cost of goods lands in the profit and loss, and none of it can be changed silently. ##### What makes us different Purpose-built for the phone-repair trade: not a generic till bolted onto a spreadsheet. ##### Purchase orders & receiving Raise a purchase order, receive stock against it in full or in part, and keep supplier bills and returns with the order that created them. ##### IMEI-level device units Every handset is its own record: specs, cost, condition and history tracked per unit. ##### VAT margin scheme Second-hand margin VAT handled correctly, so your returns add up first time. ##### Multi-branch & trade-in credits Run several shops from one login, see every branch in one report, and settle trade-ins as store credit. ##### Everything the counter needs, in one place Every part of the shop on one set of records. Pick the part of the day you want to see. - **Repairs**: One ticket carries the device, the fault, the deposit, the parts committed to it and the handover. The money moves with the job because they are the same record. - **POS & sales**: Ring up a repair, an accessory by quantity and a handset by its IMEI on the same sale, then settle it across more than one method. - **Invoicing**: Each payment is recorded against the invoice it settles, so the balance is derived rather than typed, and a refund never quietly reopens a bill that was paid. - **Device units**: A handset is its own row with its own IMEI, condition, cost and price. Quantity is counted from the units on the shelf rather than typed into a box. - **Purchasing**: Receive against the order you raised. A short delivery is visible at the moment it is booked in, not when the bill arrives three weeks later. - **Reports & tax**: Revenue, profit and tax read from the same ledger the till writes to, and every figure can be opened to see the invoices underneath it. - **Workforce**: Roles decide who can discount, void, refund or see cost prices. Hours and technician load sit next to the tickets they belong to. - **Suppliers**: Your purchase order arrives as their incoming order: not an email they retype. They confirm or re-quote, you approve line by line, and stock is reserved until the dispatch is confirmed. - **Multi-branch**: Each branch keeps its own stock, staff and takings. The group view reads across them without merging anything, so a transfer is still a movement. ##### Watch the till do the work The two things worth seeing move rather than read about: a sale being rung up, and a phone standing in for a barcode scanner. ##### A till that speaks fluent repair shop Ring up repairs, accessories and second-hand devices, take split payments across card and cash, and print or email a receipt in seconds. ##### Turn any phone into a barcode scanner Show the QR on the till, scan it with a staff phone, and start scanning stock straight into the open sale. No scanner hardware, no app to install, and no login on the phone. ##### How to do it, on the real screens Short, numbered guides for the jobs a shop does every day. Each one is written against the app as it is, not as a promise of what it will do. ##### Book a repair in Create a repair ticket at the counter: customer, device, fault, price, an optional deposit and technician, then print the ticket for the customer. ##### Ring up a sale Put accessories, parts and a used handset on one sale, take the money across more than one method, and print the receipt. ##### Add a handset to stock Put a second-hand device on the shelf with its own IMEI, condition, cost and price, so it is priced as itself rather than as a model. #### A clear, uncluttered shop dashboard ##### Today at a glance Takings, open repairs and jobs due out: the moment you open up. ##### Numbers you can trust Every figure traces back to the record it came from: no second spreadsheet. ##### Jump to any screen ⌘K opens a finder for every page, tab and action: no hunting through a sidebar. ##### Ten one-click jobs A repair, a sale, a trade-in, a stocktake, and you only see the tiles your role can use. One handset is one record. Quantity is derived from units, never typed. Second-hand VAT is computed on the margin and kept off the invoice. Each shop keeps its own stock and staff under shared ownership. ##### Look at the paperwork, not a quote Three things you can inspect. If the documents are right, the system underneath is right. ##### A sale settled two ways Two payment lines on one checkout, with the total due and the amount collected side by side. The screen says paid in full only when the two meet: the case where money usually goes missing. ##### A device unit's record One handset as its own record: how many are on the shelf, its cost and sell price, the margin between them, and a movements tab for how it got there. Quantity is derived from units, never typed. ##### A report total, and its source Gross revenue, refunds, parts cost and gross profit on one screen, each line the one above it less the one between. The total is not a separate number; it is the same lines, added up in front of you. ##### What happens if something goes wrong Moving a shop onto new software is the real decision. These are the parts that make it reversible. - **Migration**: Bring parts, accessories and devices in from a spreadsheet, and preview exactly what the import will do before anything is written. - **Role permissions**: Staff see and change what their role allows: refunds, voids and price edits are gated. - **Audit trail**: Money and stock movements are recorded with who did what and when. - **Your country, your tax rules**: Pick your country and the currency follows. Tax is a rule you set (a rate, inclusive, exclusive or margin) scoped to devices, parts or accessories, and to new or used stock. - **Printing that matches**: Receipts, A4 invoices, tickets and shelf labels come off one template, so the PDF, the thermal roll and the printed page all say the same thing. - **A link the customer can check**: The QR on a ticket or invoice opens a status page for that job: no login, no account, and search engines are told not to index it. - **Support**: Email support on every plan, priority on Professional and above. Every SlickCell Pro feature is included on every plan: plans differ by team size, locations, discounts and support. ##### Four plans, one feature set Flat monthly pricing. Never per device, never per transaction. **Starter**: £39/month or £390/year, excluding VAT. One location, everything you need to open up and trade. - Every SlickCell Pro feature included - 3 app-access users - 5 employee profiles - Single location - Hosted in London - Manual one-off discounts - Standard email support **Professional**: £59/month or £590/year, excluding VAT. Multiple locations, discount rules and priority processing. - Every SlickCell Pro feature included - 10 app-access users per branch - 15 employee profiles per branch - Multiple locations - Discount rules, promo codes & automatic campaigns - Priority large-job processing - Custom domain - Priority email support - Additional branches £29.00/mo each **Supplier Pro**: £99/month or £990/year, excluding VAT. Adds Supplier Operations: sell to other shops from your own catalogue. - Every SlickCell Pro feature included - 15 app-access users per branch - 25 employee profiles per branch - Multiple locations - Supplier Operations included - Discount rules, promo codes & automatic campaigns - Priority large-job processing - Custom domain - Priority support - Additional locations £59.00/mo each **Enterprise**: price on application. Tailored to your organisation. - Every SlickCell Pro feature included - Unlimited app-access users - Unlimited employee profiles - Unlimited locations - Supplier Operations included - Discount rules, promo codes & automatic campaigns - Super-fast large-job processing - Custom domain - Separate dedicated database - Dedicated account manager - Priority or contractual support ##### Frequently asked questions The quick answers. Can't find yours? Talk to our team. **Is SlickCell Pro built specifically for phone-repair shops?** Yes. Repairs, IMEI-level device inventory and the VAT margin scheme are all first-class, not add-ons bolted onto a generic till. **Can I run more than one branch?** You can. Run several shops from one login, each with its own stock and staff, and see reports per branch or across the whole group. **How does device tracking work?** Every handset is its own unit with its own IMEI, cost, condition and history. Quantities are derived from those units, so your counts stay honest. **Do you take card payments?** Yes. Take card, cash or a split of both in one sale on the card machine you already have. SlickCell Pro records each payment on the sale and takes no cut of your takings, and receipts print or go by email. **Can I import my existing stock?** Yes: from a spreadsheet, with parts, accessories and devices imported separately. Prices go in as pounds and suppliers are selected by supplier ID. A device reference can be a full IMEI, a serial number, the last few digits or your own shop reference, and you preview what the import will do before anything is written. ##### Writing for the repair trade Practical reads on running a tidier, more profitable repair shop. ##### Getting the VAT margin scheme right on used devices ##### Why IMEI-level stock beats a quantity count ##### Purchase orders, receiving, and the gap in between --- ## All features Source: https://pro.slickcell.com/features #### The modules connect: that's the point Any system can list modules. What matters is whether a part used in the workshop reduces the stock on the shelf, lands in cost of goods, and shows up in the month's profit: without anyone retyping it. ##### One repair, followed all the way through The same job from the counter to the ledger. Each step writes to the next, so nothing has to be re-entered and nothing changes silently. - **Repair booked**: Device, fault and customer captured against a ticket. - **Deposit taken**: Payment recorded against the job, balance tracked. - **Part reserved**: Stock is committed to the ticket, not just noted. - **Technician assigned**: The job joins a queue with an owner and a due time. - **Extra work quoted**: Added cost is quoted on the ticket before it reaches the bill. - **Final payment**: Balance settles across card, cash or store credit. - **Device handed over**: Handover closes the ticket and the stock movement. - **Invoice & warranty issued**: The document, the VAT and the report agree. Because those steps are joined, a part used reduces stock, the stock movement lands in cost of goods, and cost of goods lands in the profit and loss, and none of it can be changed silently. #### Front of shop - **Repairs**: Repair detail spread across paper, WhatsApp and memory. - One ticket from intake through to handover - Parts committed to the job, not just noted - Status, technician and due time on every job - **POS & Sales**: A till that was never built for repairs or used handsets. - Repairs, accessories and devices on one sale - Split payments across card and cash - Receipts printed or sent by email - **Invoicing & payments**: Part payments treated as paid, or absorbed as discount. - Real paid, due and change status on every invoice - Refunds and credit notes as controlled flows - A settled invoice cannot be altered silently - **Customers**: No history when a customer returns with the same device. - Every repair, sale and payment against the customer - Devices linked to the person who owns them - Contact detail kept with the job, not in a phone - **Customer updates**: Ringing round to say a repair is ready. - Email a customer from the job, on a template - A live tracking page from the QR on their receipt - Every message kept against the customer record - **Reviews**: No idea which jobs left the customer happy. - Customers rate the job from the link on their receipt - Ratings roll up to the technician who did the work - Attribution is fixed when the review lands, not later #### Stock - **Inventory & device units**: Stock that does not match what is actually on the shelf. - Devices tracked one unit at a time, by IMEI or serial - Parts and accessories counted by quantity - Stock movements recorded with who did what, and when - **Used devices & margin tax**: Second-hand VAT worked out by hand, job by job. - Cost, margin and selling price held per unit - Margin-scheme tax computed on the margin - Margin tax reported separately from standard tax - **Trade-in & buyback**: Trade-ins settled off the books and never reconciled. - Inspect, price and approve a device taken in - Pay out or apply the value against a sale - The handset enters stock as its own unit - **Mobile scanning**: A scanner for every till, or no scanner at all. - Pair a staff phone by scanning the QR on the till - Scan stock straight into the open sale - No app, no login, and it cannot change a price or take payment #### Supply chain - **Purchase orders & receiving**: Supplier orders living in messages and spreadsheets. - Raise a purchase order against a supplier - Receive stock against the order, in full or in part - Supplier bills and returns kept with the order - **Returns to supplier**: Faulty stock going back on the shelf because nowhere else holds it. - Refunded goods wait in a holding area, not on the shelf - Inspect, then restock as used or send back to the supplier - Faulty items tracked until the supplier settles them - **Supplier network**: Re-keying the same order into a supplier's system by hand. - Find and connect to suppliers who use SlickCell Pro - Order against a catalogue the supplier keeps current - Suppliers run their own orders, dispatch and discrepancies #### Back office - **Reports & tax**: The invoice and the report showing different totals. - Revenue and profit read from the same ledger as the invoices - Standard and margin-scheme tax reported separately - Figures trace back to the records behind them - **Workforce**: Staff access too broad, and hours kept on a wall chart. - Role permissions on refunds, voids and price edits - Rota and attendance against employee profiles - Job assignment and technician workload - **Multi-branch**: Each branch keeping its own numbers, in its own way. - One login across every branch - Stock and staff kept per branch - Reporting per branch or across the group - **Cash drawer**: The drawer and the day's takings never quite agreeing. - Open on a float, close on a counted breakdown - Expected against actual, with the difference shown - Cash movements attach to the session automatically - **Stocktake**: A count that overwrites the system with whatever was typed. - Count against a snapshot, not against live stock - The variance is what posts, once approved - Nothing moves until a manager signs it off --- ## Repairs Source: https://pro.slickcell.com/features/repairs #### Every repair, from booked in to handed over: with the money still correct A repair is not one event. It is an intake, a deposit, a part, an approval, a balance and a handover, and most systems keep those in different places. This one keeps them on the same record. ##### Where a repair and its money come apart None of these are unusual. They are just what happens when the job lives on a board and the money lives somewhere else. - A deposit is taken at the counter and noted on the ticket, but never against the bill. - Extra work is agreed verbally, done, and then argued about at collection. - A part is fitted from the drawer and the stock count is corrected next week, or never. - The device is handed over before the balance is settled, and nobody can say who allowed it. - Two faults on one device become two half-finished tickets. - A repair is edited after it was paid, and the day's takings stop matching the invoices. ##### Intake to handover, on one record Each step writes to the next. The job and the money move together because they are the same record, not two records kept in step by hand. - **Intake**: Device, fault and customer captured against a ticket. - **Deposit**: Payment recorded against the job; the balance updates. - **Parts**: Stock committed to this ticket, not just written down. - **Approval**: Extra work is quoted, and how the customer agreed can be recorded on the job. - **Payment**: The balance settles across card, cash or store credit. - **Handover**: Handover closes the ticket and the stock movement. - **Invoice**: The document and the ledger carry the same figures. The point is not that the steps exist. It is that a part used reduces stock, the stock movement lands in cost of goods, and cost of goods lands in the profit and loss: without anyone retyping a number. ##### One ticket, its whole timeline Not a summary screen. The record a shop actually works from. ##### Everything that happened to this device, in order The status flow, the technician who owns it, the parts committed to it and what the customer has been told, on one record, in the order it happened. When a customer asks why the bill changed, the answer is on the ticket rather than in someone's memory. ##### What you get back at the end of the month The operational gain is obvious. The financial one is the reason this matters. - **One version of the job**: No board, no notebook and no phone thread to reconcile against each other. - **Deposits that count**: Money taken at intake is money against the bill, not a note to remember. - **Parts that move stock**: Fitting a part reduces the shelf and lands in cost of goods automatically. - **Balances you can see**: What is paid and what is still due is a figure, not a conversation. - **A history that holds**: Financial changes leave a record, so last month still reads the same next month. ##### The awkward jobs, and what the system does about them Any system handles the simple repair. These are the ones that decide whether the numbers survive the month. - **Multiple issues on one device**: Several faults stay on one ticket for one device, each with its own work and cost, so the customer gets one bill and you keep one history. - **Estimate only, not yet approved**: An estimate is a priced intention, not a job. It does not commit stock or create a charge until it is approved. - **Deposit taken at intake**: The deposit is recorded against the job immediately and reduces the balance due. It is money received, not a note on the ticket. - **Only part of the work approved**: The customer can approve some lines and decline others. The declined work leaves the bill rather than lingering as an assumption. - **A part added after the quote**: Added cost is quoted on the ticket and the price change is stamped and audited. It never quietly appears on the final bill. - **Additional payment required**: When approved work raises the total, the extra shows as a balance due rather than being absorbed into the original figure. - **Waiting for parts**: The ticket carries a waiting state, so a job held up by a supplier is distinguishable from one nobody has started. - **Outsourced repair**: A device sent out for specialist work stays on its ticket while it is away, so it is never simply missing from the shop. - **Cancelled before stock was allocated**: Cancelling early closes the ticket without touching stock, because nothing was committed to it yet. - **Cancelled after stock was allocated**: Committed stock has to be dealt with deliberately, returned to the shelf or accounted for, rather than silently released. - **Warranty claim on an earlier repair**: A warranty job links back to the original repair, so the return is attached to the work that caused it instead of looking like a new sale. - **Handing over before the balance is paid**: An unpaid handover requires a controlled override with a reason, and it leaves an audit entry naming who allowed it. - **A manager reverses something**: A reversal is a recorded action with its own history. A paid part cannot be removed silently, and an invoice cannot be reduced silently after payment: any post-payment change creates an adjustment, refund, credit note or approved write-off. Every one of those leaves an audit history. That is the difference between a system that records what happened and one that records what someone last typed. ##### What the repairs module carries ##### One ticket per job Device, fault, customer and history on a single record from intake to handover. ##### Owner and queue Every job has an assigned technician and a place in the queue, not just a status. ##### Extra work stays visible Added work is quoted on the ticket before it reaches the bill, and every change to the price is recorded. ##### States that mean something Waiting for parts, outsourced and completed are distinct: not one vague 'in progress'. ##### Invoice from the same record The document is generated from the job, so the bill and the ticket cannot disagree. ##### Audit history Financial and stock changes are recorded with who did what, and when. ##### Warranty starts at handover Not at booking. Change the length later and the expiry is recalculated from the same start date, so the printed note and the record agree. ##### Print what you need Ticket, label, receipt or A4 invoice from one template, so the PDF and the paper never disagree. ##### A link the customer can check The QR on the ticket opens a status page for that job. No login, no account, and search engines are told not to index it. ##### The questions owners actually ask Including the one that starts “we already use a whiteboard”. **We already use a whiteboard and it works. Why change?** A whiteboard tracks the job but not the money. It cannot tell you that a deposit was taken, that a part was fitted from stock, or that a bill changed after payment. The board is fine until someone asks why the takings and the invoices disagree. **Does a ticket handle more than one fault on the same device?** Yes. Several faults live on one ticket for one device, each with its own work and cost. The customer gets one bill and you keep one history, rather than two half-finished tickets for the same handset. **What happens when extra work is needed halfway through?** It is quoted on the ticket first, and you can record how the customer agreed. The added cost stays visible and the balance due updates, so the customer is never surprised at collection and the original figure is not quietly rewritten, every price change is stamped and audited. **Can a repair be edited after the customer has paid?** Not silently. Once a payment is recorded, a change must create a controlled adjustment, an additional invoice, a credit note, a refund or an approved write-off. The original payment history is preserved either way. **Can we hand a device over before it is paid for?** Yes, but it is a deliberate act. An unpaid handover requires a controlled override with a reason, and it leaves an audit entry naming who allowed it, so it stays a decision rather than a habit. **What if a job has to be cancelled?** It depends whether stock was committed. Cancelling before allocation closes the ticket cleanly. Cancelling after means the committed parts have to be dealt with deliberately, so the shelf and the system stay in agreement. --- ## POS & sales Source: https://pro.slickcell.com/features/pos #### A till that keeps the money straight, not just the sale Most tills are good at taking a payment and bad at saying what kind of money it was. Part payments, change and store credit are not the same thing, and a shop that treats them as one loses the difference. ##### Where the money quietly changes shape Every one of these balances on the day and still leaves you short at the month. - A customer pays most of it, promises the rest, and the sale gets marked paid. - The shortfall is written off as a discount because that is the only field that fits. - Cash change handed back is counted as though it were takings. - Store credit from a return is given as a price reduction, so the liability disappears. - A handset is sold from a shelf that the system still thinks holds four. - A refunded device goes straight back out for sale without anyone checking it. ##### From the exact unit to a settled balance The sequence matters because each step is where a specific mistake usually happens. - **Exact unit**: The specific item or handset, not a generic line. - **Basket**: Priced and totalled: stock is not touched yet. - **Split tender**: Card, cash or store credit, in any combination. - **Balance state**: Received, due, overpayment and change kept apart. - **Confirm**: Only now does stock move against the sale. - **Receipt**: The document carries the same figures as the ledger. The order is deliberate: nothing leaves the shelf on the strength of someone starting a sale, and nothing is called paid until the arithmetic says it is. ##### One sale, settled two ways The screen where the distinction between received, due and change is either kept or lost. ##### Card and cash on the same sale, both classified The total due, the amount collected and what is left are three separate figures, not one field called paid. Each tender line carries its own method and reference, so the cash drawer and the card total can both be reconciled at close, and a shortfall stays visible as a balance instead of quietly becoming a discount. ##### What the counter stops costing you These are the five leaks that a till which only knows paid and unpaid cannot close. - **Shortfalls stay visible**: An underpayment is a balance you can chase, not a discount you absorbed. - **Change is not takings**: Cash handed back is never reported as revenue, so the day's figure is real. - **Credit stays a liability**: Store credit moves on a ledger instead of vanishing into a price reduction. - **Stock matches the shelf**: Nothing is deducted because a sale was started: only because one completed. - **Returns are decided**: Where returned stock goes is chosen, not assumed, and it is not resold unchecked. ##### The rules the till actually enforces Not settings you have to remember. This is how the sale behaves. - **The exact item is selected**: You sell the specific part, or the specific handset by its IMEI, serial or shop reference: never a generic line that stands in for whichever one happens to be on the shelf. - **The basket does not touch stock**: Adding an item to a sale reserves nothing and deducts nothing. A half-started sale at a busy counter cannot make your stock figures wrong. - **Stock moves on confirmation**: The shelf changes only when the sale reaches its confirmed, approved state: one movement, at one moment, with a record attached. - **Five figures, kept apart**: Amount received, invoice total, amount due, overpayment and change are five separate numbers. Collapsing them into one is exactly how shortfalls disappear. - **Underpayment is never a discount**: Paying less than the total creates a visible balance against the sale. There is no path where a shortfall silently becomes a price reduction. - **Change is not revenue**: Cash given back is recorded as change, not as money taken, so the day's revenue figure is not inflated by the float moving in and out. - **Store credit is a ledger movement**: Credit issued and credit spent are entries on a ledger you can read back, a liability the shop owes, rather than a discount that leaves no trace. - **Returned stock has a destination**: On a refund you choose deliberately where the item goes. It does not default back onto the sales shelf because that was the easiest option. - **Refunded devices are not automatically resellable**: A returned handset does not become sellable stock again until it has been inspected. The system will not quietly put an unchecked device back in the window. ##### What the till carries ##### Sell the exact unit Repairs, accessories and individual handsets on the same sale, each identified. ##### Split tender Card, cash, bank transfer and store credit in any combination on one sale. ##### Balance arithmetic Received, total, due, overpayment and change tracked as separate figures. ##### Store credit ledger Credit issued and spent as recorded movements, not as invisible discounts. ##### Controlled returns Refunds choose where stock goes, and devices need inspection before resale. ##### Receipt from the sale The document is produced from the sale record, so the two cannot disagree. ##### What counter staff ask first Starting with the one that matters most at a queue. **Our current till is faster. Won't this slow the counter down?** A sale is a few taps either way. The time a shop actually loses is at the month end, reconciling a till that recorded a part payment as paid and a shortfall as a discount. This is the same speed at the counter and considerably faster afterwards. **Does adding an item to the basket reduce my stock?** No. Stock changes only when the sale is confirmed. A basket that is abandoned, edited or left open at a busy counter has no effect on your stock figures at all. **What happens when a customer pays only part of the bill?** The difference stays as a visible balance against the sale. It is never converted into a discount, so you can see what is owed, chase it, and settle it later against the same record rather than a new one. **How is cash change handled?** Change is recorded as change and never counted as revenue. Amount received, invoice total, amount due, overpayment and change are five separate figures, so the day's takings reflect money kept rather than money handled. **What happens to store credit from a return?** It moves on a ledger. Credit issued is a liability the shop owes and credit spent is an entry against it, so you can read back what was given and what has been used, rather than a price reduction that leaves no trace. **Can a refunded handset go straight back on sale?** Not automatically. You choose where returned stock goes, and a returned device is not treated as sellable again until it has been inspected. That stops an unchecked handset going back in the window on a busy afternoon. --- ## Invoicing & payments Source: https://pro.slickcell.com/features/invoicing #### Invoices, payments and refunds in one financial history The problem is rarely the first invoice. It is what happens to it afterwards (the correction, the part refund, the goodwill discount) and whether any of that leaves a trace you can follow in three months. ##### Where settled money quietly changes Each of these is a reasonable thing to do at the counter. Together they are why the books stop agreeing with the till. - A paid invoice is edited to fix a line, and last week's takings change with it. - A goodwill reduction is applied by overwriting the total rather than recording it. - A part refund is handed back in cash and noted on a scrap of paper. - Two invoices exist for one job because it was easier than correcting the first. - The report and the invoice list disagree, and nobody can say which is right. - An amount is written off, and six weeks later nobody remembers who agreed it. ##### Invoice, part payment, adjustment, refund, credit note The sequence a real job actually takes, and the point at which the rules change. - **Invoice raised**: Generated from the job, carrying its lines and totals. - **Part payment**: Recorded against the invoice; the balance updates. - **Still open**: Draft and unpaid invoices update through the ticket workflow. - **Payment recorded**: From here, settled history can no longer be rewritten. - **Adjustment**: A later change becomes a recorded correction of its own. - **Credit or refund**: Money owed back is a credit note or a refund, not an edit. The line in the middle is the whole page. Before a payment, an invoice is a working document. After one, it is financial history, and history gets corrected by adding to it, never by overwriting it. ##### The document, and the report that reads from it Two artefacts in real markup. The figures in the second are the invoices in the first. ##### One invoice, every tender against it The subtotal, the tax, the total, what has been received, what change went back and what is still due: as separate figures on the document itself. A part payment leaves a visible balance rather than a rounded-down total, and each tender line keeps its own method and date. ##### Reports read from the same underlying records Reports read from the same underlying financial records as the invoices, with reconciliation checks and drill-downs, so a revenue figure opens onto the invoices that compose it, and the rows add up to the headline rather than approximating it. ##### What you can prove three months later Not that nothing ever goes wrong: that everything which did is still legible. - **Corrections are additive**: A change adds a record rather than replacing one, so the original stays readable. - **Payments survive edits**: The payment history is preserved whatever happens to the invoice afterwards. - **Reasons travel with money**: A credit, a refund or a write-off carries why it happened, not just how much. - **One job, one thread**: Related documents stay linked instead of becoming two unrelated invoices. - **Figures you can open**: A total drills down to the records that produced it when someone asks. ##### What happens when something has to change Every one of these is a real thing that happens after money has moved. None of them overwrites what was there. - **The invoice is still draft or unpaid**: It can be updated through the approved ticket workflow, because nothing has been settled yet. This is the only window in which the document itself changes. - **A payment has been recorded**: From that point, financial changes cannot silently rewrite settled history. Every correction below adds a record instead of editing the original. - **Work was added after the bill was paid**: The extra becomes a controlled adjustment or an additional invoice. The first invoice keeps the figures it was paid against. - **A line has to come off**: Removing a charge after payment creates a recorded correction, not a deletion. A paid part cannot simply disappear from the job. - **A discount is agreed afterwards**: It is recorded as a correction with its own entry, rather than the total being quietly reduced to match what the customer actually handed over. - **The customer was overcharged**: A credit note records what is owed back, linked to the invoice that caused it, so the correction and the original are readable together. - **Money goes back to the customer**: A refund is recorded as its own movement against the invoice. It reduces what has been settled without pretending the original payment never happened. - **A small balance will never be paid**: It is closed with an approved write-off carrying a reason, rather than being absorbed into a discount that leaves no trace of the decision. - **Somebody asks why the total moved**: The invoice carries its adjustments, credits and refunds as history, so the answer is on the record rather than in whoever happened to be on the counter that day. Added charges, removals, discounts and corrections must create a controlled adjustment, an additional invoice, a credit note, a refund or an approved write-off, and the original payment history is preserved. ##### What invoicing carries ##### Invoice from the job Generated from the record it belongs to, so the bill and the work cannot disagree. ##### Part payments Received, due and change tracked separately, with a visible balance rather than a rounded total. ##### Adjustments Post-payment changes recorded as corrections that sit alongside the original. ##### Credit notes What is owed back, linked to the invoice that caused it and readable together. ##### Payment history Every tender, correction and refund against the invoice, in the order it happened. ##### No silent rewrites Once a payment exists, settled history is added to rather than overwritten. ##### What owners and accountants ask Including the one that comes up on every call. **My accountant already handles this. Why does it matter?** Your accountant works from what you give them. If a paid invoice was edited in March, they are reconciling a figure that no longer matches the payment it received. This does not replace an accountant. It means the records handed over are the records that actually happened. **Can I edit an invoice after the customer has paid?** Not directly. Draft and unpaid invoices update through the approved ticket workflow. Once a payment is recorded, added charges, removals, discounts and corrections must create a controlled adjustment, an additional invoice, a credit note, a refund or an approved write-off, and the original payment history is preserved. **What if a customer pays only part of the bill?** The balance stays visible against the invoice. Received, due and change are separate figures, so a shortfall remains something you can chase and settle later rather than being absorbed into the total as though it were a discount. **How do refunds and credit notes differ?** A credit note records that money is owed back and links to the invoice that caused it. A refund records money actually going back to the customer. Both sit alongside the original rather than modifying it, so the sequence stays readable afterwards. **Can a bad debt be written off?** Yes, as an approved write-off carrying a reason. The balance is closed deliberately and the decision is recorded, rather than the amount quietly becoming a discount that nobody can account for at the year end. **Will my reports match my invoices?** Reports read from the same underlying financial records as the invoices, with reconciliation checks and drill-downs. A revenue figure opens onto the invoices behind it, so where a difference exists you can see which records produced it rather than guessing. --- ## Inventory & device units Source: https://pro.slickcell.com/features/inventory #### Parts by quantity. Devices one unit at a time. A box of screen protectors is a number. A second-hand handset is not. It has its own cost, its own condition and its own history. Counting both the same way is why the shelf and the system stop agreeing. ##### Where the count goes wrong Not carelessness. Just what happens when four different handsets share one line called “iPhone 13”. - Four of the same model on the shelf, bought at four different prices, counted as one line. - The right handset is sold, but nobody can say which one left or what it cost you. - A part is used on a repair and the count is corrected at the weekend, if anyone remembers. - A trade-in goes on the shelf without a cost, so the margin on it is a guess. - The system says three, the drawer says one, and neither has a history to check. - A device comes back from a refund and rejoins stock without anyone recording why. ##### Product group, individual units, movement history One model is a group. Each physical handset inside it is its own record. The quantity is what falls out of that, not something anyone types. - **Product group**: The model, iPhone 13 128GB, as a heading, not a count. - **Units**: One record per handset, with its own identifier. - **Own specs**: Storage, colour, condition and battery per unit. - **Own money**: Cost and selling price held on the unit itself. - **Movements**: Received, reserved, sold or returned: each recorded. - **Derived quantity**: Available stock is counted from the units. Because quantity is derived rather than typed, there is no way for the number to drift away from the things it is supposed to be counting. ##### One model, and the handsets inside it Real markup, not a screenshot: the figures below are checkable against each other. ##### Three handsets, three costs, one model Each unit carries its own identifier, condition, battery health, cost and selling price, and the sold one carries the invoice it left on. The available stock value underneath is the sum of the units still on the shelf, so you can check the total against the rows that produced it. ##### Stock you can trust and audit The operational win is knowing what is there. The financial win is knowing what it cost. - **Real cost per handset**: Margin is calculated against what that unit actually cost, not an average. - **The right one sold**: You know which physical device left the shop, and against which sale. - **Counts that hold**: Quantity is derived from units, so it cannot drift from what is on the shelf. - **A movement history**: Every arrival, reservation, sale and return is recorded with who and when. - **Defensible valuation**: Stock value is the sum of real unit costs you can open up and check. ##### Bringing your existing stock in These are the rules the import actually follows. Nothing here is aspirational. - **Three separate imports**: Parts, accessories and devices come in as three separate imports, because they are three different kinds of thing with three different shapes. - **Quantity for parts, references for devices**: Parts and accessories are imported with a quantity. Device quantity is derived from the unit references you supply, not entered as a number. - **One unit per reference**: Each device unit corresponds to one IMEI, serial number or shop reference. Two units cannot share one reference. - **The reference can be partial**: A full IMEI, a serial number, the last four or five digits, or an internal shop reference are all accepted, stored as free text, with no format or checksum rule to fight. - **Prices in pounds**: Costs and selling prices are entered in pounds, the way they appear on your supplier's invoice. - **Suppliers by ID**: A supplier is selected by its supplier ID, so the same name spelled three ways does not become three suppliers. - **Preview before commit**: You see what the import will do before anything is written. Nothing lands in your stock on the strength of a file you have not looked at. - **Warnings and errors are separate**: Rows that cannot be imported and rows that merely look odd are shown apart, so a genuine problem is not buried among things that are simply unusual. - **Update mode is explicit**: Whether the import updates existing stock is a choice you make deliberately, not a default that quietly overwrites what is already there. - **No barcode required**: The approved import format does not require a barcode, so a spreadsheet from an older system is enough to get started. ##### What the stock module carries ##### Unit-level devices Each handset is its own record with an IMEI, serial or shop reference as free text. ##### Quantity for consumables Parts and accessories counted the sensible way, by quantity on the shelf. ##### Specs per unit Storage, colour, condition and battery health held on the individual handset. ##### Cost and price per unit What that device cost you and what it sells for, not a blended average. ##### Movement history Arrivals, reservations, sales and returns recorded with who did what, and when. ##### Import with a preview Bring stock in from a spreadsheet and see exactly what it will do first. ##### The stock questions worth asking Starting with the one everyone asks about unit tracking. **Unit tracking sounds like extra work. Is it?** It is one extra field when a handset arrives, and it removes the work of reconciling a count that drifted. You are already tracking these devices: on a whiteboard, in a notebook, or in your head. This just puts them where the money is. **Does every device need a proper IMEI?** No. Each unit carries an IMEI, serial number or shop reference, stored as free text. A full IMEI, the last four or five digits, or your own internal reference are all fine. There is no format or checksum rule to satisfy. **Do I have to track parts one at a time as well?** No, and you should not. Parts and accessories are counted by quantity, which is the right shape for a box of screen protectors. Only devices are tracked as individual units, because only devices have their own cost, condition and history. **How does the quantity stay right?** It is derived rather than typed. Available stock is counted from the unit records themselves, so there is no separate number to fall out of step with the shelf and no way to correct one without the other. **Can I bring my existing stock in from a spreadsheet?** Yes. Parts, accessories and devices import separately, prices are entered in pounds and suppliers are selected by supplier ID. You preview what the import will do before anything is written, with warnings and errors shown separately. **What happens when a device comes back from a refund?** It does not rejoin sellable stock on its own. Where returned stock goes is chosen deliberately, and a returned handset is not treated as available again until it has been inspected. --- ## Used devices & the margin scheme Source: https://pro.slickcell.com/features/used-devices #### Two identical handsets are not the same stock Same model, same colour, same shelf: bought for different money, in different condition, from different people, and taxed differently when they sell. Counting them as “2 in stock” is where the margin goes missing. ##### Where second-hand stock stops adding up Quantity-based stock control was designed for parts. Handsets break it. - Four of the same model in stock, bought for four different prices, showing as one line. - A handset sells and nobody can say which one went, or what it cost. - Which units came in on a tax invoice and which did not is in somebody's memory. - Battery health and condition were noted on the box, and the box is gone. - A device is sold at the shelf price when that particular unit cost far more. - A returned handset goes straight back on the shelf without anyone checking it. ##### One handset, one record, all the way through A device unit is created when the handset arrives and is closed when it leaves. Everything about it hangs off that one row. - **Intake**: The handset gets its own record and its own reference. - **Specs**: Storage, colour, condition, battery health and network, per unit. - **Cost**: What this handset cost you, not what the model usually costs. - **Price**: A selling price on the unit itself, not on the model. - **Sale**: That specific unit leaves stock, at its own price. - **Tax**: If it sells on the margin, the tax follows the margin. - **After**: Returns land back as a unit to inspect, never straight onto the shelf. Because quantity is derived from the units rather than typed, the count and the shelf cannot drift apart. There is no number for anyone to correct. ##### The record a device trader works from Not a stock line. A handset. ##### Where this handset came from and what it did Its reference, its specs, what it cost, what it sold for and every movement in between, for that unit, not for the model. When a customer comes back three months later, the answer is on the record. ##### The unit's price wins, every time A handset that cost more sells for more, even if the model's default price says otherwise. The price is taken from the unit when the invoice is raised, so a busy counter cannot accidentally sell a premium unit at the shelf figure. ##### Second-hand stops being the guesswork line - **Real margin per handset**: Profit is this unit's price minus this unit's cost: not an average across a model that flatters the good buys and hides the bad ones. - **Tax that follows the unit**: Margin-taxed stock is treated on its margin and reported separately from standard-rated sales. - **A history you can answer from**: Every unit carries where it came from, what was done to it and where it went. - **Returns that get inspected**: A refunded handset comes back as a unit to look at, not as a number added to a count. Every SlickCell Pro feature is included on every plan: plans differ by team size, locations, discounts and support. ##### The ones that catch out quantity-based systems - **You only know the last four digits**: The reference is free text on purpose. Shops key shorthand, and a system that refuses it just gets a fake number typed into it instead. - **Two units end up with the same reference**: It is flagged as a conflict to resolve rather than blocked outright, so the unit still gets recorded, and the clash surfaces where someone can fix it. - **One model, six different costs**: Each unit holds its own. There is no average cost standing in for six different purchases. - **Some units came in on a tax invoice, some did not**: That is a property of the unit, which is what decides how its sale is taxed. - **A sold handset comes back**: It returns to a state that means 'returned', not 'available'. Putting it back on the shelf is a decision someone makes, not a side effect. - **A unit is being held for a customer**: Reserved is its own state, so it is not sold twice while the customer thinks about it. - **The handset is locked and the customer left the code**: PIN, password or a drawn pattern can be held against the device, behind a role check, and every look at it is recorded. None of these need a workaround. They are states a unit already carries. ##### What unit tracking carries ##### One unit, one record Every physical handset is its own row, from intake to sale. ##### Free-text references IMEI or serial as you actually write it, with clashes flagged rather than blocked. ##### Specs per handset Storage, colour, condition, battery health, network and region on the unit. ##### Cost and price per handset What this one cost and what this one sells for: the unit's price is the one that applies. ##### Margin tax where it applies Used stock can be taxed on the margin and reported apart from standard sales. ##### Movement history Every state change on the unit, with who did it and when. ##### What device traders ask **Do I have to type a full IMEI for every handset?** No. The reference is free text, so last-four or last-five shorthand is fine. That is how shops actually work. There is no format or checksum validation, deliberately: a system that rejects real-world shorthand only teaches people to type a fake number that passes. **What if two units end up with the same reference?** The clash is detected and flagged for someone to resolve, rather than the unit being refused at the point of entry. The record still exists, and the conflict surfaces where it can be dealt with. **How does the margin scheme work here?** Tax is a rule you configure, and one of the types is margin: which can be scoped to used stock specifically. When a unit sells under that rule, the tax follows the margin between what you paid and what you sold it for, and is reported separately from standard-rated sales. The rules that apply to you depend on where you trade; check with your accountant. **Does a returned handset go back into stock automatically?** No, and that is deliberate. It returns as a unit in a returned state for someone to inspect. Moving a sold device straight back to available is refused by the system. **We sell parts and accessories too. Does everything become unit-tracked?** No. Parts and accessories stay quantity-based, which is the right model for them. Unit tracking is for the stock where each item genuinely differs. --- ## Trade-in & buyback Source: https://pro.slickcell.com/features/buyback #### Buying a handset is a purchase, not a note in the drawer Money leaves the till, a device arrives with no paperwork behind it, and both need to end up somewhere a report can see. This makes the whole thing one record: inspected, approved, paid and on the shelf. ##### Where a trade-in disappears Buying stock from the public is the one flow most shop systems simply do not have. - Cash goes out of the drawer and the day's takings never explain it. - A handset is bought at the counter and priced by whoever happened to be on. - The device sits in a drawer for a week before anyone lists it. - Store credit is promised verbally and honoured from memory. - Nobody can say what the shop paid for a handset it is about to sell. - The seller's details were written on a pad that is now full. ##### Counter to shelf, as a set of states Each step is a state the record actually holds, so at any moment you can see exactly how far a buy has got. - **Take it in**: The handset and the seller's detail are captured as a record. - **Inspect**: Condition and working order assessed before any money is agreed. - **Approve**: A manager signs off the price the shop is paying. - **Purchase**: The buy is committed at the approved figure. - **Pay the seller**: Cash, bank transfer, store credit or against a sale. - **Add to inventory**: The handset becomes a device unit with its own cost and specs. Because paying the seller is a real money movement, it reaches the cash drawer and the account ledger the same way every other payment does, rather than being an unexplained gap in the day. ##### One buy, start to finish The record, and the money it moved. ##### Inspected first, priced second, paid third A buy waits for inspection and then for a manager's approval before any money is committed. The person on the counter can start the record without being the person who decides what the shop pays for it. ##### Credit you can account for Settle a trade-in as store credit and it becomes a ledger entry, not a promise. It is applied against a sale as a real payment, so the customer's balance and the shop's books agree about what is owed. ##### Money out of the drawer is money you can explain - **The payout is accounted for**: Paying a seller is a recorded money movement that reaches the drawer, the account ledger and the reports. - **Pricing is a decision, not a habit**: Inspection and approval sit between the handset arriving and the shop paying for it. - **The handset enters stock properly**: It becomes a device unit with the cost you actually paid, so its margin is real when it sells. - **Seller detail is held, and restricted**: The record keeps who you bought from, and that detail is visible only to the roles that should see it. Every SlickCell Pro feature is included on every plan: plans differ by team size, locations, discounts and support. ##### The awkward ones, handled - **The handset fails inspection**: The buy is rejected as a recorded outcome. It does not vanish. You can see what was turned away and why. - **The seller changes their mind**: Cancelled is its own state, distinct from rejected. What happened is still on the record. - **They want credit instead of cash**: Store credit is one of the settlement methods, and becomes a ledger entry applied against a future sale. - **They are trading in against something they are buying now**: The trade-in value settles against the sale rather than money going out and coming straight back in. - **The shop paid too much**: The cost stays on the unit, so the thin margin is visible when it sells instead of being averaged away. - **A staff member should not see seller details**: Sensitive seller information is restricted by role, so the counter can take a device in without the whole shop seeing the person's details. - **The device is locked**: PIN, password or a drawn pattern can be recorded against the device, behind a role check and with every reveal audited. What you are required to record when buying from the public differs by country, the system holds the detail, but check what applies where you trade. ##### What buyback carries ##### Inspection before price Condition is assessed as its own step, before the shop commits to a figure. ##### Manager approval The payout figure is signed off by someone with the authority to sign it off. ##### Four ways to settle Cash, bank transfer, store credit, or against something they are buying. ##### Store credit ledger Credit is a balance that gets applied as a real payment, not a promise. ##### Straight into unit stock The handset becomes a device unit carrying the cost you actually paid. ##### Restricted seller detail Who you bought from is held on the record and visible only to the right roles. ##### What shops ask about buying stock in **We only take a few trade-ins a week. Is this worth it?** The volume is not the problem: the untracked cash is. A handful of unexplained payouts a week is exactly the kind of thing that makes a month's cash refuse to reconcile, and it is far harder to unpick later than to record at the counter. **Can the person on the counter take a device in without deciding the price?** Yes, and that is the intended shape. They create the record and inspect; approval of what the shop pays is a separate state that a manager moves it through. **How does store credit actually work?** It is its own ledger. Settling a buy as store credit creates a balance for that customer, and when they spend it, it is applied against the sale as a real payment, so both sides of it appear in the books. **What do we have to record when buying from the public?** That depends entirely on where you trade, and we are not going to pretend otherwise. The system holds the seller's details, the device, the price and the date against the buy, and restricts who can see them: what your jurisdiction requires you to keep is a question for your own advice. **Does the trade-in show up in reports?** Yes. Buyback has its own report, the payout appears in the money account as cash going out, and the handset's cost follows it into stock so its margin is right when it sells. --- ## Customers Source: https://pro.slickcell.com/features/customers #### The same person, the same device, the third time they come in Repair is repeat trade. Whether the last screen you fitted is still under warranty, what you charged, and which handset it was should be on a record, not in the memory of whoever happened to serve them. ##### Where customer history goes Almost every shop has this problem, and almost none of them call it a CRM problem. - A customer returns with the same fault and nobody can find the original job. - Their number is in one person's phone, under a nickname. - Two records for the same person, spelled differently. - Nobody can say whether the repair they are complaining about is still in warranty. - The device passcode was written on a sticky note that came off. - A refund was given months ago and there is no trace of why. ##### One person, everything attached The customer record is not a contact card. It is the thing every job, sale and payment hangs off. - **The person**: Name and contact detail, captured once at the counter. - **Their devices**: Handsets linked to the person who actually owns them. - **Their jobs**: Every repair against the customer and the device it was on. - **Their money**: Sales, payments, refunds and credit notes as one history. - **Their messages**: What they were told about the job, and when. - **Their view**: What they said about the work, from the link on the receipt. Because the invoice freezes who the customer was when it was issued, correcting a name today does not quietly rewrite a document that was already given to someone. ##### The record the counter actually needs Answering the question a returning customer just asked. ##### Which handset, which job, and is it still covered Devices belong to the person who owns them, and every repair sits against both. When someone comes back with the same fault, the original job, the part that went in and whether it is still in warranty are on the record, not reconstructed from a date and a guess. ##### The passcode, held properly A PIN, a password or a pattern drawn on a 3x3 grid: the three ways phones actually lock. It is stored behind a restricted call rather than sitting on the device record, ordinary screens never return it, and every time someone reveals it that is checked against their role and written to the audit log. ##### Repeat customers stop starting from scratch - **Warranty questions have an answer**: The original job, the part and the cover are on the record, so the counter is not negotiating from memory. - **Devices belong to people**: Handsets are linked to owners, and a change of owner is a recorded action. - **One financial history**: Sales, payments, refunds and credit notes read as one story rather than four lists. - **Codes are held safely**: Unlock codes are restricted and every look at one is audited. Every SlickCell Pro feature is included on every plan: plans differ by team size, locations, discounts and support. ##### The awkward ones, handled - **The same person entered twice**: Matching helps catch it at the counter, where it is cheap to fix, rather than at year end when it is not. - **They sold the phone to someone else**: Ownership transfer is a recorded action, so the device moves to the new owner and the history of the move survives. - **Their name was spelled wrong on an invoice they already have**: Correct the customer, and the issued invoice keeps the identity it was issued with. A document someone is holding does not change under them. - **A credit note from a refund months ago**: It is refund history: a record of what was returned and why. It is not a spendable balance, and the page never pretends otherwise. - **They want to know how the repair is going**: The QR on their ticket opens a status page for that job, with no login and no account. - **You need to tell fifty customers something**: Messages can go to a group of customers on a template, and each one is kept against the customer it went to. - **The customer left a bad review**: It arrives against the job and the technician who did it, with the attribution fixed at the moment it landed. Store credit from a trade-in is a different thing to a credit note: that lives with buyback. ##### What the customer record carries ##### The person Contact detail captured once, with duplicates caught at the counter. ##### Devices they own Handsets linked to their owner, with transfers recorded. ##### Every job and sale Repairs, purchases and warranty state against the person and the device. ##### One financial history Payments, refunds and credit notes as a single story you can follow. ##### What they were told Messages sent from the job, on a template, kept against the customer. ##### What they thought Ratings from the link on their receipt, attributed to the job that earned them. ##### What shops ask about customer records **Is this a CRM? We do not want to run marketing campaigns.** It is the operational record a counter needs: who owns which device, what you did to it and what they paid, ready the moment someone walks back in. Bulk messages go only to customers who have opted in to marketing, and only when you choose to send them. **How do customers find out a repair is ready?** Email them from the job on a template, and every message is kept against the customer. Their receipt also carries a QR code that opens a live tracking page, so they can check the status themselves without ringing the shop. **How are device passcodes stored?** Behind a restricted call, not on the device record. Ordinary screens never return the code, revealing it is checked against your role, and every reveal is written to the audit log. Patterns are supported as a drawn 3x3 sequence, because that is how a lot of handsets actually lock. **Can a customer spend a credit note?** No. Credit notes here are refund history: the record of what was returned and why. Spendable balances come from trade-ins, which are a separate ledger. We keep those two apart deliberately, because conflating them is how shops end up honouring the same money twice. **If I correct a customer's name, does it change old invoices?** No. An invoice freezes the customer identity it was issued with. Correcting the record going forward does not rewrite a document somebody is already holding. **Does customer history follow them between our branches?** No: branches keep their own records, because they are genuinely separate shops. It is worth knowing if you run more than one site. --- ## Customer tracking & reviews Source: https://pro.slickcell.com/features/customer-tracking #### “Where is my phone?” Answered without the phone call The QR on the ticket you already hand over opens a page showing where that repair has got to. No app, no account, no password, and nothing on it that you would not say at the counter. ##### The call every shop takes ten times a day Each one is thirty seconds. Thirty seconds, ten times, on a Saturday, is the whole problem. - Someone rings to ask whether it is ready, and it is still on the bench. - The person who answers has to find the ticket before they can say anything. - A customer turns up to collect a device that is still waiting for a part. - The same customer rings three times because nothing told them anything changed. - A repair took longer than quoted and the first they hear of it is at the counter. - You ask for a review a week later, by which point the job is a blur to them. ##### From the counter to a page they can check Nothing here is a separate thing to set up. It is on the paperwork you already print. - **Book it in**: The ticket gets a link of its own, and a QR that encodes it. - **Print**: The QR is on the ticket, the label and the receipt as they come off the printer. - **They scan**: The phone camera opens the page. No account, no download, no login. - **They see progress**: The status, what it is, who has it, and when it is due back. - **Ready**: The page shows completed, so the trip to the shop is a trip worth making. - **Review**: Once the job is finished they can rate it, from the same link. The customer never creates anything. The link is the ticket, and the ticket already existed. ##### The QR is already on the paperwork Printed from the same template as everything else, so the link and the document cannot disagree. ##### Ticket, label, receipt or A4: one template The QR is generated as the document is drawn, so whichever format you print, it carries the link for that job. Change the paper size and it is the same document, not a different one. ##### What you get back - **Fewer interruptions**: The commonest question a repair shop is asked has an answer that does not need a person. - **Collections that are not wasted trips**: Someone who can see “not ready yet” does not come in to be told it. - **Nothing to sign up for**: No customer account, no portal password to reset, no app to persuade anyone to install. - **Reviews while it is fresh**: Asked at the moment the job finishes, from the link they already have open. - **Credit where it is due**: A review attaches to the technician who did the work, not to the shop in general. ##### What is on the page, and what is not A link anyone can open is a decision about disclosure, so this is the part worth reading. - **The repair page shows progress, not money**: Status, the stage it has reached, the device, who is working on it and when it is due. No prices, no line items, and the customer's first name only. - **The invoice page shows the bill**: A separate link, rendered from the same template as the printed receipt: the lines, the total, what has been paid and what is still due, with a PDF to download. - **Search engines are told to stay away**: Both pages carry noindex, nofollow and noarchive, and the site's robots file disallows them. They are unlisted pages, not published ones. - **A link can be turned off**: Links can be given an expiry date or revoked outright, and a revoked link stops working immediately. Rotating or revoking one is an owner or manager action. - **Following one link does not unlock the other**: The repair page links to its invoice and the invoice links back, but each is checked on its own. Revoke the invoice link and the repair page stops offering it. - **A review waits for the job to finish**: The option appears once the repair is completed or handed over, whichever link the customer arrived through, and only once per repair. - **Reviews are yours, not ours**: They are visible inside your shop and nowhere else. Nothing publishes them to this site, to a directory, or to any public profile. ##### What customer tracking carries ##### A QR on the paperwork On the ticket, the label and the receipt, generated as the document is drawn. ##### A status page with no login Stage, device, technician and due date, in the order things happened. ##### The invoice, and a PDF Lines, total, paid and balance due: the same document you would hand over. ##### Linked both ways The repair page opens its invoice, and the invoice opens the repair: each checked separately. ##### Unlisted, expirable, revocable Noindexed and disallowed in robots, with links that can be given an end date or switched off. ##### A rating out of five Offered once the job is finished, with an optional comment and name. ##### Attributed to the technician Each review is tied to whoever the job was assigned to, and shows on their record. ##### Whatever printer you have A4, 80mm, 58mm or a label: the QR is on all of them because they are one template. ##### The questions owners ask about showing customers anything **Our customers won't use it.** Some will not, and the calls from those people carry on exactly as now. The ones who do use it are the ones who would otherwise have rung twice, and scanning a code on a receipt with a phone camera is roughly as much effort as reading the receipt. **Can anyone with the link see it?** Yes, and that is why the page is built the way it is. The repair page carries no prices, no line items and only a first name. The links are unlisted, not published: search engines are told not to index them, and you can give a link an expiry or revoke it. **Does the customer need an account?** No. There is nothing to sign up for, no password and no app. The link is the whole thing. **How does the customer get the link?** It is printed as a QR code on their receipt and repair label, so they scan it once and keep checking. You can also paste the link into any message you send from the job. **When can a customer leave a review?** Once the repair is completed or handed over, and once per repair. Before that the option is not shown, so nobody is invited to rate a job that has not been done. **Do reviews appear anywhere public?** No. They are visible to your shop, summarised on the customer record and on the technician who did the work. Nothing publishes them anywhere else. --- ## Phone as a barcode scanner Source: https://pro.slickcell.com/features/mobile-scanning #### Your staff already carry a barcode scanner Show a code on the till, scan it with any phone in the shop, and that phone starts scanning stock into the open sale. Nothing to install, nothing to log in to, and nothing to buy. ##### Why the scanner never gets bought It is never urgent enough to buy and never cheap enough to buy four of. - One scanner, two tills, and it lives at whichever one used it last. - The second counter types SKUs by hand because the hardware never got ordered. - A Saturday assistant is handed the till and cannot be handed the cost prices with it. - Stock arrives in a box on the floor, nowhere near the desk the scanner is cabled to. - The wireless one is flat, and the charger is in the back. - Someone mistypes a SKU and the sale goes through against the wrong item. ##### Paired in about ten seconds The whole setup is a code on one screen and a camera on another. - **Open the sale**: Start a sale at the till as you normally would. - **Show the code**: The till displays a pairing QR, good for ten minutes. - **Scan it**: Any phone camera. The page opens; no app store, no sign-in. - **Confirm**: The phone asks whether to connect to that till, and names it. - **Scan stock**: Each barcode goes to the till, which resolves it and adds the line. - **Take payment**: Payment happens at the till. The phone cannot take money. - **Done**: Completing the sale ends the session, and the code is spent. The phone submits what it read. Everything else (resolving the code, the cart, the arithmetic) stays on the till. ##### The till keeps the cart The phone is an input device with a screen, not a second till. ##### Scanned lines land in the sale on the counter A scan is submitted as the raw code and resolved on the till, so the line that appears is the one the till's own catalogue matched: not something the phone decided. Quantities and removals work from the phone too; price changes and payment do not. ##### What you stop needing - **Hardware you did not buy**: Every counter can scan, including the one you set up for the Christmas rush. - **Nothing to install**: No app, no store, no device management, and no phone that needs enrolling. - **A phone you can hand to anyone**: It carries prices, because a till does. It does not carry cost, margin, customer details or full IMEIs, and it cannot change a price or take a payment. - **Scanning where the stock is**: The box on the floor, the shelf at the back: not wherever the cable reaches. - **Fewer typed SKUs**: The commonest way a sale goes against the wrong item is somebody typing it. ##### What the phone can and cannot do Handing a member of staff a phone that is connected to the till is a permission decision, so here is exactly what it grants. - **It can scan, adjust quantity and remove a line**: The three things a second pair of hands actually needs while a sale is being built. - **It cannot change a price or take a payment**: Discounting, overriding a price and tendering all stay at the till, under whatever role the person on the till has. - **It sees prices, not cost**: Line prices and the cart total are on the phone, because it is showing a sale. Cost, margin, supplier and the customer's name and number are not sent to it at all. - **It never sees a full IMEI**: A serialised unit shows as a six-character tail, enough to tell two handsets apart and not enough to write down. - **The code goes stale on its own**: Ten minutes to pair, thirty minutes maximum for the session however busy it is, and three minutes of silence ends it. Reopening the panel voids the old code and issues a new one. - **One phone per till**: A pairing code can be claimed once. A second phone scanning the same code is refused rather than joining. - **You can disconnect it from the till**: Disconnect ends the session immediately, and so does finishing the sale. The phone can also disconnect itself. - **Only some roles can pair one**: Pairing is limited by role, and the whole feature can be switched off for the shop. - **A dropped connection does not lose scans**: Events are numbered and acknowledged, so reconnecting catches up on what was missed exactly once rather than replaying or skipping it. - **If the till goes away, the phone stops**: A phone that loses the till stops its camera and says so, instead of quietly queueing scans nothing will read. ##### What the phone scanner carries ##### Pair with a code on screen The till shows it, the phone camera reads it, and the phone confirms which till it is joining. ##### No app and no login An ordinary web page. The link leaves the address bar once paired, and dies with the tab. ##### Straight into the open sale Scan, adjust a quantity, remove a line. The till resolves every code against its own catalogue. ##### Camera, typing, or a photo If the camera will not read a damaged label, type it or photograph it: both go the same way. ##### Codes that expire Ten minutes to pair, thirty minutes at most, three minutes of silence to end it. ##### Role-gated and revocable Only some roles can pair a phone, the till can disconnect it, and the shop can switch it off entirely. ##### Survives a bad connection Numbered, acknowledged events, so a reconnect catches up exactly once. ##### Or use the scanner you own Any USB or Bluetooth scanner that types like a keyboard works at the desktop, alongside this. ##### The questions owners ask before handing over a phone **We'd rather buy a real scanner.** Then buy one: any USB or Bluetooth scanner that behaves like a keyboard works at the desktop, and nothing here replaces it. This is for the second counter, the stock delivery on the floor, and the week you need three tills instead of one. **What can someone see on that phone?** The sale in front of them: the lines, their prices and the total. Not cost, not margin, not the supplier, not the customer's name or number, and never a full IMEI: a serialised unit shows as a six-character tail. **Can they change a price or take the money?** No. The phone scans and adjusts quantities. Pricing, discounting and payment stay at the till under the role of whoever is on it. **What if they walk off with the phone still connected?** The session ends by itself: three minutes of silence, and thirty minutes maximum however active it is. You can also disconnect it from the till, and completing the sale ends it. **Does it work on an old phone?** It uses the browser's own barcode support where the phone has it and falls back to a decoder it loads on that page otherwise, which covers most iPhones. If the camera struggles with a damaged label, there is manual entry and a photo upload. **Where does the phone scanner work?** At the till: pair a phone from a QR code and every scan lands straight in the sale. Stocktakes and goods-in have their own scanning at the desk, by USB scanner or the device camera. --- ## Purchase orders & receiving Source: https://pro.slickcell.com/features/procurement #### What you ordered, what turned up, and what you owe for it Three numbers that should always agree and usually do not. An order, a delivery and a bill are separate events. This keeps them attached to each other so the difference is visible the day it happens, not at year end. ##### Where an order and its stock come apart None of this is carelessness. It is what happens when the order lives in a message thread and the stock lives in a spreadsheet. - An order is placed over WhatsApp and nobody else in the shop can see what was ordered. - Half the delivery arrives; the rest is remembered by one person until they are off sick. - Stock is booked in at the old price, so margin looks better than it is. - A supplier invoice arrives and nobody can tell which delivery it is for. - A faulty part goes back to the supplier and is never credited. - The same part is ordered twice because the first order was never recorded. ##### Order, receive, bill, settle Each step is a record that points at the one before it, so the trail from order to payment stays intact. - **Raise**: A purchase order against a supplier, with the lines and costs you expect. - **Send**: The order leaves as a document the supplier can work from. - **Receive**: Book in what actually arrived: the whole order or part of it. - **Cost**: Receiving recalculates the moving-average cost of what you now hold. - **Bill**: The supplier bill is the payable, raised against the receipt. - **Pay**: Payments settle against the bill, so the outstanding balance is real. - **Return**: Faulty or wrong stock goes back on a record, not on trust. Because receiving is what moves stock and sets cost, the shelf, the cost of goods and the supplier balance all change from the same event. ##### A part order, all the way through The records a stockroom actually works from. ##### Receive six of the ten you ordered Book in the quantity that arrived, line by line. The order stays open on the remainder and says so, Partially Received is its own state, not a note in a comment box. When the rest turns up, it is received against the same order. ##### Margin based on what you actually paid Receiving recalculates the moving-average cost of the stock you hold, so a price rise reaches your margin the moment it reaches your shelf. The old cost does not linger, and the profit report does not flatter you. ##### The supply chain stops being a memory test - **One place to look**: What is on order, what is part-delivered and what is still owed, visible to anyone on the counter, not just whoever placed the order. - **Supplier balances that are real**: Bills are the payable and payments settle against them, so an outstanding figure is something you can act on. - **Returns that get credited**: Stock sent back to a supplier is a record with a state, so it can be chased. - **Costs that stay honest**: Receiving sets cost. Margin reflects the price you actually paid for the stock you actually hold. Every SlickCell Pro feature is included on every plan: plans differ by team size, locations, discounts and support. ##### The awkward ones, handled Ordering is easy. It is the exceptions that decide whether a system survives contact with a stockroom. - **Only part of the order arrives**: Receive the lines that came. The order moves to Partially Received and keeps the outstanding quantity, so it can be chased on what is actually missing. - **The rest is never coming**: An order can be closed short without destroying the record of what was ordered: the history of the shortfall survives. - **The price changed between order and delivery**: The receipt carries the cost you were actually charged, and the average cost of your stock moves with it. - **The bill covers more than one delivery**: A bill is its own record raised against what was received, rather than being forced to match one order exactly. - **Stock arrives faulty**: It goes to a return record against the supplier rather than onto the shelf, and stays visible until it is credited. - **A refunded item comes back from a customer**: It lands in a holding area marked used: never straight back into sellable stock. Inspect it, then restock it as used or send it back to the supplier. - **Two people order the same part**: Open orders are visible to the shop, not private to the person who raised them. None of these need a workaround. They are states the records already carry. ##### What purchasing carries ##### Purchase orders Raise an order against a supplier with the lines and costs you expect to pay. ##### Line-level receiving Book in what arrived, line by line, and leave the order open on the rest. ##### Goods received notes A receipt is its own record: what came, when, and against which order. ##### Supplier bills The bill is the payable. Payments settle against it, so outstanding means outstanding. ##### Returns to supplier Faulty and wrong stock goes back on a record that stays open until it is credited. ##### The trail stays joined Order, receipt, bill and payment each point at the one before it. ##### What stockroom managers ask **We only order from three suppliers. Is this overkill?** The number of suppliers is not what makes ordering go wrong: part-deliveries, price changes and uncredited returns are, and those happen with three suppliers as easily as with thirty. If your orders already reconcile perfectly, this will feel like paperwork. If you have ever paid for stock that never arrived, it will not. **Does receiving stock change my selling prices?** No. Receiving sets what the stock COST you, and recalculates the moving average across what you hold. Selling prices are yours to set and are never moved for you. **Can I raise a bill without a purchase order?** Yes. A bill can be posted on its own, because real supplier invoices do not always map neatly onto one order. It is still a payable that payments settle against. **What happens to a part-delivered order we know will never complete?** Close it short. The order keeps the record of what was ordered and what arrived, so the shortfall stays visible rather than being erased to tidy the list. **Do you connect to our suppliers directly?** If your supplier also uses SlickCell Pro, yes. You can order against a catalogue they keep current, and they run their own orders, dispatch and discrepancies from their side. For everyone else, an order is a document you send them. --- ## Supplier network Source: https://pro.slickcell.com/features/supplier-network #### Order from your supplier without either of you retyping it Most shops order by email, phone or a portal that belongs to someone else. When your supplier is on SlickCell Pro, your purchase order arrives as their order, the same record, not a copy of it. ##### Where an order and its answer come apart None of this is anyone's fault. It is what happens when two businesses keep the same order in two places. - The order goes out by email and the reply comes back as a price you have to re-key. - Half the lines are in stock, so the order becomes a conversation instead of a document. - A price changed since last time and nobody notices until the bill. - The box arrives short and the only record of what was ordered is in a sent folder. - A part goes back and the credit is agreed verbally, then chased for a month. - You pay, and neither side is sure which invoices it settled. ##### One order, two businesses, no re-keying Each step writes to the next on both sides at once. Neither business is transcribing what the other one said. - **Connect**: Find the supplier in the directory and add them. The link is live immediately. - **Browse**: Their shared catalogue, with the prices and lead times they keep current. - **Order**: Raise the purchase order from your own stock screen; it lands as their incoming order. - **Quote**: They confirm, re-price or offer an alternative: each version kept, with its reason. - **Approve**: You accept the order, or accept some lines and cancel others. - **Reserve**: Approved stock is held against your order rather than sold twice. - **Dispatch**: Confirming the dispatch is the moment stock leaves their inventory. - **Receive**: You book in what arrived: accepted, damaged, missing or wrong, line by line. The two ends of that sequence are the point. What you ordered and what they read are one record, and what they sent and what you booked in are checked against it rather than against memory. ##### Ordered, received, and the gap between them The screen a stock manager actually works from. ##### What you ordered against what turned up Every line carries an ordered quantity and a received quantity, and they are allowed to disagree. A short delivery stays open and visible instead of being closed off as “received” so the paperwork can move on. ##### What you stop spending time on The saving is not the typing. It is the checking that the typing made necessary. - **One version of the order**: No sent folder, no portal login, no “can you confirm what I asked for”. - **Prices you did not transcribe**: Lines come off the supplier's own catalogue, so a stale price is their edit, not your typo. - **A short delivery that stays open**: Booking in what actually arrived leaves the rest outstanding, which is the only state you can chase from. - **Payments with a matching answer**: You record what you paid; they confirm they have it. Both sides can see which is which. - **The awkward conversation has a record**: Discrepancies and returns are a documented flow rather than a phone call nobody wrote down. ##### The orders that are not simple Any system handles a full delivery of everything you asked for. These are the ones that decide whether the numbers survive. - **They can only supply some of it**: The quotation comes back with the lines they can do, and you approve or cancel line by line. A partial order stays one order rather than becoming three. - **The price has gone up since last time**: A re-quote is a new version of the same quotation, with the reason for the revision recorded, so the change is visible instead of arriving on the bill. - **They offer a different part instead**: An alternative is a line-level response you can accept or decline, not a substitution that quietly appears in the box. - **It was agreed over the phone**: Off-platform approvals are recorded as such (the method, the person who agreed and the evidence) and a supplier cannot approve their own quotation. - **Stock is committed but not sent yet**: Approval reserves; dispatch is what removes stock from the supplier's inventory. The two are separate events, so reserved goods are not counted as gone. - **The delivery is split**: A dispatch can cover part of the order, and the rest stays outstanding against the same record. - **Something arrives damaged or wrong**: Receipt is per line and per outcome: accepted, damaged, missing, wrong item or rejected. Only accepted goods enter stock; the rest open a discrepancy instead. - **It has to go back**: A return is authorised through the discrepancy it belongs to, with the supplier's own return instructions attached to it. - **You paid but they have not seen it**: A payment you record is a claim until the supplier verifies it. Unverified claims never reduce a verified balance, so neither side is working from a number the other has not agreed. - **You want to stop ordering from them**: A supplier can be set to take no new orders, or the relationship closed, without deleting the history of what you already bought. Every one of those leaves an entry on the order's activity timeline, visible to both businesses. ##### What the network carries ##### A directory of connected suppliers Find suppliers already on the platform and connect. Adding one from the directory takes effect immediately. ##### Catalogues they keep current Browse a supplier's shared items with their wholesale price, minimum order quantity, pack size and lead time. ##### They choose what you see Sharing can cover everything, a category, or a named list of items, with an expiry, and stock can show as an exact figure, a simple in-stock marker, or not at all. ##### Orders that arrive as orders Your purchase order becomes their incoming order. No portal, no PDF, no re-keying at either end. ##### Quotations with versions Every re-quote is kept with its reason, and you can approve some lines while cancelling others. ##### Reserve, then dispatch Approving holds the stock against your order. Confirming the dispatch is the single point at which it leaves their inventory. ##### Payment claim and verification You record the payment; they confirm it. A claim awaiting verification never quietly reduces the balance either of you is working from. ##### Messages against the thing they are about A conversation attaches to the relationship, the order or the discrepancy, so it is findable later by what it concerned. ##### Rate the orders you received Buyers rate a completed order across several categories, and the supplier can reply once. ##### The questions buyers and suppliers actually ask **Our supplier isn't on it. Is this useless to us?** No. Purchase orders, receiving, bills and returns all work against your own supplier records whether or not the supplier uses SlickCell Pro. That is the ordinary purchasing module and it is on every plan. The network is what happens when they are on it too: the order stops being an email. **How does a supplier get on it?** They sign up and choose “Supplier / wholesaler” when setting the shop up, which puts them on the Supplier Pro plan and turns on the supplier side of the product. They get everything a shop gets, plus the trade counter their shop customers order from. **Does connecting to a supplier let them see our business?** They see what a supplier sees: the orders you send them, the messages on those orders, and what you have paid against them. Your stock, your customers, your prices and your other suppliers are not part of it. **Can a supplier show different customers different things?** They can share their whole catalogue, one category, or a named list of items, with each grant given per customer and able to expire. They also choose whether you see an exact stock figure, just whether an item is available, or nothing. **What stops reserved stock being sold twice?** Approving an order reserves against it, and stock leaves the supplier's inventory only when a dispatch is confirmed. Reserving and sending are two separate events, which is what makes a reservation mean anything. **What if we pay and they say they haven't had it?** That is exactly the case this is built for. A payment you record is a claim; the supplier verifies it. Until they do it is visible to both of you as awaiting verification, and it does not move the verified balance either way. --- ## Reports & tax Source: https://pro.slickcell.com/features/reports #### Figures you can open, not figures you have to believe A report is only worth having if you can ask it where a number came from and get an answer. Every total here is computed on the server from the full dataset, and every total opens onto the records underneath it. ##### Why nobody trusts the reports Not because the arithmetic is wrong. Because nothing tells you what went into it. - The dashboard, the invoice list and the tax return give three different totals for the same month. - Profit looks healthy because the cost of the parts was never counted against it. - Tax is worked out by dividing a total, so a mixed sale quietly reports the wrong figure. - A number looks wrong and there is no way to see what it is made of. - The report only covers what happened to be loaded on screen. - Month-end is a spreadsheet someone rebuilds by hand, every month. ##### From the event to the total The chain below is why the number can be opened. Each link is a record, not a calculation someone ran once. - **The event**: A sale, a repair, a part used, a payment taken. - **The line**: Its economics are persisted on the line, not recomputed later. - **The movement**: Stock used becomes a movement with a real cost. - **The ledger**: Money in and out lands on the account it belongs to. - **The total**: The server aggregates the whole dataset for your date range. - **The drill-down**: Open the total and see the records that produced it. Because cost of goods comes from actual stock movements and tax from the stored breakdown, profit is not an estimate laid over revenue. It is what is left after the things that actually happened. ##### A total, and what it is made of The screen an owner checks on a Monday. ##### Every headline opens onto its own records A revenue figure is not a number on a card. Open it and you get the invoices behind it, each with its own discount, tax and payment history. If a figure looks wrong, you can find out why in the report rather than in a spreadsheet. ##### What actually came in and went out Takings, manual income, expenses, supplier payments, refunds and trade-in payouts, day by day, with an opening and closing balance. It is the view that answers 'where did the cash go' without anyone reconstructing it. ##### Month-end stops being a rebuild - **One set of numbers**: The report, the invoice and the dashboard read the same ledger, so they cannot disagree about the same month. - **Profit after real costs**: Cost of goods comes from the stock that was actually consumed, not from a margin assumption. - **Tax from the breakdown**: Tax is read from what was stored on each line, never back-computed by dividing a total: which is where mixed-rate sales usually go wrong. - **Per branch or across the group**: Filter to one shop or read the whole group, from the same reports. Every SlickCell Pro feature is included on every plan: plans differ by team size, locations, discounts and support. ##### Where reporting usually goes wrong These are the specific ways a shop's numbers stop adding up. - **A sale mixes tax rates**: Each line carries its own tax, and the report reads the stored breakdown. Nothing is inferred by dividing the total by a single rate. - **A used device sold on the margin scheme**: Margin tax is reported separately from standard tax rather than being blended into one figure that suits neither. - **A refund lands in a later month**: It reduces the period it actually happened in. Revenue for a closed month is not silently rewritten. - **A discount is given on the whole basket**: It is apportioned across the lines, so both revenue and tax reflect it. - **There are more rows than the page can hold**: Totals are computed on the server across the whole range, so a busy month is not quietly truncated to what loaded. - **A number still looks wrong**: Open it. The drill-down shows the records behind the total, which is usually enough to find the entry that caused it. This is general reporting, not tax advice. Check the rules that apply where you trade, or speak to your accountant. ##### What reporting covers ##### Revenue and profit Takings and what is left after the cost of the goods that produced them. ##### Tax and refunds Read from the breakdown stored on each line, with margin tax kept separate. ##### The money account Daily money in and out, with opening and closing balances. ##### Inventory and stock counts What you hold, what it is worth, and what counts and trade-ins did to it. ##### Workforce Output per technician, with payroll cost taken from real payroll runs. ##### Drill-down on everything Open any headline figure and see the records that produced it. ##### What owners and accountants ask **Are these figures calculated in my browser?** No, and that is deliberate. Each report is a server-side query over your full dataset for the date range you chose. Client-side aggregation can only ever total the rows that happen to be loaded, which is exactly how a busy month silently under-reports. **How is tax worked out?** From the tax breakdown stored on each line when the sale happened: never by dividing a total by a rate afterwards. That distinction matters the moment one sale contains items at different rates, or a used device sold under a margin scheme. **Does profit include the cost of parts?** Yes. Cost of goods is computed from the stock movements that actually happened, so a repair's profit is net of the part that was fitted, at the cost you actually paid for it. **Can I see one branch on its own?** Yes. Every report can be filtered to a single branch or read across the whole group, from the same screen. **Can I give my accountant access without giving them everything?** Yes. The accountant role sees the financial reporting it needs and is kept out of the operational actions it does not: refunds, for instance, are not theirs to issue. **Does this replace my accountant?** No. It gives you numbers that reconcile and records that can be inspected, which is what makes your accountant's job cheaper. What the rules are where you trade is still their question to answer. --- ## Cash drawer & cashbook Source: https://pro.slickcell.com/features/cash-control #### What was in the drawer, what the day says, and the difference between them Open on a float, close on a count, and see the gap stated rather than absorbed. Then read every pound that moved, in and out, as a statement with a running balance. ##### How a drawer stops agreeing with anything Nobody decides to lose track of cash. It happens one unrecorded movement at a time. - The float goes in and nobody writes down how much. - A supplier is paid out of the till and the note goes missing. - A refund is handed over in cash and the day's takings quietly stop matching. - The till is counted, it is £12 out, and £12 is not worth an argument, so nothing is recorded. - A month later the shop is consistently short and there is nothing to look at. - The bank does not match the takings, and nobody can say which of the two is wrong. ##### A day, from float to close Each step writes to the same session, so the close has something to be measured against. - **Open**: Record the float that is actually in the drawer. - **Trade**: Sales, refunds, payouts and manual entries attach to the open session. - **Count**: At close, count the cash. It is required, not optional. - **Reconcile**: Expected against counted, with the difference shown rather than absorbed. - **Bank and card**: Count them too, or say you did not: the two are different answers. - **Close**: The session is stamped with every expected, actual and difference figure. - **Read the ledger**: The day joins a running statement of money in and money out. The point is the fourth step. A count that cannot disagree with anything is not a count. ##### Money in, money out, and what is left Not a profit statement. A statement of cash, which is a different and more immediate question. ##### Totals that open onto their records The reports read from the same ledger the till writes to, and a figure can be opened to see the records underneath it. A number you cannot open is a number you have to trust. ##### What you can answer at the end of a week - **Whether the drawer is right**: Not roughly. Counted against expected, with the difference kept. - **Where the difference lives**: A shop that is short on Tuesdays is a pattern. It only exists if the small differences were recorded. - **What actually left the business**: Supplier payments, refunds, trade-in payouts and expenses, in one place, in date order. - **Cash against card**: Counted separately, and allowed to be uncounted, because “we did not check the card machine” is a real answer. - **A balance that carries**: Each day opens on the closing position of everything before it, so a period is never read in isolation. ##### The awkward days - **Somebody took a payment before opening the till**: The movement is still attached to a session: one is opened for it, on a zero float, marked as having been opened automatically. The prompt to open the counter is there to stop that happening; the ledger is built so that when it does, nothing is left unaccounted. - **The count is out by a few pounds**: Record it. The difference is stored with the session rather than rounded away, which is the only reason next month's pattern will exist. - **Nobody checked the card machine**: Leave bank and online uncounted. That is stored as “not counted”, which is a different fact from “counted, and it was zero”. - **A supplier was paid from the drawer**: It reaches the session as a cash movement out, so the expected figure at close already knows about it. - **A refund was given in cash**: Same: the drawer is expected to be lighter, and the ledger shows it as money out rather than as missing revenue. - **Rent, wages or a one-off expense**: Recorded as a manual entry against a category, in or out, with the method it was paid by. Cash entries wait for an open counter like anything else. - **Two people want to close the till**: There is one open session per shop, so there is one close, and it is the one everyone is looking at. - **The accountant needs the figures**: Reading the ledger is open to owners, managers and the accountant role. Writing entries is owners and managers only, enforced by the database rather than by hiding a button. ##### What cash control carries ##### Open on a float One open session per shop, with the starting cash recorded rather than assumed. ##### Movements attach themselves Sales, refunds, supplier payments and trade-in payouts join the open session as they happen. ##### Close on a real count Counted cash is required. Bank and online can be counted, or explicitly left uncounted. ##### The difference is kept Expected, actual and difference are stored for cash, bank and online, and stay on the session. ##### A bank-statement view Opening balance, money in, money out and a running balance, newest first, day by day. ##### Open a day to see it Each day breaks down into the movements that made it, so a total is never the end of the trail. ##### Manual money in and out Rent, wages, an owner top-up, an insurance payout: categorised, dated and attributed. ##### Read and write are different rights Owners, managers and accountants can read it. Only owners and managers can write to it. ##### The questions owners ask about counting the till **We count the till at night anyway. What does this add?** Something to count against. A count on its own tells you what is in the drawer; a count against an expected figure tells you whether that is the right amount, and stores the difference, so a recurring shortfall becomes visible instead of being absorbed each night. **Does the till stop working if nobody opened the counter?** No, and it deliberately does not: refusing a customer's cash because of a bookkeeping step would be the wrong trade. You are prompted to open it, and if a cash movement happens anyway a session is opened for it automatically, on a zero float and marked as such. The ledger never ends up with cash that belongs to nothing. **Can I print a Z-report?** There is no printed close report. Closing produces a record you can open on screen: the expected and counted figures, the difference, the cash movements in that session and its event history. **Is this our profit and loss?** No, and the difference matters. This follows cash: what came in, what went out, what is left. Issuing an invoice does not appear here because no money moved, and wages only appear if you enter them. Profit is a separate report. **What if the card machine total does not match?** Count bank and card at close and the expected figures are there to compare against, with their own differences recorded. If nobody checked, leave them uncounted. That is stored as a distinct answer rather than as a zero. **Who can see it?** Owners, managers and the accountant role can read the ledger. Only owners and managers can add, edit or void an entry, and that is enforced on the server rather than by hiding controls. --- ## Workforce Source: https://pro.slickcell.com/features/workforce #### Let the shop use the system without handing over the shop A Saturday assistant needs to book a repair in. They do not need to see what the parts cost, void an invoice or read the payroll. Permissions here are enforced by the database, not by hiding buttons. ##### Where staff access goes wrong Usually not through malice. Through everyone having one login because splitting it was too much trouble. - Everyone signs in as the owner, so the audit trail says the owner did everything. - A technician can see the cost price of every part on the shelf. - Anyone can void an invoice, and nobody can say who did. - Hours are on a paper rota and re-typed into a spreadsheet at month end. - A pay rate changed mid-month and the whole month got paid at the new one. - Who is actually busy is a question you answer by walking to the bench. ##### From a new starter to a paid month The same record carries the person, what they may do, what they worked and what that cost. - **Add the person**: An employee record, with their documents kept against it. - **Give them a role**: One of five, deciding what they can see and do. - **Set the rate**: Pay rates are effective-dated, so a rise starts when it starts. - **Work the queue**: Jobs are assigned, and load is measured from real assigned work. - **Record attendance**: Hours and leave against the employee, with adjustments audited. - **Run payroll**: Attendance is priced at the rate in force on each day. - **Payslip**: A document produced from the run, and a cost the reports can see. Because the rate is effective-dated, a mid-month rise is applied from the day it took effect rather than being smeared across the whole month. ##### Permissions that are actually enforced The part most systems get wrong. ##### Owner, manager, technician, sales, accountant Each role gets its own view of each area (none, read, or full) and on top of that, whole groups of fields can be hidden. That is how a technician works a ticket without ever seeing what the part cost. The rules live in the database, so they hold whether the request comes from the app or not. ##### Who is busy, measured from actual jobs Technician load comes from the minutes of work actually assigned and still open, against the capacity of a day. It is a figure derived from the queue, so it moves when the queue moves. ##### Everyone gets their own login, and it is safe to give them one - **The audit trail names a person**: Because everyone signs in as themselves, 'who did this' has an answer. - **Costs stay behind a role**: Field-level visibility keeps cost and margin away from the roles that do not need them. - **Hours become a payroll input**: Attendance is priced against the rate that applied on the day, not the rate today. - **Workload is visible**: Who is loaded and who is free comes off the job queue rather than off a guess. Every SlickCell Pro feature is included on every plan: plans differ by team size, locations, discounts and support. ##### The ones that decide whether staff access works - **A technician needs to order a part but not see its cost**: Role permissions are per-area, and field groups are separate again, so the action and the figure are two different decisions. - **Someone's pay rate changes mid-month**: Rates are effective-dated. The days before the change are priced at the old rate and the days after at the new one. - **A leave balance was wrong and needs correcting**: The correction is an adjustment with a record behind it, not an edit to a number that leaves no trace. - **The accountant needs the figures but should not issue refunds**: That is exactly what the accountant role is: financial reporting without the operational actions. - **Someone leaves**: Their access is removed while their history stays intact: the work they did does not detach from the record. - **A manager covers a shift at another branch**: Membership is per-shop, so access follows where they actually work. Statutory deductions are not calculated here. See the questions below. ##### What workforce carries ##### Employee records The person, their details and their documents in one place. ##### Five roles, server-enforced Owner, manager, technician, sales and accountant: enforced by database policy. ##### Attendance and leave Hours and absence against the employee, with corrections recorded as adjustments. ##### Effective-dated pay rates A rise applies from the day it takes effect, not across the whole month. ##### Payroll runs and payslips Attendance priced into a run, producing a payslip and a cost the reports can see. ##### Output and load What each technician completed, and how loaded they are right now. ##### What owners ask about staff and pay **How does it work with payroll?** It does the work before payroll: it records hours, prices them against effective-dated rates, adds commission, produces a payslip and gives your reports a real labour cost. Hand the figures to your payroll provider or accountant, who handle tax, deductions and filing. **Are the permissions real, or just hidden buttons?** Real. The rules are mirrored into database policy, so a role that cannot do something cannot do it regardless of how the request arrives. Hiding the button is the presentation of the rule, not the rule. **Can I stop technicians seeing what parts cost?** Yes. Beyond area-level permissions there is field-group visibility, and cost and margin are one of those groups. A technician can consume a part on a job without the cost being on their screen. **We are four people. Do we need roles?** Four people is exactly where it starts to matter, because it is the size where everyone shares one login and the audit trail becomes useless. The value is not restriction, it is being able to answer who did something. **What does it track for each person?** Shifts, attendance and leave, for every employee profile, including staff who never sign in. Hours feed the payroll run and the labour cost in your reports automatically. **How is technician workload worked out?** From the work actually assigned and still open, measured in minutes against a day's capacity. It is derived from the job queue, so it reflects what is really on the bench. --- ## Multi-branch Source: https://pro.slickcell.com/features/multi-branch #### Three shops, one set of numbers, without merging the stock Branches need to be genuinely separate (their own stock, their own staff, their own takings) and still roll up into one view an owner can read. Sharing one database with a branch column gets that wrong in both directions. ##### Where a second shop breaks the system Most shop software is built for one location and grows a branch field later. - Each branch runs its own copy, and the group total is a spreadsheet someone builds on Sundays. - Stock shows as available when it is available at the other shop, forty minutes away. - A staff member covering another branch has to borrow someone's login. - Takings are compared between branches by exporting two reports and lining them up by hand. - One shop closes and unpicking its records takes a fortnight. - Nobody can see how the group is doing without asking each manager. ##### Separate shops, grouped by ownership Each branch is a shop in its own right. The group is what sits above them. - **A branch is a shop**: Its own stock, staff, tickets, takings and settings. - **Grouped by owner**: Branches belong to one organisation you control. - **People, not logins**: A person can belong to several shops under one account. - **Pick a shop**: You choose which branch you are working in when you sign in. - **Read one, or read all**: Every report filters to a branch or covers the group. - **Close one down**: Archiving checks what the branch still owes before it goes. Because a branch is a shop rather than a filter on shared rows, one branch's stock genuinely is not another's, and the group view is a roll-up rather than a rule that has to be remembered everywhere. ##### The owner's view and the counter's view Two different jobs, from the same records. ##### The group, without leaving the dashboard Switch the dashboard to all branches and the KPIs cover the group. Reports carry a branch filter throughout, so 'how did we do' and 'how did the High Road do' are the same screen with a different setting: not two different exports. ##### Archiving asks what is still outstanding first Before a branch can be archived, the server checks what it still holds (open jobs, unsettled money, stock, staff) and hands back the list, grouped, with a route to each one. Closing a shop becomes a checklist rather than a discovery process. ##### Growing to a second shop stops being a migration - **Stock stays where it is**: Each branch's stock is its own, so availability means available here. - **One person, several shops**: Staff who cover more than one branch use their own account in each. - **Group numbers on demand**: The roll-up is a setting on the reports you already read, not a separate exercise. - **Closing down is controlled**: A branch cannot be quietly archived while it still holds open work or unsettled money. Additional locations are a per-branch add-on. See pricing for what each plan includes. ##### The ones that decide whether multi-site works - **A customer bought at one branch and comes back to another**: Each shop keeps its own records, so the branch that served them holds the history. Plan for this when you decide how to split shops. - **A manager covers two branches**: They hold membership of both under one account, and choose which they are working in at sign-in. - **The group needs one view for the accountant**: Reports read across the whole organisation, so the accountant does not need a login per shop. - **A branch still has open repairs when you want to close it**: The archive preflight lists them, grouped, with a route to each. It will not archive around them. - **Branch limits on the plan**: How many branches a plan allows is enforced server-side, so it cannot be exceeded by accident. - **One branch prices differently to another**: Settings are per shop, so pricing and tax rules do not have to be identical across the group. ##### What multi-branch carries ##### A branch is a real shop Its own stock, staff, takings and settings: not a column on shared rows. ##### Branch switcher Move between the shops you belong to without signing out. ##### All-branches view Dashboard KPIs and reports across the whole group, or filtered to one. ##### One person, several shops Membership is per shop, so staff who cover branches keep their own account. ##### Guarded archiving A server preflight lists what a branch still owes before it can be closed. ##### Limits enforced server-side Branch and team limits hold in the database, not just in the interface. ##### What multi-site owners ask **Is a branch just a filter, or is the data really separate?** Really separate. A branch is a shop in its own right, grouped with your others by ownership, the same isolation that separates two unrelated businesses. That is why one branch's stock is genuinely not another's, rather than being a rule the software has to remember to apply everywhere. **Can I see all three shops at once?** Yes. The dashboard has an all-branches view, and every report carries a branch filter, so the group total and a single shop's numbers come from the same screen. **Can stock move between branches?** Stock is held per shop and there is no automatic rebalancing between them. If you want a handset moved, it moves as stock leaving one shop and arriving at another. We would rather say that plainly than imply a transfer feature that does more than it does. **Does each branch cost extra?** Yes: additional locations are a per-branch add-on, and how many a plan includes is enforced in the database rather than on trust. Pricing has the detail. **What happens when we close a branch?** Archiving runs a server-side check first and hands back everything the branch still holds (open jobs, unsettled money, stock, staff) grouped, with a route to each. You clear them, then archive. **Do our shops share customers and stock?** Each shop keeps its own customers, stock and purchasing, so every branch runs cleanly on its own figures, while group reports read across the whole organisation for you and your accountant. --- ## Pricing Source: https://pro.slickcell.com/pricing #### Pricing that scales with the shop Every SlickCell Pro feature is included on every plan: plans differ by team size, locations, discounts and support. Start the trial yourself: no sales call, no card, and nobody has to ring you back before you can look at it. ##### Four plans, one feature set Flat monthly pricing. Never per device, never per transaction. **Starter**: £39/month or £390/year, excluding VAT. One location, everything you need to open up and trade. - Every SlickCell Pro feature included - 3 app-access users - 5 employee profiles - Single location - Hosted in London - Manual one-off discounts - Standard email support **Professional**: £59/month or £590/year, excluding VAT. Multiple locations, discount rules and priority processing. - Every SlickCell Pro feature included - 10 app-access users per branch - 15 employee profiles per branch - Multiple locations - Discount rules, promo codes & automatic campaigns - Priority large-job processing - Custom domain - Priority email support - Additional branches £29.00/mo each **Supplier Pro**: £99/month or £990/year, excluding VAT. Adds Supplier Operations: sell to other shops from your own catalogue. - Every SlickCell Pro feature included - 15 app-access users per branch - 25 employee profiles per branch - Multiple locations - Supplier Operations included - Discount rules, promo codes & automatic campaigns - Priority large-job processing - Custom domain - Priority support - Additional locations £59.00/mo each **Enterprise**: price on application. Tailored to your organisation. - Every SlickCell Pro feature included - Unlimited app-access users - Unlimited employee profiles - Unlimited locations - Supplier Operations included - Discount rules, promo codes & automatic campaigns - Super-fast large-job processing - Custom domain - Separate dedicated database - Dedicated account manager - Priority or contractual support #### What actually changes between plans Team size, locations, discounts, processing priority and support: nothing else. | | Starter | Professional | Supplier Pro | Enterprise | |---|---|---|---|---| | Every SlickCell Pro feature included | Yes | Yes | Yes | Yes | | App-access users | 3 | 10 per branch | 15 per branch | Unlimited | | Employee profiles | 5 | 15 per branch | 25 per branch | Unlimited | | Locations | Single | Multiple | Multiple | Unlimited | | Additional location / branch | No | £29.00/mo each | £59.00/mo each | Included | | Discounts | Manual one-off | Rules, promo codes & automatic campaigns | Rules, promo codes & automatic campaigns | Rules, promo codes & automatic campaigns | | Large-job processing | No | Priority | Priority | Super-fast | | Custom domain | No | Yes | Yes | Yes | | Data hosted in London | Yes | Yes | Yes | Yes | | Supplier Operations | No | No | Yes | Yes | | Separate dedicated database | No | No | No | Yes | | Dedicated account manager | No | No | No | Yes | | Support | Standard email | Priority email | Priority | Priority or contractual | ##### The things worth knowing before you choose Short answers. If yours isn't here, book a demo and ask directly. **How much does repair shop software cost?** SlickCell Pro starts at £39.00 a month excluding VAT for a single location, rising to £59.00 for multiple locations and £99.00 with Supplier Operations. Enterprise is priced to the organisation. Yearly billing costs ten months instead of twelve, so two months are free. **Is there a free trial?** Yes: fourteen days on the plan you choose, with every feature available. You are trialling the same product a paying shop uses, not a cut-down version, so you can put real repairs and real stock through it and see whether the numbers come out right. **Is there a free plan?** Every plan starts with a fourteen-day free trial with every feature switched on, and no card. After that, plans start at £39.00 a month excluding VAT, flat: no per-transaction fees, no per-device charges and nothing capped that you need to trade. **What is the difference between app users and employee profiles?** App-access users are the people who sign in and use the system. Employee profiles are the staff records you keep (for rotas, attendance and job assignment) whether or not that person logs in. A technician who never touches the till needs a profile, not a seat. **How much does an extra branch cost?** Additional locations are £29.00 a month each on Professional and £59.00 a month each on Supplier Pro, both excluding VAT. Starter is a single-location plan. Enterprise includes additional locations in its pricing. Each branch keeps its own stock and staff under one login. **Can I change plan later?** Yes. Plans are a ladder rather than separate products, so moving up or down changes your team size, locations and support level without changing the software you are using. Every feature is on every plan, so you never lose a capability by moving. **Do I have to use your card machine?** No. Keep the card machine you already have, from whichever provider gives you the best rate. SlickCell Pro records card, cash and split payments on the sale and takes no cut of your takings, so your monthly bill is the plan price and nothing else. **Do you charge per transaction?** No. There is no per-transaction charge, no per-device charge and no percentage of your takings. The plan price is flat, so a busy month costs the same as a quiet one and you can budget for it without checking your volume first. --- ## Security Source: https://pro.slickcell.com/security #### Your shop's data, hosted in London and locked to your shop Customer records, unlock codes, stock and takings are the most sensitive things a repair shop holds. Here is exactly how SlickCell Pro protects them, on every plan, from the day you sign up. ##### In London, encrypted, and separate from every other shop - **Hosted in London, on every plan**: Your shop's database runs in a London data centre (AWS eu-west-2). That is the same on Starter as on Enterprise: UK data residency is not an upgrade you have to ask for. - **Encrypted in transit and at rest**: Every connection to SlickCell Pro is encrypted with TLS, and the database is encrypted at rest with AES-256. That covers the app, the till, the phone scanner and the customer tracking page. - **Every shop sealed off from every other**: Row-level security is switched on for every table in the database. Each query is checked against the shop you belong to by the database itself, so another shop's records cannot be reached from the app, from the API or by a changed link. The rule is covered by automated database tests. ##### Staff see what their job needs, and nothing more - **Roles enforced by the database**: Owner, manager, technician, sales and accountant each see and change only what the role allows. The rule lives in the database, not just in hidden buttons, so a permission cannot be sidestepped from outside the screen. - **Money-moving actions limited**: Voids and write-offs are limited to owners and managers. Editing a sold unit or handing a device over unpaid asks for a reason, and the reason is kept with the record. - **Two-factor sign-in**: Every account can add an authenticator app, so a stolen password alone does not open the shop. Switching it off needs both the password and a current code. - **Customer unlock codes kept apart**: Device passcodes are stored separately from the customer record and are revealed only to the roles that work on the device. Every reveal is logged with who looked and when. - **Automatic sign-out**: A till left open signs itself out after the period of inactivity you choose, with a warning first. ##### A record of every change, and your data always yours - **Append-only audit trail**: Changes to repairs, stock, customers, invoices and payments are written to an audit trail with who made them and when. Entries are added, never edited, and only owners and managers can read them. - **Paid invoices cannot be rewritten**: Once an invoice is settled it is locked. A refund or correction is a new entry that points at the original, so the history your accountant reads is the history that happened. - **Deleted records can be restored**: Deleting a record moves it to the bin first, where it can be brought back. Nothing important disappears because of one wrong click. - **Export whenever you like**: Repairs, stock, payments, profit and loss, tax and payroll reports export to CSV at any time, from the screen you are already on. Your records are yours to take to your accountant, or anywhere else. ##### No card numbers held, and eyes on the system around the clock - **We never store a card number**: Your subscription is paid on Stripe's own secure pages, and Stripe is certified to PCI DSS Level 1. At the till, card takings are recorded by amount and method on the sale, so no customer card data ever passes through SlickCell Pro. - **Monitored around the clock**: Errors in the app and on the server are reported to us the moment they happen, with customer personal data stripped out before the report is sent. ##### What shop owners ask us **Where is SlickCell Pro data hosted?** In London. Your shop's database runs in AWS's London region (eu-west-2) on every plan, including Starter. UK data residency is standard, not an enterprise add-on, and the data is encrypted in transit (TLS) and at rest (AES-256). **Can another shop see my data?** No. Row-level security is enabled on every table, so the database itself checks every request against the shop you belong to. Another shop's records cannot be reached from the app, from the API, or by editing a link, and automated database tests cover that rule. **Who can see a customer's unlock code?** Only the roles that work on the device. Passcodes are stored apart from the customer record, an accountant login never sees them, and every reveal is logged with the name of the person and the time. **Does SlickCell Pro store card details?** No. Your subscription is paid on Stripe's PCI DSS Level 1 pages, and card sales at the till are recorded by amount and method only. Keep the card machine you already have: SlickCell Pro takes no cut of your card takings. **Does SlickCell Pro support two-factor authentication?** Yes. Any account can add an authenticator app, so a password on its own is not enough to sign in, and turning it off needs the password and a current code. **Can I get my data out?** Yes, at any time. Repairs, stock, payments and every report export to CSV from the screen they are on, so your accountant gets the same figures the app shows, and moving your records never depends on asking us. --- ## Integrations Source: https://pro.slickcell.com/integrations #### What SlickCell Pro connects to Your card machine, your printers, your scanners, your suppliers and your accountant. Everything on this page works on every plan, from the day you sign up. - Each section says what the connection does and where you find it in the product. ##### Your own card machine - Keep the card machine you already have, from whichever provider gives you the best rate. Take the payment on the terminal and the till records it on the sale, split with cash if needed, so the sale, the receipt and the day's report agree. SlickCell Pro takes no cut of your card takings. ##### Stripe, for your subscription - Your SlickCell Pro plan is billed through Stripe. Checkout, the card on file, plan changes, cancellation and reactivation all run on Stripe's own secure pages, so your card details are never held by us. ##### Exports for your accountant - Profit and loss, VAT including the margin scheme, payments, the account ledger, stock and payroll export to CSV from the report you are reading. Your accountant works from exactly the figures the app shows, and customer statements download as PDF. ##### Your suppliers, connected - Suppliers on SlickCell Pro publish a live catalogue to the shops they serve. Your purchase order lands directly in their account: they confirm or re-quote, reserve and dispatch, and you book in what actually arrived. Suppliers who are not on the platform receive the same order as a PDF by email. ##### Email updates to customers - Ready-for-collection notices, diagnosis updates and reminders go to customers by email from the job, on templates each shop can edit, and every message is kept on the customer record. Nothing to set up. - Every receipt and repair label also carries a QR code that opens a live tracking page, so customers can check progress themselves without an app or a login. ##### Google sign-in - Staff can sign in with a Google account instead of a password. Access inside the product is still decided by the role the shop gave that person; Google only proves who they are. ##### Barcode scanning: USB, camera, or a paired phone - Any USB barcode scanner that types into the till works as it would in any other program. A device camera can scan too. And a staff phone can be paired to the till from a QR code on screen and used as a scanner for the open sale, with no app to install and no hardware to buy. ##### Stock import from CSV - Parts, accessories and devices import from CSV files as three separate imports, with column mapping, supplier matching and a preview of exactly what will be written before anything is saved. Bring your stock over from a spreadsheet or straight from your old system. ##### Printing and PDF: receipts, invoices, tickets and labels - One document template prints as an A4 page, an 80mm or 58mm receipt roll, or a repair label on stock sizes from 50 by 25 up to 80mm, and the same document downloads as a PDF. Printing goes through the browser's own print dialog, so any printer the computer can already print to will work, with no driver to install. ##### What shops ask about connections **Does it work with my card machine?** Yes, with the one you already have. Take the payment on your terminal and the till records it on the sale, split with cash if needed, so the sale, the receipt and the report agree. SlickCell Pro takes no cut of your takings, so you choose the card provider with the best rate. **How do I get my figures to my accountant?** Export them. Profit and loss, VAT including the margin scheme, payments, the account ledger and payroll export to CSV from the report you are reading, so your accountant works from exactly the figures the app shows. **Which receipt printers work?** Any printer the computer can already print to. Receipts, A4 invoices, repair tickets and labels come off one template and print through the browser at A4, 80mm, 58mm or label sizes, with no driver to install. **How do customers get repair updates?** By email from the job, on a template, with every message kept against the customer. Their receipt also carries a QR code that opens a live tracking page, so they can check the status without ringing the shop. **Do I need a barcode scanner?** No. Any staff phone becomes the scanner: pair it to the till from a QR code on screen and every scan lands in the open sale, with no app to install. A USB scanner or the device camera works too. --- ## Moving from another system Source: https://pro.slickcell.com/migration #### Moving your stock across, without a leap of faith The real question is not whether the software is good. It is whether you can get out of what you are using now, and what happens to the count if the import goes wrong. ##### Export, map, preview, commit The preview is the part that matters. Nothing enters your stock on the strength of a file nobody has looked at. - **Export what you have**: A spreadsheet out of your current system. - **Split by type**: Parts, accessories and devices are three imports. - **Add references**: One IMEI, serial or shop reference per device unit. - **Preview**: See exactly what the import would do before it runs. - **Read the warnings**: Errors and oddities are listed separately. - **Commit**: You choose whether existing stock is updated. Most of the work is the first two steps, and most of the risk is removed by the fourth. A shop moving over usually spends longer tidying its own spreadsheet than running the import. ##### What the import actually does The same ten rules published on the inventory page: one list, so the two cannot disagree. - **Three separate imports**: Parts, accessories and devices come in as three separate imports, because they are three different kinds of thing with three different shapes. - **Quantity for parts, references for devices**: Parts and accessories are imported with a quantity. Device quantity is derived from the unit references you supply, not entered as a number. - **One unit per reference**: Each device unit corresponds to one IMEI, serial number or shop reference. Two units cannot share one reference. - **The reference can be partial**: A full IMEI, a serial number, the last four or five digits, or an internal shop reference are all accepted, stored as free text, with no format or checksum rule to fight. - **Prices in pounds**: Costs and selling prices are entered in pounds, the way they appear on your supplier's invoice. - **Suppliers by ID**: A supplier is selected by its supplier ID, so the same name spelled three ways does not become three suppliers. - **Preview before commit**: You see what the import will do before anything is written. Nothing lands in your stock on the strength of a file you have not looked at. - **Warnings and errors are separate**: Rows that cannot be imported and rows that merely look odd are shown apart, so a genuine problem is not buried among things that are simply unusual. - **Update mode is explicit**: Whether the import updates existing stock is a choice you make deliberately, not a default that quietly overwrites what is already there. - **No barcode required**: The approved import format does not require a barcode, so a spreadsheet from an older system is enough to get started. ##### How shops move over without a gap Stock first, checked against the shelf, while your old system finishes what it started. - **Preview before anything is written**: Every import shows exactly what it will create, with errors and warnings listed separately, before a single record is saved. The preview is the decision point: check it, then commit. - **Start small, then do the rest**: Nothing forces you to bring everything over at once. Importing one category, checking it against the shelf and then continuing is slower on paper and faster in practice. - **Finish open jobs where they started**: Part-finished repairs run to completion on your old system while new work starts in SlickCell Pro, so nothing is moved halfway through a repair. - **A clean set of books from day one**: Your trading history stays in the system that produced it, where your accountant keeps working from it for the closed period, and SlickCell Pro starts clean from your go-live day. - **Every unit enters stock as itself**: If an export has the same IMEI, serial or shop reference on two rows, the preview flags it, so each handset arrives as one unit with one reference. - **Prices read as pounds**: Costs and selling prices import as pounds. A cell holding text, a stray symbol or a blank is listed for you to fix rather than guessed at. Bring your export to a demo call and we will walk through exactly how it maps before you buy anything. ##### You do not have to do it alone What is actually on offer, described as what it is. - **Bring your file to the demo**: We will look at your real export together and tell you what will and will not come across. - **A dry run first**: The preview can be run and read before you commit anything, on your own data. - **Support on every plan**: Email support is included on every plan, with priority levels rising up the ladder. - **No migration fee**: There is no setup charge and no separate migration cost on any plan. Moving your stock across is part of the subscription, not an extra. ##### What shops ask before switching Straight answers about the switch. **Can I bring my existing stock across?** Yes. Parts, accessories and devices import separately, prices are entered in pounds and suppliers are selected by supplier ID. A device reference can be a full IMEI, a serial number, the last few digits or your own shop reference, and you preview what the import will do before anything is written. **What if my file has mistakes?** The preview catches them first. You see exactly what would be written, with errors and warnings listed separately, before anything is saved. Import one category, check it against the shelf, then bring over the rest. **Do my device IMEIs have to be complete?** No. A full IMEI, a serial number, the last four or five digits or your own internal shop reference are all accepted, stored as free text. There is no format or checksum rule to satisfy, so a partial reference from an older system is fine. **What happens to my open repairs and old invoices?** Finish part-finished repairs on your old system and keep its invoices there for your accountant's closed period. Your stock comes across, new repairs start in SlickCell Pro from go-live, and the two never overlap. **How long does moving over take?** Most of the effort is exporting and tidying your own data rather than running the import. We would rather look at your actual file and tell you than quote an average that turns out not to describe your shop. **Can I try it before committing everything?** Yes. Every plan has a fourteen-day trial, and nothing requires you to import your whole shop on day one. Bringing one category across and checking it is the sensible way in. --- ## About Source: https://pro.slickcell.com/about #### Built for the shop, not the demo SlickCell Pro exists because the software a repair shop can actually buy tends to be a till with repairs bolted on, or a ticket system that knows nothing about money. #### The gap between the job and the money - Walk into a busy repair shop and you will usually find three systems running at once: a board or a notebook for the jobs, a till for the money, and somebody's memory for everything in between. Each one works. The trouble is what happens where they meet. - A deposit gets taken and noted on a ticket, but never against the bill. A part comes out of the drawer and the count is corrected at the weekend, if anyone remembers. A customer pays most of it and the rest becomes a discount because that is the only field that fits. None of this is carelessness. It is what happens when the record of the work and the record of the money are two different records. - So the product was built around one idea rather than a feature list: a part used should reduce stock, that movement should land in cost of goods, cost of goods should land in the month's profit, and none of it should be changeable without leaving a trace. Everything else follows from that. ##### Three principles They sound obvious. Most software for this trade breaks at least one of them. - **Money must reconcile**: A part payment is a balance, not a discount. Change is not revenue. Once money is settled, history gets corrected by adding to it rather than by overwriting it. - **Stock must match the shelf**: Quantity is derived from real units, not typed. A device is an individual record with its own cost and history, because that is what it is in the drawer. - **Honest numbers**: A figure should open onto the records that produced it. If a total cannot be traced back to the invoices behind it, it is a guess with a decimal point. ##### Where the work is going Directions rather than dates. - **The supplier side, deepened**: Ordering between two businesses that both use SlickCell Pro is live, and suppliers run their own orders, catalogues and dispatches on it. Next comes the wholesaler's day on one screen: every order and delivery at once, with trade figures that read at a glance. - **The trade's own tools**: Calculators and guides for the parts of the job that are genuinely hard to get right, margin-scheme VAT being the obvious one, built to be useful whether or not you ever buy anything. - **Listening to shops that say no**: The objections that come out of sales conversations change the product and the copy. A shop explaining why this would not work for them is more useful than one saying it looks good. --- ## Partner programme Source: https://pro.slickcell.com/partners #### A partner programme for parts distributors You already know which shops need better software: you sell to them every week. Introduce them, and their subscriptions pay for yours. ##### Five steps, and you only do the first From naming a shop to skipping a bill, with nothing to install and no code to hand out. - **Tell us**: Send the shop's name and who to expect, before they sign up. - **They start**: They sign up and run the fourteen-day trial like anyone else. - **They pay**: Their first paid month is the month your credit is earned. - **It banks**: Credit adds up and does not expire. Three shops is a free month. - **You skip a bill**: Say the word before it goes out and that month is not charged. We match introductions and apply credit by hand, personally, for every partner. #### Bring the shops you already supply, and stop paying for months Every shop you introduce earns credit against your own subscription. Three of them is a month you do not pay for: banked until you want it, and spent on whichever month suits you. | | One free month | Two free months | Three free months | |---|---|---|---| | Shops on Starter | Three | Six | Nine | | Shops on Professional, Supplier Pro or Enterprise | Two | Four | Six | ##### The rules, in full, before you ask Eleven of them. Several are limits rather than benefits, and those are not kept for the bottom. - **It has to be a shop that was not already coming**: A business that is not already a SlickCell Pro customer, and not one of your own locations under another name. A shop that had already started a trial before you told us about it does not count. - **Tell us before they sign up**: Send us the shop's name and who to expect, and we match it when they arrive. There is no referral code in the app and no partner dashboard: while the programme is small we run it by hand, and we would rather say that than show you a screen that does not exist. - **It counts once they are paying**: The fourteen-day trial does not count. A shop earns you credit on the first month it pays for a plan, and the credit is yours from that point. - **A shop earns once**: Credit is for bringing a shop, not for keeping one. A shop you introduced earns its credit on its first paid month and does not earn again, so a free month next quarter means another shop rather than the same three. - **It counts at the plan they start on**: A shop that starts on Starter and moves up later does not earn again on the upgrade. Whichever plan they first pay for is the one their credit is worked out from. - **Plans add up, and remainders carry**: Credit is worked out per shop and added together, so two on Starter and one on Professional make a free month between them. Anything left over is not lost, four on Starter is one free month with credit still in hand towards the next. - **Spend them when you like**: Free months bank up and do not expire. You choose which bills to skip, so a quiet month can be one you do not pay for. Tell us before the bill goes out and we will apply it. - **It comes off your subscription, not your locations**: A free month covers your own plan. Additional locations are charged separately and are not covered by it. - **If you pay yearly**: Free months earned on a yearly term are added to the end of that term rather than paid back, because there is no monthly bill to skip. - **One shop, one supplier**: If two suppliers introduce the same shop it counts for whoever told us first, and we will tell you which it was. - **If we change it**: We can change the programme or close it, and we will give notice before we do. Months you have already earned stay yours. We will not take back credit you were told you had. None of that is conditional on how much they buy from you. Credit follows the shop's subscription, not their orders. ##### What a distributor asks before signing up to this Including who it is not for, and the one thing you need before you can take part. **Who is this for?** Parts distributors and wholesalers who sell to repair shops: businesses that already have a book of shops and a reason to talk to them. It is built around that relationship rather than around advertising: you are not being asked to find strangers, you are being asked to mention us to customers you already speak to every week. **Do I need to be a SlickCell Pro customer myself?** Yes, and it is the one hard requirement. What you earn is free months of your own subscription, so there has to be a subscription to take them off. If you are not on the platform yet, the fourteen-day Supplier Pro trial is the place to start, and anything you introduce while you are on trial still counts once you are paying. **What if I am a repair shop rather than a supplier?** Then this particular programme is not written for you yet. The arithmetic is built around a distributor's book of trade customers, and we would rather say that than take an introduction under terms that do not fit. If you have shops you would introduce anyway, get in touch and we will talk about it properly rather than pretend a page covers it. **Is the partner programme worth anything if I only supply a handful of shops?** Three shops is a month you do not pay for, and two is a month if they are on Professional or above, so the arithmetic starts working at two or three rather than at thirty. What it will not do is pay you: credit only ever cancels your own bill. The plan prices it is measured against are on the pricing page. **Do the shops I introduce have to keep buying from me?** No. Credit follows their subscription, not their orders. If a shop you introduced starts buying from another wholesaler as well, or instead, the month you earned is still yours. They are still a customer here and you are still the reason. We would rather not be in the business of policing who you trade with. **How many shops can I introduce?** As many as you like, and there is no ceiling on what you can earn, nine on Starter is three free months, eighteen is six. Because credit is earned once per shop rather than paid out every month, bringing more is the only way to keep earning, which is exactly the way round we want it. **Is there a referral code or a partner dashboard?** Introductions are handled by hand, personally. You tell us who you are bringing before they sign up, we match them when they arrive, and we apply the free month to your subscription when you ask for it. That is the whole mechanism, with a person on our side at every step. --- ## VAT margin scheme calculator (free) Source: https://pro.slickcell.com/tools/vat-margin-calculator #### VAT margin scheme calculator Work out the VAT on a second-hand phone in one step, and see exactly how the figure was reached. Free, no sign-up, and it works whether or not you ever use our software. ##### When the margin scheme applies The arithmetic is simple. Whether you are entitled to use it is the part worth checking. - **It covers second-hand goods**: The scheme can be used for second-hand goods, works of art, antiques and collectors' items. A used handset bought from a member of the public is the ordinary case in this trade. - **Not if you were charged VAT on it**: If you bought the item on a VAT invoice showing a separate VAT amount, it is not eligible for the margin scheme. You reclaim that VAT and sell the item under normal VAT rules instead. - **Repairs and parts stay outside the margin**: You cannot add what you spent on repairs, parts, accessories or business overheads to the purchase price. Where you were charged VAT on those, reclaim it on your VAT return in the normal way. - **The margin already includes the VAT**: That is why the figure is one sixth of the margin, 16.67%, rather than 20% of it. Charging 20% of the margin would overstate what you owe on every sale. - **A loss on one item is not a credit on another**: Under the standard margin scheme you cannot set a loss on one sale against the margin on a different one. The alternative global accounting scheme works differently. - **Records are the condition, not the paperwork**: The scheme requires a stockbook tracking each item individually, plus purchase and sales invoices for all of them. Miss the records and VAT is due on the full selling price, not the margin. - **The invoice must not show VAT separately**: A margin scheme sales invoice shows the total price only. Showing a separate VAT amount on it is not permitted, which catches out anyone whose till prints a standard VAT breakdown by default. General information, not tax advice. Check the guidance that applies where you trade, or speak to your accountant about your circumstances. ##### What people get wrong about margin VAT Mostly the same four things. **Do I pay VAT on the whole selling price of a used phone?** Not if you are using the margin scheme and the item qualifies. VAT is due on the difference between what you paid and what you sold it for, at one sixth of that difference. If the scheme's requirements are not met, VAT becomes due on the full selling price instead. **Why is it 16.67% and not 20%?** Because the margin is a VAT-inclusive amount. One sixth of a VAT-inclusive figure is the same money as 20% of the VAT-exclusive amount underneath it. Applying 20% to the margin would charge you VAT on the VAT, and overstate what you owe on every sale. **Can I add what I spent fixing it to the purchase price?** No. Repairs, parts, accessories and business overheads cannot be included in the margin calculation, so they do not reduce the VAT. Where you were charged VAT on them, you reclaim that on your VAT return in the normal way instead. **What if I sell a handset for less than I paid?** There is no margin, so there is nothing to tax on that sale. You cannot then set that loss against the margin you made on a different item, under the standard scheme each sale stands alone. The separate global accounting scheme treats losses differently. **Can I show the VAT on the customer's invoice?** No. A margin scheme sales invoice shows the total price and must not show VAT separately. This trips up shops whose till prints a standard VAT breakdown automatically, because the wrong paperwork can cost the scheme on that sale. **Do I have to register to use the margin scheme?** No separate registration is required. You start using it by keeping the correct records (a stockbook tracking each item individually, with purchase and sales invoices) and reporting it on your VAT return. --- ## Comparisons Source: https://pro.slickcell.com/compare #### SlickCell Pro compared with other repair shop software Side-by-side comparisons for UK phone and device repair shops, with every fact about the other product sourced from its own pages and dated. £39 a month in pounds with every feature included, against US-dollar per-store pricing with add-ons marked paid on the entry plan; a trial you start yourself against a Request a Demo form; a database hosted in London. £39 a month in pounds with no monthly ticket limit and three users, against a US-dollar Starter plan limited to 75 tickets and invoices a month and one user; a database hosted in London. ##### Head-to-head - **SlickCell Pro vs RepairDesk**: Priced in US dollars per store, with add-ons sold on top of the entry plan. - £39 a month in pounds, every feature included - Trial started online, no demo call - Database hosted in London on every plan - **SlickCell Pro vs RepairShopr**: US-dollar plans, and the entry plan stops at 75 tickets a month. - No monthly ticket or invoice limit - Three users and five staff profiles on Starter - Database hosted in London on every plan ##### What you get whichever system you are leaving - **Every handset is its own record**: One phone is one unit with its own IMEI or serial, cost, condition, battery health, selling price, supplier and history. Quantity is counted from the units, never typed, so you see the exact profit on the exact phone you sold. - **The VAT margin scheme, per item**: Second-hand stock can be taxed on the margin between what you paid for that unit and what you sold it for, reported separately from standard-rated sales. Because every handset carries its own purchase cost, the per-item record the margin scheme asks for is already there. - **Repairs where the money adds up**: A deposit is taken against the job, parts are committed from stock, extra work is quoted before the price changes, a part payment leaves a real balance, and a paid invoice is locked. The ticket, the till, the invoice and the report all agree. - **Trade-ins as a tracked purchase**: Inspect, approve, pay the seller by cash, bank transfer or credit against a sale, and the handset enters stock as its own unit with its real acquisition cost. - **Customers kept up to date by email and QR**: Email a customer from the job on a template. Every receipt and repair label carries a QR code that opens a live tracking page, with no app and no login. - **Any staff phone is a barcode scanner**: Pair a phone to the till from a QR code on screen and every scan lands in the open sale. No app, no hardware to buy. - **Suppliers connected inside the system**: A purchase order lands directly in a connected supplier's own account; they confirm or re-quote, reserve and dispatch, and you book in what actually arrived. - **Hosted in London, sealed per shop**: The database runs in London on every plan, encrypted in transit and at rest, with row-level security on every table, two-factor sign-in, database-enforced roles and an append-only audit trail. - **Every feature on every plan**: From £39 a month excluding VAT, in pounds, with a fourteen-day free trial you start yourself: no card and no sales call. No per-transaction fees, and you keep the card machine you already have. --- ## SlickCell Pro vs RepairDesk Source: https://pro.slickcell.com/compare/slickcell-pro-vs-repairdesk #### SlickCell Pro vs RepairDesk for UK repair shops Priced in pounds with every feature on every plan, data hosted in London, every handset tracked as its own unit, and a trial you start yourself tonight. Here is how the two compare, with every RepairDesk fact sourced and dated. #### The differences a UK shop feels first RepairDesk facts are taken from their own pages on 10 September 2026, with sources below. | | SlickCell Pro | RepairDesk | |---|---|---| | Entry price | £39 a month, excluding VAT | $99 per store a month, or $79 billed annually (US dollars) | | Currency and VAT | Pounds, VAT stated on every price | US dollars | | Add-ons sold on top of the entry plan | None: every feature on every plan | Loyalty, store credits, gift cards, email campaigns, appointments, Connect and the phone system listed as paid | | Starting a trial | Sign up online: 14 days, no card, no sales call | Free Trial leads to a Request a Demo form | | Where your data is held | Database hosted in London, on every plan | Privacy policy: may be transferred to and stored in the United States | | Second-hand handsets | Each handset its own unit, with its own cost, condition and margin | Serialized inventory | | Card payments | Keep your own card machine; no cut of your takings | Integrations and RepairDesk Payments | ##### Five reasons the switch is worth it - **One price in pounds, and nothing sold on top**: SlickCell Pro is £39, £59 or £99 a month excluding VAT, and every plan carries every feature: plans differ only by team size, locations, discount rules and support. RepairDesk's pricing page quotes US dollars per store and marks loyalty, store credits, gift cards, email campaigns and appointments as paid on its entry plan. - **Start tonight, not after a demo**: Sign up, pick a plan and fourteen days start straight away, with no card and no call. RepairDesk's Free Trial button leads to a Request a Demo form and a call from a product specialist. - **Your shop's database is in London**: SlickCell Pro's database is hosted in London on every plan, encrypted in transit and at rest, and sealed per shop by row-level security. RepairDesk's privacy policy says personal information may be transferred to, stored and processed in the United States. - **Every handset is its own unit, with its own cost**: Buy three identical iPhones for £280, £320 and £350 and SlickCell Pro holds three units, each with its own IMEI, cost, condition, battery health and price. You see the real profit on the exact phone you sold, and the margin scheme is worked out from that unit's own purchase cost. - **Keep the card machine with the best rate**: Take card payments on the terminal you already have and the till records them on the sale, split with cash if needed. SlickCell Pro takes no cut of your takings and does not ask you to move processor. - Every statement this page makes about RepairDesk, with where it came from and when it was checked. Prices and terms change: if anything here has gone out of date, write to us and we will correct it. ##### RepairDesk's pricing page lists Essential at $99 per store per month, or $79 per store per month billed annually, and Growth at $149, or $119 billed annually. Advanced is quoted on request. Prices are shown in US dollars, and payment is upfront. - Source: https://www.repairdesk.co/pricing/ - Checked: 2026-09-10 ##### On the Essential plan, RepairDesk's pricing page marks Loyalty, Store Credits, Gift Cards, Email Campaigns and Appointments Pro as paid. RepairDesk Connect is a paid add-on on Essential and Growth, and the Phone System is a paid add-on on every plan. The page also states that not all integrations are available with each plan. - Source: https://www.repairdesk.co/pricing/ · https://www.repairdesk.co/repairdesk-connect/ · https://www.repairdesk.co/repairdesk-phone-system/ - Checked: 2026-09-10 ##### RepairDesk's Free Trial button leads to a page titled Request a Demo, and its pricing FAQ says a RepairDesk product specialist will contact you to demo the product. - Source: https://www.repairdesk.co/pricing/ → book.repairdesk.co - Checked: 2026-09-10 ##### RepairDesk's privacy policy states that personal information may be transferred to, stored and processed in the United States. - Source: https://www.repairdesk.co/privacy-policy/ (last updated 10 July 2026) - Checked: 2026-09-10 ##### What shops ask before switching from RepairDesk **What is the best RepairDesk alternative for a UK repair shop?** SlickCell Pro. It is priced in pounds from £39 a month with every feature on every plan, handles UK VAT including the margin scheme, tracks every handset as its own unit with its own cost, keeps its data in London, and you can start the fourteen-day trial yourself with no card and no sales call. **How much does RepairDesk cost compared with SlickCell Pro?** RepairDesk's pricing page lists Essential at $99 per store a month, or $79 billed annually, and Growth at $149, or $119 billed annually, in US dollars, with several features marked as paid extras (checked 10 September 2026). SlickCell Pro is £39, £59 or £99 a month excluding VAT, with every feature on every plan. **Where is my data held?** With SlickCell Pro, in London: the database is hosted in AWS's London region on every plan. RepairDesk's privacy policy states that personal information may be transferred to, stored and processed in the United States. **Can I move from RepairDesk to SlickCell Pro?** Yes. Export your parts, accessories and devices to a spreadsheet and import them from CSV, with a preview of exactly what will be written before anything is saved. Finish open repairs on RepairDesk and start new work in SlickCell Pro from your go-live day. **Does SlickCell Pro handle the VAT margin scheme?** Yes, per unit. Margin is one of the tax rule types and can be scoped to used stock, and because every handset carries its own purchase cost, the margin on each sale is worked out from that unit and reported separately from standard-rated sales. **Do I have to speak to sales before I can try it?** No. Sign up online, choose a plan and the fourteen-day trial starts straight away with every feature switched on. There is no card to enter and nobody has to call you first. --- ## SlickCell Pro vs RepairShopr Source: https://pro.slickcell.com/compare/slickcell-pro-vs-repairshopr #### SlickCell Pro vs RepairShopr for UK repair shops Priced in pounds with no monthly ticket limit, a team from day one, data hosted in London and every handset tracked as its own unit. Here is how the two compare, with every RepairShopr fact sourced and dated. #### The differences a UK shop feels first RepairShopr facts are taken from their own pages on 10 September 2026, with sources below. | | SlickCell Pro | RepairShopr | |---|---|---| | Entry price | £39 a month, excluding VAT | $69.99 a month, or $59.99 billed annually (US dollars) | | Currency and VAT | Pounds, VAT stated on every price | US dollars, taxes added on top | | Tickets and invoices on the entry plan | No monthly limit | 75 a month | | People on the entry plan | 3 app users and 5 employee profiles | 1 user account | | Where your data is held | Database hosted in London, on every plan | Processed outside the EEA, the UK and Canada | | Second-hand handsets | Each handset its own unit, with its own cost, condition and margin | Serialized inventory | ##### Four reasons the switch is worth it - **No ticket limit on any plan**: Book in as many repairs and raise as many invoices as the shop can handle, on every plan. RepairShopr's Starter plan stops at 75 tickets and invoices a month and one user account. - **A team from the first day**: Starter carries three people who sign in and five employee profiles for hours, commission and job assignment, all with database-enforced roles, at £39 a month excluding VAT. - **Your shop's database is in London**: SlickCell Pro is hosted in London on every plan, encrypted in transit and at rest, and sealed per shop by row-level security. RepairShopr's operator states that it transfers and processes data outside the EEA, the UK and Canada. - **Every handset is its own unit, with its own cost**: Each phone carries its own IMEI, cost, condition, battery health and price, so the profit on the exact phone you sold is real and the margin scheme is worked out from that unit's own purchase cost. - Every statement this page makes about RepairShopr, with where it came from and when it was checked. Prices and terms change: if anything here has gone out of date, write to us and we will correct it. ##### RepairShopr's pricing page lists Starter at $69.99 a month, or $59.99 billed annually, Repair Shop at $139.99, or $129.99, and Big Chain at $149.99, or $139.99, in US dollars. - Source: https://www.repairshopr.com/pricing - Checked: 2026-09-10 ##### RepairShopr's Starter plan is limited to 75 tickets and invoices a month, one location and one user account. Unlimited tickets start on Repair Shop, and more than one location on Big Chain. - Source: https://www.repairshopr.com/pricing - Checked: 2026-09-10 ##### RepairShopr's licence agreement states that fees are exclusive of sales, use and value added taxes. - Source: https://www.repairshopr.com/repairshopr-user-access-and-license-agreement - Checked: 2026-09-10 ##### RepairShopr is operated by Syncro Technologies, Inc., whose privacy policy states that it transfers and processes data outside the EEA, the UK and Canada. - Source: https://www.repairshopr.com/privacy-policy - Checked: 2026-09-10 ##### What shops ask before switching from RepairShopr **What is the best RepairShopr alternative for a UK repair shop?** SlickCell Pro. It is priced in pounds from £39 a month with no monthly ticket limit and every feature on every plan, handles UK VAT including the margin scheme, tracks every handset as its own unit with its own cost, and keeps its data in London. **How much does RepairShopr cost compared with SlickCell Pro?** RepairShopr's pricing page lists Starter at $69.99 a month, or $59.99 billed annually, with 75 tickets and invoices a month and one user, and Repair Shop at $139.99, in US dollars with taxes added (checked 10 September 2026). SlickCell Pro is £39, £59 or £99 a month excluding VAT, with every feature on every plan. **Can I move from RepairShopr to SlickCell Pro?** Yes. Export your parts, accessories and devices to a spreadsheet and import them from CSV, with a preview of exactly what will be written before anything is saved. Finish open repairs on RepairShopr and start new work in SlickCell Pro from your go-live day. **Where is my data held?** With SlickCell Pro, in London: the database is hosted in AWS's London region on every plan. RepairShopr's operator, Syncro Technologies, states that it transfers and processes data outside the EEA, the UK and Canada. --- ## For phone repair shops Source: https://pro.slickcell.com/for/phone-repair-shops #### Software for mobile phone repair shops Built around the way a repair shop actually runs: a counter with a queue, a bench with parts on it, and a drawer of handsets that all cost something different. #### One morning, start to finish - Ten past nine. A cracked screen comes in, and the customer leaves a deposit against the job rather than a promise. The part is checked, it is on the shelf, and it is reserved to that ticket, so the same screen cannot be sold out from under the repair at the counter an hour later. - By eleven the technician finds the battery is going too. That is quoted, sent to the customer, and approved before anyone touches it, so the extra cost is agreed rather than discovered at collection. At half twelve the phone is handed back, the balance settles against the deposit already taken, and the receipt shows what was paid and how. - The handset the customer traded in is costed, graded and listed by lunchtime, as its own unit, with its own price. ##### What made that Tuesday possible Each step wrote to the next. Nothing in that morning was retyped, and nothing was held together by someone remembering it. - **Booked in**: Device, fault and customer on one ticket. - **Deposit**: Money against the job, not a note on a pad. - **Part reserved**: Committed to that ticket so it cannot be sold twice. - **Extra work quoted**: Quoted on the ticket before the cost lands. - **Balance settled**: The deposit counts; what is left is a real figure. - **Trade-in listed**: Costed and graded as its own unit, ready to sell. A part used reduces stock, the stock movement lands in cost of goods, and cost of goods lands in the month's profit: which is why the trade-in you took at half twelve is already costed when you look at the figures on Friday. ##### Three things you can inspect Not a quote from a shop you cannot ring. Three artefacts, in real markup, whose figures check against each other. ##### A split-payment receipt One sale settled across card and cash. The tenders add up to the total, the change is what went back over the counter, and the balance lands on zero: the case where money usually goes missing. ##### A device unit's history One handset by IMEI: what it cost, what it sold for, its condition, and the stock ledger that recorded it arriving and leaving. Quantity is derived from units, never typed. ##### A report total, and its source The revenue figure and the invoices it is made of, on the same screen: the rows add up to the total exactly. The report is not a separate number; it is the same number, traced. ##### Fewer disputes, stock that matches, VAT that reconciles The three things a shop owner actually notices after the first month. - **Fewer disputes**: What was quoted, approved and paid is on the ticket, so collection stops being an argument. - **Stock that matches**: Quantity is derived from real units, so the shelf and the system stop drifting apart. - **VAT that reconciles**: Standard and margin-scheme VAT are reported separately, from the same records as the invoices. - **Deposits that count**: Money taken at intake is money against the bill rather than something to remember. - **A month you can close**: Figures open onto the records behind them, so month-end is checking rather than rebuilding. ##### Everything a repair shop runs on ##### Repairs One ticket per job, from booked in to handed over. ##### A repair-aware till Repairs, accessories and handsets on one sale, with split tender. ##### Device-unit stock Each handset its own record; parts counted by quantity. ##### Invoices & payments Part payments, corrections and refunds as one financial history. ##### Used devices Cost, margin and margin-scheme VAT held per unit. ##### Trade-ins Take a handset in, cost it, and put it on the shelf as stock. ##### Reports & tax Figures that open onto the records that produced them. ##### More than one branch One login across shops, with stock and staff kept per branch. ##### Mobile scanning Pair a staff phone off a QR and scan into the open sale. ##### Customer updates Tell a customer the job is ready, and keep the record of it. ##### Cash drawer Open on a float, close on a count, see the difference. ##### Stocktake Count against a snapshot; stock moves only once approved. ##### What shop owners ask before switching The questions shops ask before they switch, answered straight. **Is this cell phone repair shop software, or is it for something else?** It is built for mobile phone repair shops first. Repairs, a repair-aware till, device-unit stock and used-device VAT are the core of it rather than modules bolted onto a general retail system. Computer repair and phone retail shops use it too, but the trade it was designed around is yours. **We are a two-person shop. Is this too much system?** The plans start at a single location with three app users, which is the size most shops begin at. The parts you do not need stay out of the way. You are not paying for a multi-branch rollout to book in a screen repair. **How long before we are actually using it?** Stock can be brought in from a spreadsheet, with a preview of what the import will do before anything is written. Most of the setup is deciding how your shop already works and telling the system that, rather than changing how you work to suit it. **What happens to the way we already track repairs?** It becomes one record instead of a board, a notebook and a phone thread. The job and the money live on the same ticket, so a deposit taken at intake is money against the bill rather than something someone has to remember at collection. **Do we have to track every handset individually?** Devices, yes: each carries an IMEI, serial number or shop reference stored as free text. Parts and accessories are counted by quantity, which is the right shape for a box of screen protectors. You are not logging cables one at a time. **Can it handle the VAT margin scheme on used phones?** Cost, margin and selling price are held on the individual handset, and margin-scheme VAT is reported separately from standard VAT. This is general information rather than tax advice. Check the guidance that applies where you trade, or speak to your accountant about your circumstances. **What if a customer pays only part of the bill?** The shortfall stays visible as a balance against the job. It is never converted into a discount, so you can see what is owed, chase it, and settle it later against the same record rather than opening a new one. **Can we run more than one shop from it?** Yes, from one login, with stock and staff kept per branch and reporting available per branch or across the group. Multiple locations start on the Professional plan; additional branches are priced per month. --- ## For phone shops Source: https://pro.slickcell.com/for/phone-shops #### EPOS and stock control for phone shops A shop that sells handsets, cases and chargers all day, and takes the odd repair, needs a till first. This one counts accessories by the box and tracks every handset on its own. #### Forty sales before lunch - Nine o'clock. A case, a screen protector and a charging cable go through in one sale, scanned off the shelf, each coming off a quantity. The next customer buys a refurbished handset: that one is a single unit with its own IMEI, its own cost and its own price, and it leaves stock as itself rather than as one of a count. - Half ten. A regular asks for money off. The assistant on the till picks a discount the shop has defined, with a start date, an expiry, a usage limit and a cart minimum, and the server checks all four before it is applied. There is no free-text box for knocking a tenner off. - Midday. A customer trades in their old handset against a new one. It is costed and graded there and then and goes into stock as a unit, ready to sell. At close the drawer is counted against what the till says it should hold, and the difference, if there is one, is a figure rather than an argument. ##### What a retail day runs on From the first scan to the counted drawer, each step writes to the next. - **Scanned**: Accessories off a barcode, handsets by their IMEI. - **Discounted**: From a rule the shop defined, checked on the server. - **Paid**: Card, cash, or both against one sale, with change recorded. - **Traded in**: Costed, graded and on the shelf as a unit. - **Reordered**: Accessories below their reorder level show up for a purchase order. - **Counted**: The drawer closed on a count, the difference visible. A staff phone can be paired to the till from a QR code and used as a scanner for the open sale, so a busy counter does not need a second scanner bought for it. ##### Three things you can inspect Real screens from the product, whose figures check against each other. ##### A split-payment receipt One sale settled across card and cash. The tenders add up to the total, the change is what went back over the counter, and the balance lands on zero: the case where money usually goes missing. ##### A device unit's history One handset by IMEI: what it cost, what it sold for, its condition, and the stock ledger that recorded it arriving and leaving. Quantity is derived from units, never typed. ##### A report total, and its source The day's revenue and the sales it is made of, on the same screen. The rows add up to the total exactly, so the report is the till, traced. ##### A drawer that reconciles, a shelf that matches, discounts you can see What a phone shop owner notices after the first month. - **The drawer reconciles**: Opened on a float, closed on a count, with the difference shown rather than guessed. - **The shelf matches**: Accessories by quantity, handsets by unit, so the system and the stockroom stop drifting apart. - **Discounts are rules**: Each has a start, an expiry, a usage limit and a cart minimum, and the server enforces them. - **Used stock is costed**: Each second-hand handset carries its own cost, so the margin on it is real. - **Reorders are not guessed**: Fast-moving accessories fall below their reorder level and show up to be ordered. ##### A till built for the shelf you actually have ##### The till Accessories, handsets and repairs on one sale, with split tender. ##### Scan to sell Barcodes for accessories; a staff phone can be the scanner. ##### Accessories by quantity Cases, cables and chargers counted by the box, with reorder levels. ##### Handsets by unit Every device its own record with its own IMEI, cost and price. ##### Used devices Cost, margin and margin-scheme tax held per handset. ##### Trade-ins Take a handset in against a sale and put it on the shelf as stock. ##### Discounts as rules Defined once, with expiry and usage limits, applied at the till. ##### Cash drawer Open on a float, close on a count, see the difference. ##### Invoices & payments Part payments, corrections and refunds as one financial history. ##### Repairs when you take them A repair ticket sits beside the sale, not in a separate system. ##### Stocktake Count against a snapshot; stock moves only once approved. ##### More than one shop One login across branches, with stock and staff kept per branch. ##### What phone shop owners ask The questions shops ask before they switch, answered straight. **Is this a phone shop EPOS system, or repair software with a till bolted on?** It is both, and the till is not an afterthought: accessories are scanned off a quantity, handsets are sold as individual units, and card and cash can be split across one sale. Repairs sit beside sales on the same record rather than in a second system, which suits a shop that sells most of the day and fixes some of it. **Do I really have to record every handset one at a time?** Handsets, yes, because two of the same model bought for different money are not the same stock, and the margin on a used one is only real if its own cost is known. Accessories are the opposite: a box of cases is a quantity with a reorder level. The system holds both shapes at once. **Can I stop staff giving discounts?** Discounts are rules the shop defines rather than an amount typed at the till. Each rule has a start date, an expiry, a usage limit and a cart minimum, and the server checks all four when it is applied, so a discount that has run out cannot be given again. Staff choose from the rules that exist; they do not invent one. **Does it work with a barcode scanner?** Yes. A USB scanner that types into the till works as it would anywhere, and a phone camera can scan too. A staff phone can also be paired to the till from a QR code on screen and used as a scanner for the open sale, with no app to install and no scanner to buy. **Does it work with my card machine?** Yes, with the one you already have. Take the payment on your terminal and the till records it on the sale, split with cash if needed, so the sale, the receipt and the day's report agree. SlickCell Pro takes no cut of your takings, so you stay free to choose the card provider with the best rate. **How does it handle second-hand handsets and the margin scheme?** Cost, condition and selling price are held on the individual handset, and margin-scheme tax is reported separately from standard tax, so a used sale and a new sale do not get mixed in the figures. This is general information rather than tax advice. Check the guidance that applies where you trade, or ask your accountant. **What happens at the end of the day?** The drawer is opened on a float and closed on a count. The till knows what cash it should hold from the day's sales and change, so the close shows the difference as a figure. Card takings are listed separately, and the day's revenue in the report opens onto the sales it came from. **Can we run more than one shop from it?** Yes, from one login, with stock and staff kept per branch and reporting available per branch or across the group. Multiple locations start on the Professional plan; additional branches are priced per month. --- ## For computer repair shops Source: https://pro.slickcell.com/for/computer-repair-shops #### Software for computer and laptop repair shops A bench job that takes three days is a different shape from a screen swap that takes an hour. Quotes before work, parts on order, machines by serial: the ticket is built for it. #### One laptop, Monday to Thursday - Monday morning a laptop comes in that will not power on. It is booked in by make, model and serial number, with the processor, memory and storage recorded on the ticket so the machine that leaves is provably the machine that arrived. - After an hour of diagnosis the fault is a failed board component. A quote goes to the customer before any part is ordered, and nothing on the ticket moves until they approve it. If they come back asking for a cheaper option, the quote is revised rather than retyped. - The part is not on the shelf, so the ticket sits in Awaiting Parts while a purchase order goes out. That is a normal state, with its own date, not a job someone has to remember. Thursday the part arrives, is booked in against the order, the repair is finished and the balance settles at collection. ##### A longer job, held on one record The states a bench job actually passes through, each one visible on the ticket and in the queue. - **Booked in**: Make, model, serial and the fault described. - **Diagnosed**: Findings on the ticket, in the technician's words. - **Quote sent**: Priced before the work, approved before the part. - **Awaiting parts**: A status with a date, tied to the purchase order. - **Repaired**: Parts used come off stock and onto the job. - **Collected**: Balance settled against any deposit already taken. A job sent out to a specialist (a board-level repair, a data recovery lab) is marked Outsourced and stays on the queue, so it is still your ticket and still your customer while it is away. ##### Three things you can inspect Real screens from the product, whose figures check against each other. ##### A device unit's history One machine by serial: what it cost, what it sold for, its condition, and the stock ledger that recorded it arriving and leaving. The same record shape holds a refurbished laptop as holds a handset. ##### A split-payment receipt One bill settled across card and cash, with the deposit taken at booking already counted. The tenders add up to the total and the balance lands on zero. ##### A report total, and its source The revenue figure and the invoices it is made of, on the same screen. A report is the same number as the invoices, traced, not a separate number typed in. ##### Quotes that are agreed, parts that are tracked, machines that are yours What a computer shop owner notices after the first month. - **No surprise at collection**: The quote the customer approved is on the ticket, and the bill is built from it. - **Parts on order are visible**: Awaiting Parts is a status with a date and a purchase order behind it, not a note. - **Serials that match**: The machine is booked in by serial, so the one that leaves is the one that arrived. - **Refurbished stock costed**: A machine you rebuild to sell is its own unit with its own cost and price. - **A month you can close**: Figures open onto the records behind them, so month-end is checking rather than rebuilding. ##### Built for the bench as much as the counter ##### Repairs One ticket per job, from booked in to collected, with diagnosis and quote on it. ##### Awaiting parts A real status with a date, tied to the order that will clear it. ##### Laptops by serial Processor, memory, storage and screen on the record, brand list built in. ##### Desktops and all-in-ones Tower or all-in-one, with graphics and form factor recorded. ##### Consoles too Storage, edition and controllers included, on the same ticket shape. ##### Parts by quantity Memory, drives and cables counted; machines tracked one by one. ##### A till for the counter Repairs, accessories and refurbished machines on one sale, split tender. ##### Deposits and balances Money taken at booking counts against the bill at collection. ##### Customer updates Tell a customer the quote is ready or the job is done, and keep the record. ##### Reports & tax Figures that open onto the records that produced them. ##### Stocktake Count against a snapshot; stock moves only once approved. ##### More than one branch One login across shops, with stock and staff kept per branch. ##### What computer shop owners ask The questions shops ask before they switch, answered straight. **Is this computer repair software, or phone software with a laptop option?** It was built for mobile phone repair shops first, and it says so on the page for them. Laptops, desktops, all-in-ones, tablets and games consoles are device types in their own right, each with a brand list and the spec fields that matter for it, and a bench job with a quote and a wait for parts is a normal ticket rather than an exception. **Can I quote before I do the work?** Yes. A ticket can carry a quote that is sent to the customer and sits at Quote Sent until they approve it. If they ask for a different option the quote is revised on the same ticket. Nothing is ordered and no part comes off stock until the approved version is converted into the job. **Half my jobs are waiting on a part. How is that handled?** Awaiting Parts is a status of its own, with the date the job entered it, so the queue shows what is waiting and for how long. The purchase order for the part is raised in the same system, and when it arrives it is booked in against that order and the job can move on. **Do I have to track machines by serial number?** Machines you stock to sell, yes: each is its own unit with its own serial, cost, condition and price, and quantity is derived from those units. The serial is free text, so a laptop service tag, a console serial or your own shop reference all work. Parts and accessories are counted by quantity. **What about a job I send out to a specialist?** Mark it Outsourced. The ticket stays on your queue and the customer stays yours, so when the machine comes back the job carries on from where it was rather than being booked in again. The status is visible in the queue the whole time it is away, with the rest of the job's history intact. **We sell refurbished laptops as well as fixing them. Does that fit?** Yes. A machine you rebuild is its own unit with its own cost, so when it sells the margin is real rather than estimated. If it was bought second-hand, cost and selling price are held per unit and margin-scheme tax is reported separately from standard tax. That is general information rather than tax advice. **What if the customer never collects?** The ticket stays open with its balance visible, so the shortfall is never converted into a discount by accident. You can see what is owed, message the customer from the record, and settle it later against the same job when they do turn up. **Can we run more than one shop from it?** Yes, from one login, with stock and staff kept per branch and reporting available per branch or across the group. Multiple locations start on the Professional plan; additional branches are priced per month. --- ## For parts suppliers and wholesalers Source: https://pro.slickcell.com/for/suppliers #### Software for parts distributors and wholesalers The shops you supply raise the order in their own system. It arrives in yours as an order, not an email to re-key, not a PDF someone reconciles later. #### One morning, start to finish - Twenty past eight. An order lands from a shop you supply, ten screens and six charging flexes, carrying their own purchase order number. You have the screens. You have four of the flexes. So the quote goes back saying four, not six, and the shortfall is a number on the order rather than a phone call at five o'clock. - They approve it before ten, which holds the stock against that order instead of leaving it on the shelf to be sold twice. It goes out on the afternoon courier, and confirming the dispatch is the moment it leaves your inventory. - One screen arrives marked. They book it in as damaged, you authorise the return, and the credit is on their statement before the week is out. ##### What happens to an order between them and you Eight steps, and the only two that belong to the shop are the two that should: approving the quote, and saying what turned up. - **It arrives**: Their purchase order lands as your incoming order, their PO number on it. - **Match the lines**: To your own stock, or offer an alternative, a special order, or nothing. - **Quote**: Confirm, re-price, or supply four where six were asked for. - **They approve**: All of it, or some lines and not others: their decision, recorded. - **Reserve**: Approved stock is held against that order rather than sold twice. - **Dispatch**: Confirming the dispatch is the moment stock leaves your inventory. - **They book in**: Line by line: accepted, damaged, missing or wrong item. - **Settle**: They submit a payment; you verify it; the statement moves. Nothing in that sequence is transcribed. What they ordered and what you read are one record, and what you sent and what they booked in are checked against it rather than against anybody's memory. ##### The screen that decides what a buyer sees Not a claim about the supplier side. One of its screens, photographed, with the rule printed on it. ##### What a buyer is shown The sharing panel that decides it: exact stock, availability only, or nothing at all — and the line that says cost prices, margins, internal notes and reorder levels are never shared, in any mode. Beside it, the customers with access and the wholesale price on each shared item. ##### Fewer phone calls, and an argument you can settle What a wholesaler notices in the first month of running an order this way. - **One order, not two records**: Their purchase order and your sales order are the same document, so nothing is keyed twice and nothing drifts. - **A short line is a number**: Supplying four of six is quoted on the order rather than explained on the phone, and it stays visible afterwards. - **Stock that leaves once**: Approved lines are reserved, and inventory only moves when you confirm the dispatch. - **A shortage with a paper trail**: What arrived damaged or missing is booked in against what you sent, so the credit is agreed from a record. - **A balance that means one thing**: A payment is a claim until it is verified, and a claim never quietly reduces what is owed. ##### The supplier side, in full ##### Incoming orders A shop's purchase order arrives as your order, their reference on it. ##### A shared catalogue Wholesale price, minimum order quantity and lead time, per item. ##### Control what is seen Exact stock, availability only, or nothing. Cost and margin never. ##### Versioned quotes Re-price or offer an alternative; every version keeps its reason. ##### Reserve on approval Approved lines are held against that order rather than sold twice. ##### Dispatch Delivery, courier, collection or third party: stock moves on confirm. ##### Receipt, line by line They book in what arrived: accepted, damaged, missing or wrong. ##### Discrepancies that end Replace, authorise a return or issue credit; the shop confirms it closed. ##### Payment verification A payment is a claim until you verify it. Pending moves no balance. ##### Customer statements Invoiced, outstanding and overdue per shop, with terms and a limit. ##### A thread per order One conversation in one place, with notes only your staff can see. ##### Business customers Pause new orders, decline with a reason, or archive once nothing is open. #### Bring the shops you already supply, and stop paying for months Every shop you introduce earns credit against your own subscription. Three of them is a month you do not pay for: banked until you want it, and spent on whichever month suits you. | | One free month | Two free months | Three free months | |---|---|---|---| | Shops on Starter | Three | Six | Nine | | Shops on Professional, Supplier Pro or Enterprise | Two | Four | Six | ##### How you earn one, and how you spend it The four that matter most. There are eleven in total, and the rest are on the programme page. - **Tell us before they sign up**: Send us the shop's name and who to expect, and we match it when they arrive. There is no referral code in the app and no partner dashboard: while the programme is small we run it by hand, and we would rather say that than show you a screen that does not exist. - **It counts once they are paying**: The fourteen-day trial does not count. A shop earns you credit on the first month it pays for a plan, and the credit is yours from that point. - **A shop earns once**: Credit is for bringing a shop, not for keeping one. A shop you introduced earns its credit on its first paid month and does not earn again, so a free month next quarter means another shop rather than the same three. - **Spend them when you like**: Free months bank up and do not expire. You choose which bills to skip, so a quiet month can be one you do not pay for. Tell us before the bill goes out and we will apply it. ##### What a wholesaler asks first Straight answers to what wholesalers ask before they sign up. **Do I have to be a repair shop to use this?** No. You choose “supplier” as your business type when you set the account up, and the supplier side is switched on for you. What you should know is that there is no separate distributor product: you get the whole platform (stock, a counter, invoices, customers and reporting) with Supplier Operations on top of it. For most wholesalers that is useful rather than surplus, because a trade counter is still a counter. **Do my customers have to be on the same system?** For the connected order, yes. The whole point is that their purchase order and your sales order are one record, and that only works when both businesses are on it. Everyone else is still an ordinary customer with ordinary invoices. You are not locked out of trading with them, you just re-key their orders the way you do now. **What do buyers actually see of my prices and stock?** You decide, per catalogue. Quantity can show as an exact figure, as availability only, or not at all. Prices are the wholesale price you set per item, and an item left without one shows as price on application. Cost prices, margins, internal notes and reorder levels are never shared, in any mode. **How do I get listed so shops can find me?** Two steps, and the second one catches people out. First you apply from your settings, which is where the trading details, categories and delivery terms go. Once that is approved you still have to publish your public profile (a description, at least one supplier type, at least one category and a fulfilment method) and until you do, you are approved but not listed. **What control do I have over who orders from me?** Shops already on the platform can add you as their supplier and start ordering straight away, so new trade reaches you with no approval queue. You control everything from there: you can turn new orders off, decline an order with a reason they see, set credit terms and a limit per customer, or archive the relationship once nothing is outstanding. **What happens when a delivery is short or damaged?** They book the delivery in line by line (accepted, damaged, missing or the wrong item) and raise a discrepancy against the lines that were not right. You accept it, accept part of it, or reject it with a reason. Then you send a replacement, authorise a return, or issue a credit, and the shop confirms it is settled before it closes. **How does the money side work?** The order becomes an invoice, and when a shop pays it they submit the payment against it. That submission is a claim until you verify it, and an unverified claim never reduces the balance you are owed. Each business customer has a statement showing what has been invoiced, what has been verified, what is outstanding and what is overdue, against the terms and credit limit you set for them. **What does it cost?** Supplier Operations is part of the Supplier Pro plan rather than an extra you bolt on, so one price covers the platform and the supplier side together. The trial runs fourteen days on that plan with every feature available and no card, which is long enough to take a real order from a real customer before you decide. **Is the partner programme worth anything if I only supply a handful of shops?** Three shops is a month you do not pay for, and two is a month if they are on Professional or above, so the arithmetic starts working at two or three rather than at thirty. What it will not do is pay you: credit only ever cancels your own bill. The plan prices it is measured against are on the pricing page. **Do the shops I introduce have to keep buying from me?** No. Credit follows their subscription, not their orders. If a shop you introduced starts buying from another wholesaler as well, or instead, the month you earned is still yours. They are still a customer here and you are still the reason. We would rather not be in the business of policing who you trade with. **How many shops can I introduce?** As many as you like, and there is no ceiling on what you can earn, nine on Starter is three free months, eighteen is six. Because credit is earned once per shop rather than paid out every month, bringing more is the only way to keep earning, which is exactly the way round we want it. **Is there a referral code or a partner dashboard?** Introductions are handled by hand, personally. You tell us who you are bringing before they sign up, we match them when they arrive, and we apply the free month to your subscription when you ask for it. That is the whole mechanism, with a person on our side at every step. --- # Guides, in full ## “Where is my phone?” The call you can stop taking Source: https://pro.slickcell.com/blog/where-is-my-phone The commonest question a repair shop is asked has the same answer every time, and a person has to find it first. It does not have to be a person. Count them one Saturday. Not the enquiries, not the bookings, just the calls that are somebody asking whether their device is ready yet. In most shops it is between five and fifteen. Each one costs about ninety seconds, because the person answering has to find the ticket before they can say anything, and they are usually holding a screwdriver when the phone rings. Twenty minutes a day, spent giving out information you already have. ### The call is not the problem It is tempting to treat this as an interruption to be blocked. It is not. The customer is asking a completely reasonable question about their own property, and they are asking it because there is no other way to find out. The problem is that the only interface to that information is a human being. And a human being is slow, occasionally wrong, and busy. ### What "ready" actually means to them Three different questions arrive as the same phone call: - **Is it done?** They want to know whether to drive over. - **Is it still going to be today?** They need the phone for something. - **Has something gone wrong?** It has been longer than they expected, and silence is starting to feel like bad news. The third one is the expensive one. Silence is where a perfectly ordinary two-day repair turns into a complaint, because nothing told them that "waiting for a part" is a normal state rather than a problem. ### A link, not a portal The instinct is to build a customer account system. Resist it. Accounts mean sign-ups, passwords, password resets, and a support burden that dwarfs the phone calls you were trying to avoid: for customers who will use it once. What actually works is much smaller: a link that is specific to one repair, handed over on the paperwork the customer is already holding. No account. No password. No app. A code on the receipt, a phone camera, and a page that says where that job has got to. ### What belongs on that page This is the part worth thinking about carefully, because a link anyone can open is a decision about disclosure. **Put on it:** the stage the repair has reached, the device, roughly when it is due, and who is working on it. That is what the customer would be told on the phone, so there is nothing new being given away. **Leave off it:** money and full identity. The price is between you and the person who authorised the work, and it does not belong on a page reachable by anyone holding the receipt: including whoever finds it on a train. **Make it forgettable to search engines.** An unlisted page is not a published one. Anything of this kind should tell crawlers to stay away, and you should be able to give a link an end date or switch it off. ### The stages have to be honest A status page that only ever says "in progress" is worse than no status page, because it teaches the customer that checking is pointless and they go back to ringing. The stages that earn their place are the ones that mean something different to the customer: - **Booked in**: we have it, we have not started. - **Being worked on**: someone has it open. - **Waiting for a part**: this is why it is taking longer, and it is not forgotten. - **Sent away**: a specialist has it. Same reassurance. - **Ready**: come and get it. That third one is the whole return on the exercise. "Waiting for a part" is the single most common cause of a repair taking longer than quoted, and it is the one thing a customer cannot guess. ### Then ask, while it is fresh The other thing a link like this is good for is the review, and the timing is the entire trick. Asking a week later, by email, when the job is a blur and the email is in a promotions folder, gets you nothing. Asking at the moment the repair is finished (from the same link they already have open, from the phone in their hand) is a different proposition entirely. Two rules make it worth doing. Only ask once the job is actually finished; and attach the answer to the technician who did the work, so a run of five-star jobs is attributable rather than being a fact about the shop in general. ### The test Pick your busiest day and ask one question: if a customer wanted to know where their device was at nine in the evening, could they find out? If the answer is "they'd have to ring in the morning", the twenty minutes is still being spent. You just have not noticed it, because it is spread across the whole day in ninety-second pieces. --- How this works in SlickCell Pro (the QR on the ticket, the status page, the invoice link and the review) is on [Customer tracking](/features/customer-tracking). --- ## Ordering from a supplier who is already in the system Source: https://pro.slickcell.com/blog/ordering-from-a-connected-supplier Every purchase order gets typed twice: once by you, once by them. Everything that goes wrong afterwards starts with that second typing. Here is a purchase order's actual life in most repair shops. You work out what you need. You write it in an email, or a WhatsApp message, or into a portal that belongs to your supplier and looks like it was built in 2011. Somebody at the other end reads it and types it into their own system. They reply with what they can do and what it costs. You read that and type it back into yours. Two people, typing the same list, into two systems that will never speak to each other again. ### Everything downstream inherits that Once the same order exists in two places, every later question becomes an archaeology exercise. The box arrives short. Short against what? Your sent folder, or their picking note? The price on the invoice is not the price you remember. Remember from where, the email or the reply to the email? A part goes back and a credit is agreed. Agreed by whom, and against which order? None of these are dramatic. Each is £30 or £60 and twenty minutes. They are invisible because there is no single record either party can point at, so nobody can be shown to be wrong and nothing gets fixed. ### The fix is not a better email It is that the order is one record with two viewers. You raise a purchase order in your own system, off your own stock levels. It arrives in the supplier's system as an incoming order. Not a PDF of your order. Not a notification prompting them to go and type it. The order. From there, the interesting parts are the ones that used to be conversations: **They can only supply some of it.** They send back a quotation with the lines they can do, at the prices they can do them. You approve line by line. What you did not approve is cancelled rather than assumed. **The price has changed.** The re-quote is a new version of the same document, with a reason attached. You see that the price moved and why, before it turns up on a bill. **They offer an alternative.** A different part, as a line-level suggestion you accept or decline: not a substitution that appears in the box and gets discovered on a Tuesday. ### Reserving is not sending This is the part most systems get wrong, and it is worth being fussy about. When a supplier approves your order, the stock should be **reserved**: held against your order, not available to be sold to the next shop that rings. But it has not left their building yet, so it should not have left their stock figures either. Those are two different events, and collapsing them into one is how a supplier ends up selling the same four screens twice. Reserve on approval. Deduct on dispatch. If a system cannot tell you which of those has happened, its stock figure is a guess. ### Receiving is where the money is The box arrives, and this is the moment worth thirty seconds of somebody's time. Book in what actually turned up, line by line, and let the outcomes be different from each other: accepted, damaged, missing, wrong item. Only the accepted goods should reach the shelf. Everything else should open something (a discrepancy, a return, a credit expected) rather than being absorbed into a shrug. A process with only "received" and "not received" cannot record thirty-six against an order of forty. So it records forty, and the four are gone. ### Paying, and being believed The last unglamorous piece: you pay, and the supplier's statement still says you owe it. The honest model is that a payment you record is a **claim** until the other side confirms it. Not because anyone is lying, but because two ledgers take time to agree and it is useful for both parties to see which items are agreed and which are still in flight. A claim awaiting confirmation should never quietly reduce a confirmed balance. That is how one side ends up arguing from a number the other has never seen. ### Is it realistic? Only if your supplier is on the same system, and today most will not be. That is worth saying plainly rather than pretending otherwise. But the parts that do not depend on them are worth doing anyway. Raise real purchase orders. Receive against them, per line, with real outcomes. Keep bills matched to receipts. All of that works with a supplier who has never heard of your software, and it is where most of the leaked money is. The connected version is what happens when the supplier is on it too. Then the second typing, the one every later problem descends from, simply does not happen. --- How this works in SlickCell Pro, from the shared catalogue to the payment confirmation, is on [Supplier network](/features/supplier-network). The supplier-agnostic half is on [Purchase orders & receiving](/features/procurement). --- ## Your staff already carry a barcode scanner Source: https://pro.slickcell.com/blog/staff-already-carry-a-scanner The second till never gets a scanner, because a scanner is eighty pounds you have not spent. Everyone behind the counter is already holding one. Most repair shops own exactly one barcode scanner, and it lives at whichever till used it last. That is not a purchasing failure. A scanner is never urgent enough to buy today and never cheap enough to buy four of, so the shop settles into a rhythm: one counter scans, the other types SKUs, and the stock delivery on the floor is counted by carrying boxes to the desk the cable reaches. Meanwhile there are four phones behind the counter, each with a camera better than the scanner. ### Why "just use the phone" usually is not that simple Plenty of people have had this idea. The reason it does not normally work is not the camera (phone cameras decode barcodes perfectly well). It is everything around it. To scan into a sale, the phone has to know which sale. Which means it has to be signed in as somebody. Which means an app, an account for every member of staff, a password nobody remembers, and a device you now have to think about when someone leaves. At which point the £80 scanner looks like the cheap option, because it is. ### Pairing beats logging in The move that makes it work is to stop treating the phone as a user and start treating it as a peripheral. A peripheral does not log in. It gets connected to one till, for one session, and it stops being connected when the session ends. That is what a cable does, and it turns out you can do the same thing with a code on a screen. The till shows a QR. A phone scans it. That phone is now attached to that till's open sale, and to nothing else. No account was created and nothing was installed. Four properties make that safe, and they are worth checking on any implementation: **The code expires.** A pairing code left on a screen at lunchtime should be useless by the time someone finds it. Minutes, not hours. **The session expires too.** Separately, and on a hard ceiling. A phone forgotten in an apron pocket must stop being a till after a while whatever it is doing. **One code, one phone.** A pairing code that can be claimed twice is a pairing code that can be photographed. **The till can cut it off.** Disconnect, and finishing the sale, should both end it immediately. ### What the phone should be allowed to do This is where it is worth being precise, because the whole value of the idea is that you can hand the phone to whoever is standing there: the Saturday assistant, the new starter, the person helping out during a rush. **Let it scan, change a quantity, and remove a line.** That is what a second pair of hands actually needs. **Do not let it price or take money.** Discounting, overriding a price and taking payment are decisions with a role attached, and that role belongs to whoever is on the till, not whoever is holding a phone. And be honest about what it displays. A phone scanning into a sale *shows the sale*: the lines, the prices, the total. It has to; the person holding it is reading items out. The meaningful question is not whether it shows prices, it is what it never receives at all: what those items cost you, your margin, who supplies them, the customer's name and number, and complete serial numbers. Those are the things you would not want written down on a bus, and none of them need to leave the till for a barcode to be scanned. ### The cases it actually solves Not "replacing scanners". These: - **The second counter**, which has never had one and never will. - **The delivery on the floor**, which is nowhere near the desk. - **The busy Saturday**, where an extra person is worth more than an extra till. - **The pop-up or the market stall**, where the hardware is whatever fits in a bag. If your shop has one counter and a scanner already cabled to it, this changes nothing for you, and that is fine. Keep the scanner. A good USB scanner is fast, dumb and reliable, and any system worth using should accept one. They behave like keyboards, so it is not much of an ask. ### The thing to check before you rely on it Signal. A phone that loses the till mid-sale must say so and stop, not quietly collect scans nothing will ever read. Ask what happens on a dropped connection: the honest answer is that scans are numbered and acknowledged, so reconnecting catches up on exactly what was missed. The dishonest answer is silence, and you will find out on the busiest afternoon of the year. --- How pairing, expiry and the split of authority work in SlickCell Pro is on [Phone scanner](/features/mobile-scanning). --- ## Who is allowed to give a discount? Source: https://pro.slickcell.com/blog/who-can-give-a-discount Most shops answer that question with trust. Trust is not a control, and the difference shows up in the month's margin, not on the day it happens. Ask a shop owner who is allowed to give a discount and you usually get a name. Ask who is allowed to void a sale, refund a card payment, change a price after it was agreed, or see what a screen cost you, and the answer is normally the same name, followed by "well, everyone can, really, but they wouldn't." That is not a permission model. It is a hope, and it holds right up until a Saturday when the person you trust is on lunch. ### The problem is not theft It is worth saying plainly, because the conversation usually starts in the wrong place. The reason to control who can discount is not that your staff are stealing from you. In most shops they are not. The reason is that **an unrecorded decision cannot be reviewed**. If anyone can knock £15 off, then at the end of the month you have a margin that is lower than your pricing says it should be and no way to find out why. The individual decisions were probably all reasonable. Collectively they are invisible, and invisible is the part that costs you. ### Four actions worth separating Most of the damage comes from four actions that are usually bundled together because they all live near the till: - **Discounting.** Reducing the price of something before it is paid for. - **Voiding.** Removing a sale that has already been rung up. - **Refunding.** Sending money back out after it has come in. - **Seeing cost.** Knowing what you paid for the thing on the shelf. They are different risks with different answers. A Saturday assistant probably should be able to take a payment and probably should not be able to refund one. A technician needs to order a part and does not need to know its margin. Your accountant needs every figure in the building and should never be able to issue a refund. Once you write them out like that, the bundle stops looking sensible. Nobody actually wants one switch labelled "trusted". They just never had four. ### "Hidden" is not the same as "not allowed" Here is the part that catches a lot of systems out, and it is worth checking on whatever you use today. There is a difference between a button that is not shown and an action that is not permitted. If the rule lives only in the screen, then the rule is decoration: it holds for the person clicking, and it does not hold for anything that reaches the data another way. The test is simple enough to ask a vendor. *Where is the permission enforced: in the interface, or in the database?* If the answer is only the first, then what you have is a tidier screen, not a control. The same question applies to figures rather than actions. Hiding a cost column is not the same as a role that cannot read cost at all. One is a layout choice. The other is a boundary. ### Roles are how you stop over-granting The practical failure in small shops is not too few permissions. It is that handing someone a login feels risky, so the owner keeps their own account logged in at the counter, and everyone uses it. That single habit destroys every audit trail you have. "Who authorised this refund" has one answer for the whole shop and it is you. Six months later, when you actually need to know, there is nothing to find. Giving everyone their own login is only safe if a login can be *limited*. That is the whole argument for roles: not bureaucracy, but the thing that makes individual accounts affordable. Once a sales role genuinely cannot refund, you can hand out sales accounts freely, and the audit trail starts naming people instead of naming you. ### What to look for If you are assessing this on a system you already run, or one you are considering, four questions get you most of the way: 1. Can two people on the same till have different powers, without one of them sharing the other's password? 2. Is discounting separable from refunding, and refunding from voiding? 3. Can someone be allowed to *use* an item without being allowed to *see what it cost*? 4. When something is overridden anyway, because sometimes it has to be, does the system record who allowed it and why, or does the exception just happen? The fourth is the one people forget. A control that cannot be overridden gets worked around, and a workaround leaves no record at all. The goal is not to make the exception impossible. It is to make it visible. ### In practice Every shop overrides its own rules sometimes. A regular customer, a job that went badly, a goodwill discount at the counter: these are good decisions and they should stay possible. What should not stay possible is making them anonymously. If you can answer "who discounted this, and why" three months later, the system is doing its job. If you cannot, then the £15 was never really the problem. --- In SlickCell Pro this is five roles (owner, manager, technician, sales and accountant) enforced by database policy rather than by hiding buttons, with cost visibility handled as a separate decision from the actions themselves. [Workforce and roles](/features/workforce) covers how they are assigned, and [Security](/security) covers where they are enforced. --- ## Counting stock without closing the shop Source: https://pro.slickcell.com/blog/counting-stock-without-closing A stocktake fails for boring reasons: it takes a day you don't have, and the till keeps selling while you count. Both are solvable. Most repair shops know their stock figure is wrong. They also know roughly when it went wrong: around the time somebody took a screen off the shelf for a job and meant to write it down. The reason it stays wrong is not laziness. It is that a stocktake, as most shops imagine it, means closing on a Sunday, counting everything, and typing numbers into a spreadsheet that is out of date by Tuesday. Nobody has a spare Sunday, so the figure drifts for another year. ### What actually makes a count hard Three things, and only one of them is the counting: **You are racing the till.** If you count the accessory wall at 10am and sell two cases at 11am, your count is wrong by the time you enter it, but you have no way to know whether the difference is a sale or a discrepancy. So the whole count becomes untrustworthy, and an untrustworthy count is worse than none, because you will act on it. **It is all or nothing.** A count that must cover the entire shop can only ever happen when the entire shop is closed. That is why it never happens. **Nothing separates the finding from the fixing.** In a spreadsheet, correcting the figure and discovering the variance are the same keystroke. So the variance (the actually interesting bit, the thing that tells you where stock is going) is destroyed at the moment it is found. ### Snapshot, count, approve, apply The fix is to make those four things four separate steps rather than one. **Snapshot.** When the count opens, the system records what it currently believes is on the shelf, right then. That number is frozen. Everything you count is compared against the snapshot, not against a figure that keeps moving, so the two cases you sell at 11am are a known movement rather than a mystery variance. You are no longer racing the till. **Count.** Enter what is physically there, line by line. Lines you have not reached should stay *unreached*, not zero. This sounds obvious and is the single most common way a count destroys good data: an empty box treated as "none in stock" will happily write off a shelf you simply did not get to. **Approve.** The variances appear: short, over, and what the difference costs. Nothing has changed yet. This is the step that is usually missing, and it is the one that makes a count useful: a manager looks at a list of differences and asks why, *before* the numbers are overwritten. **Apply.** Only now does stock actually move, and each correction posts as its own movement with a reason attached. Next month, "why did we write off four screens in August" has an answer. ### Count a shelf, not a shop Once a count can be scoped, the Sunday problem disappears. Count the accessory wall on a quiet Tuesday. Count one supplier's parts the week their statement arrives. Count the used handsets monthly, because that is where the money is, and the cases twice a year, because it is not. A small count you actually do beats a full count you keep postponing. It also narrows the investigation: when twelve lines are out, you can go and find out why. When four hundred lines are out, you shrug and accept the number. ### The variance is the point It is tempting to treat a stocktake as an accounting chore. Get the number right, move on. But the corrected number is the least valuable thing it produces. The valuable thing is the pattern. Screens short and cases fine means something different from everything short by a bit. A line that is over means something was booked in twice or a return went back on the shelf without a record. Repeated shortages on one category, month after month, is a process problem with a location, and you now know where to look. That pattern only exists if variances are recorded as variances. If the count silently overwrites the figure, you have bought yourself a correct number today and learned nothing. ### The practical minimum If you do nothing else: - Count one category a month rather than the shop once a year. - Freeze what you are comparing against before you start. - Leave uncounted lines uncounted. - Have someone other than the counter approve the differences. - Keep the variance, not just the correction. None of that needs a closed shop. It needs about forty minutes and a decision to stop treating the stock figure as something that will sort itself out. --- How a scoped count works in SlickCell Pro (snapshot on open, submit, manager approval, then apply) is written up step by step in [Run a stocktake](/help/run-a-stocktake). The wider model, where devices are tracked one unit at a time and parts by quantity, is on [Inventory & device units](/features/inventory). --- ## Getting the VAT margin scheme right on used devices Source: https://pro.slickcell.com/blog/vat-margin-scheme-used-devices A plain-English walk-through of margin VAT for second-hand phones: what it taxes, why it is one sixth and not 20%, and the mistakes that cost shops the scheme. If you buy a handset from a member of the public for £180 and sell it for £240, you do not owe VAT on £240. You owe it on the £60, and not even 20% of the £60. That is the whole margin scheme in two sentences. The trouble is that almost every part of the sentence has a condition attached, and getting one of them wrong is what turns a £10 VAT bill into a £40 one. ### What the scheme actually taxes The official description is short: VAT margin schemes "tax the difference between what you paid for an item and what you sold it for, rather than the full selling price. You pay VAT at 16.67% (one-sixth) on the difference." ([official guidance](https://www.gov.uk/vat-margin-schemes)) So on that handset: - Margin: £240 − £180 = **£60** - VAT: £60 ÷ 6 = **£10.00** - Yours: **£50.00** Without the scheme, VAT on the full £240 selling price would be £40.00. That gap is why the scheme exists: you bought the phone from someone who was not VAT registered, so there was no VAT to reclaim on the way in, and charging VAT on the entire sale price would tax value that was never yours. You can put your own figures through the [VAT margin calculator](/tools/vat-margin-calculator), which shows the working rather than just the answer. ### Why one sixth, and not 20% This is the single most common error, and it always goes the same way: the shop overpays. The standard rate of VAT used throughout this article is 20% ([official guidance](https://www.gov.uk/vat-rates)). Rates differ by country, so use yours. But 20% is what you add to a price that does not yet include VAT. The margin is not that kind of number. The £60 is money that has already come out of a customer's pocket, so the VAT is already inside it. To pull VAT out of a VAT-inclusive amount you take one sixth, because 20/120 = 1/6: | | 20% of the margin | One sixth of the margin | |---|---|---| | £60 margin | £12.00 | **£10.00** | | £150 margin | £30.00 | **£25.00** | | £400 margin | £80.00 | **£66.67** | On a shop turning over forty used handsets a month, treating one sixth as 20% is a four-figure annual gift to the tax authority that nobody asked you to make. ### The four things that cost shops the scheme The arithmetic is easy. The conditions are where the money goes. #### 1. You were charged VAT when you bought it If the item came to you on an invoice showing a separate VAT amount, it is not eligible for the margin scheme. You reclaim that VAT as input tax and sell the item under normal VAT rules instead. In practice this is the line between the two halves of a lot of shops' stock: handsets bought from the public go through the margin scheme, and stock bought from a VAT-registered trade supplier generally does not. They cannot be treated the same way, which means the decision has to be recorded per item at the point it arrives: not reconstructed at quarter end. #### 2. You added the repair cost to the purchase price This is the one that catches repair shops specifically, because it feels obviously fair. You paid £180 for the phone, then £40 on a screen to make it sellable. Surely your cost is £220? For the margin scheme, no. The guidance is explicit that you cannot include business overheads, repairs, or parts and accessories in margin calculations ([official guidance](https://www.gov.uk/vat-margin-schemes/eligibility)). The margin is still £60, and the VAT is still £10.00. What you do instead: where you were charged VAT on that screen, you reclaim it on your VAT return in the normal way. The relief comes back to you through a different door, not by shrinking the margin. It does change what you keep, of course: £50.00 of margin after VAT, minus £40 of parts, is £10.00 in your pocket. Which is worth knowing before you price the next one. #### 3. Your invoice showed the VAT A margin scheme sales invoice shows the total price and **must not show VAT separately** ([official guidance](https://www.gov.uk/vat-margin-schemes/keeping-records)). This is a paperwork rule with a real cost attached, and tills cause it. A system configured to print a VAT breakdown on every receipt will happily print one on a margin-scheme sale, and that document is then wrong. It is worth actually looking at what your receipts say on a used-device sale rather than assuming. #### 4. Your records will not support it The scheme requires a stockbook that tracks each item sold under it individually, plus copies of purchase and sales invoices for all of them ([official guidance](https://www.gov.uk/vat-margin-schemes/keeping-records)). "Individually" is the important word. This is a per-item scheme: the VAT on a sale depends on what *that specific handset* cost you. Four iPhone 13s bought at four different prices are four different margins, and a single line in a spreadsheet reading "iPhone 13 ×4" cannot tell you any of them. If the requirements are not met, VAT is due on the full selling price of each item rather than the margin ([official guidance](https://www.gov.uk/vat-margin-schemes)). That is the £40 outcome instead of the £10 one: not a penalty, just the scheme not applying. ### What happens when you sell at a loss Sometimes a handset does not move and you take what you can get. If you sell it for less than you paid, there is no margin, so there is nothing to tax on that sale. What you cannot do is set that loss against the margin on a different item. Under the standard margin scheme each sale stands on its own. A separate arrangement called global accounting works differently and pools the figures, but it is a different scheme with its own conditions: not something you drift into by accident. One honest caveat on this section: the clearest statement of the loss rule appeared in a notice that was withdrawn on 23 December 2021. It follows from the definition anyway, a sale at or below cost produces no difference to tax, but we would rather flag that than quote a withdrawn notice at you as though it were current guidance. ### The part that is actually hard None of the above is difficult on one sale. Anyone can do £240 − £180 ÷ 6. It gets hard because the margin scheme is per item, and a shop is not. Stock arrives from three or four different routes, some of it eligible and some not. Handsets sit for weeks. Somebody takes a trade-in on a Saturday. By the time the return is due, the question "what did this specific phone cost us?" needs an answer for every device that left the shop that quarter, and if the answer lives in someone's memory, or in a quantity count that says "iPhone 13 ×4", it is not really an answer. That is the actual work: keeping a cost against every individual device from the day it arrives to the day it leaves. How a shop does that (spreadsheet, stockbook, or software) matters less than that it does it at all. --- **General information, not tax advice.** Check [the published guidance](https://www.gov.uk/vat-margin-schemes) or speak to your accountant about your circumstances. Figures and rules on this page were checked against the published guidance on 4 August 2026. --- ## Why IMEI-level stock beats a quantity count Source: https://pro.slickcell.com/blog/imei-level-stock Tracking each handset as its own record changes what you can see, sell and trust on the shelf, and it is the only way per-item margin VAT ever adds up. A box of screen protectors is a number. You have eleven, you sell one, you have ten. Nothing about the eleventh is different from the third. A second-hand handset is not a number. It has a cost, a condition, a battery health, and a history, and the one at the back of the drawer cost you £40 more than the one at the front. Counting both the same way is where the trouble starts. ### What "iPhone 13 ×4" cannot tell you Say the shelf shows four of the same model. You bought them over six weeks: one trade-in at £150, two from a supplier at £205 each, one from a walk-in at £180. The count says 4. It is even correct. But it cannot answer: - Which one did we just sell? - What did *that* one cost us, so what did we actually make? - Which of these came in on a VAT invoice and which did not? - Which is the one with the swollen battery the customer brought back? Each of those questions has a real answer. The count has thrown all of them away, and the only place they still exist is in somebody's memory. ### The moment it stops being an inventory problem Most shops can live with a fuzzy count. What they cannot live with is a fuzzy margin. The VAT margin scheme is a per-item scheme: the VAT you owe on a used handset depends on what *that specific handset* cost you, not on an average. Four handsets bought at four different prices are four different margins and four different VAT figures, and the record-keeping rules ask for a stockbook that tracks each item sold under the scheme individually ([official guidance](https://www.gov.uk/vat-margin-schemes/keeping-records)). A line reading "iPhone 13 ×4" cannot produce any of that. Which means the choice between a quantity count and unit-level records is not really an inventory preference: it decides whether your VAT return is built on records or on recollection. There is more on the arithmetic in [getting the VAT margin scheme right on used devices](/blog/vat-margin-scheme-used-devices), and you can put figures through the [margin calculator](/tools/vat-margin-calculator). ### What a unit-level record actually holds One physical handset, one record, carrying: - An identifier: an IMEI, a serial number, or your own shop reference - What you paid for it, and what you are asking - Storage, colour, condition, battery health - Where it came from - What happened to it: received, reserved, sold, returned The count then stops being something anyone types. Available stock is however many unit records are still available, which means it cannot drift away from the shelf. There is no separate number to fall out of step. ### "That sounds like more work" It is one extra field when a handset arrives. That is the honest cost. What it removes is the work you are already doing and not counting: reconciling a count that drifted, reconstructing what something cost at quarter end, arguing about which handset the customer actually bought, and discovering in April that the margin you have been quoting yourself all year was an average of four different purchase prices. You are already tracking these devices individually. The IMEI is written on the box, or in a notebook, or in a WhatsApp message to your supplier. Unit-level stock just puts it where the money is. ### A note on identifiers It does not have to be a full IMEI. A serial number, the last few digits, or an internal shop reference all work as long as one record means one physical device, and no two records share a reference. Perfect data entry is not the condition: one-to-one is. --- Practical detail on how this works in SlickCell Pro is on the [inventory and device units page](/features/inventory). --- ## Purchase orders, receiving, and the gap in between Source: https://pro.slickcell.com/blog/purchase-orders-and-receiving Why booking stock in against the order you raised is what stops a short delivery quietly becoming your problem, and your loss. You order forty screens. A box turns up. Somebody opens it, puts the screens on the shelf, and gets back to the counter. Six weeks later the supplier's statement says you owe for forty. You are fairly sure there were thirty-six. Nobody counted, the box is long gone, and the conversation you are about to have is one you cannot win. ### The gap The order is a record. The bill is a record. The bit in the middle, what actually arrived, usually is not. That gap is where money leaves a repair shop quietly: - A short delivery nobody noticed, paid for in full - A price on the invoice that is not the price you agreed - Two boxes booked in once, or one box booked in twice - A part on the shelf that no order accounts for - A credit you were promised that never arrived and nobody chased None of these are dramatic. Each is £30 or £60. It is the fact that they are invisible that makes them add up. ### Receiving is the control, not the admin The fix is not a better filing system. It is that goods get booked in **against the order that created them**, at the moment they arrive. That single act does several things at once. It tells you what was actually delivered, as opposed to what was ordered. It leaves a partial receipt open rather than closed, so a short delivery stays visible instead of being forgotten. It gives the eventual supplier bill something to be checked against. And it puts the stock on the shelf and in the system in the same movement, so the count does not depend on somebody remembering to adjust it afterwards. The order stops being a piece of paper you raised and becomes something with a state: sent, partly received, received, billed. ### Partial deliveries are normal The most useful thing a receiving process can do is treat a partial delivery as an ordinary event rather than an exception. Suppliers back-order. Boxes get split. If your process only has "received" and "not received", a delivery of thirty-six against an order of forty has nowhere to go, so it gets marked received, and the four vanish. Recording thirty-six against a forty-line order leaves four outstanding, and outstanding things can be chased. ### Then the bill has something to argue with When the invoice arrives, the question is no longer "does this look about right?" It is whether this bill matches what we received, at the price we agreed. That is a question with an answer, and it is the difference between checking a supplier statement and accepting one. ### What it costs to do properly Ordering is a two-minute job. Receiving is a two-minute job. Neither is hard; both get skipped on a busy Saturday, and the cost of skipping them does not show up until the statement lands. The practical test for any shop: if a delivery arrived short this morning, would anyone know by Friday? If the honest answer is no, the gap is open. --- How purchase orders and receiving work in SlickCell Pro is on [Purchase orders & receiving](/features/procurement). Everything above works against your own supplier records, whether or not the supplier uses SlickCell Pro Pro. When they do, the order stops being an email, [Supplier network](/features/supplier-network). --- # Help centre, in full ## Add a handset to stock Source: https://pro.slickcell.com/help/add-a-device-unit-by-imei By the end of this the handset is on the shelf as its own row, sellable by IMEI, with a cost that will show up correctly in profit when it sells. 1. **Find or create the model**: Inventory → Items. If you already stock that model, open it; if not, add it as a device. The model holds the name and the default price; the handsets hold everything that varies. 2. **Add the unit**: Enter the IMEI or serial, the condition, the storage and colour, what you paid and what you are asking. Anything else the shop records (battery health, network, whether it is boxed) goes on the unit too. (The reference is free text. A full IMEI, a serial, the last five digits or your own sticker number are all fine; nothing is rejected for the wrong shape.) 3. **Check the model's quantity**: It has gone up by one, because it counts the units. There is no number to correct. **Two handsets with the same IMEI** Not possible, and that is the point: one reference is one physical device. **I do not know the IMEI yet** Use a shop reference for now and correct it later. An unlabelled handset on a shelf is the thing this is meant to prevent. --- ## Answer an order from a shop Source: https://pro.slickcell.com/help/answer-an-incoming-order By the end of this an order that arrived from a shop has every line answered: matched to something you hold, offered as an alternative, put on special order, or marked unavailable. An order carries three statuses at once, and they move independently. The order status is where the conversation has got to, fulfilment is where the goods are, and payment is where the money is. 1. **Open the order**: Supplier Operations → Orders. The list shows your reference, the shop's own purchase order number, who sent it, when it arrived and when they need it. Open one to work on it. 2. **Read the three statuses**: The header carries Order, Fulfilment and Payment as separate badges, and a fourth for a discrepancy if there is one. They are separate because they genuinely move apart: an approved order can still be sourcing, and a delivered one can still be unpaid. 3. **Answer each line**: Match the line to an item in your own inventory, or use one of the other four answers: offer an alternative product, put it on special order, ask the shop for details, or mark it unavailable. A line that came from your catalogue is already matched. (A line the shop typed themselves arrives as a new item request rather than a catalogue line. Matching it is how it becomes something you can price and reserve.) 4. **Check the quantity ladder**: Every line shows seven stages (requested, quoted, approved, reserved, dispatched, delivered, accepted) and each is its own figure. If you can supply four of the six asked for, the quoted quantity is four and the requested quantity stays six, so the shortfall stays visible instead of disappearing into an edit. **I can only supply part of a line** Quote the quantity you can supply. The requested figure is kept beside it, so the shop can see what is short and decide whether to approve the line anyway, and you both still have the record afterwards. **They have asked for something I do not stock** Offer an alternative and pick the product you would send instead, or put the line on special order if you can get it. Either way the shop sees what you are proposing before they approve. **Who on my team can do this?** Owners, managers and sales staff can work orders. Preparing and sending a quotation is limited to owners and managers. --- ## Set your account up as a supplier Source: https://pro.slickcell.com/help/become-a-supplier By the end of this you have a supplier account that shops can find, connect to and order from. There are two gates rather than one. The Supplier Operations module needs the plan that carries it AND an approved supplier profile, having only one of the two shows you a wall rather than the module. 1. **Sign up and choose your business type**: Sign up as anyone would, then on the first onboarding step choose supplier rather than repair shop. That choice decides which plans you are shown, a supplier is shown Supplier Pro, because it is the plan that carries Supplier Operations. (If you arrive from the supplier page on our website, the business type and the plan are already set for you.) 2. **Open the supplier application**: Settings → Supplier Account. You will need to be the owner or a manager; other roles can see the page but not submit it. 3. **Fill in who you are and what you supply**: Legal and trading name, registration and tax numbers, address and contact. Then what kind of supplier you are, the categories you carry, how you deliver, the areas you cover, your minimum order and your fulfilment time. Returns and warranty policy go here too. (You can save it as a draft and come back. Nothing is submitted until you say so.) 4. **Submit, and wait a little**: Submitting puts the application under review. Approval usually completes within about half an hour and you get a notification when it does, the Supplier Operations module appears in your sidebar at that point. 5. **Publish your public profile**: Supplier Account → Public Profile. This is the step that catches people out: approval does not put you in the directory. You need a description, at least one supplier type, at least one category and a fulfilment method, and then Publish. (Publishing is refused, with the missing field named, until all four are there. Hide it again at any time and you drop out of the directory without losing anything.) **I am approved but no shop can find me** Your profile is almost certainly still a draft. Go to Supplier Account → Public Profile and publish it. Only published profiles appear in the directory that shops search. **Do I have to be a repair shop as well?** No. You get the whole platform (stock, a counter, invoices, customers and reporting) with the supplier side on top, and you can use as much or as little of it as suits you. **Can somebody else on my team apply?** Only the owner or a manager can submit the application or change supplier settings afterwards. Sales staff can work the orders once you are live. --- ## Book a repair in Source: https://pro.slickcell.com/help/book-a-repair-in By the end of this a ticket exists with the customer, the device and the fault on it, a price, any deposit already recorded against the job, and a printed slip with a tracking code the customer can use. You need a customer in front of you (or on the phone) and the device's details. Nothing else has to exist first. A new customer can be added inside the same flow. 1. **Open Repairs and choose New ticket**: The ticket is built in seven short steps down one panel. You can go back to any step before you create it. 2. **Customer**: Search by name, phone or email. If they are not there, add them here: name and a phone number is enough to carry on. 3. **Device**: Brand, model, colour and the IMEI or serial number. The IMEI is typed as it is: the app does not check its format, and if the customer knows the passcode you can record it so the technician is not stuck later. (Type a model the app has not seen and it offers to add it to your shop's list, so next time it is one click.) 4. **Issue**: Pick one or more faults from the list, or add your own wording. If the fault is not known yet, mark the ticket for diagnosis and set the price later. Priority and the promised time are set here too. 5. **Parts (optional)**: Search stock and add the parts you expect to use. They are committed to this ticket, so the shelf count is right before the technician starts. 6. **Price**: The agreed price, the labour, and the tax rate this job is charged at. What the customer will pay is shown before you go further. 7. **Deposit (optional)**: If the customer pays something now, record it here and how they paid. It sits against this job and comes off the bill at collection. You will not need to remember it. (Cash deposits need an open cash drawer; the app tells you if there is not one.) 8. **Technician (optional) and create**: Assign a technician now or leave it for the manager. Choose Create Repair Ticket. 9. **Print the ticket**: After creating, print the customer slip. It carries a code the customer can scan to see the repair's status without logging in. **The customer does not know the IMEI** Leave it blank or type the last few digits. It is free text and can be completed later from the ticket. **Two faults on one phone** One ticket. Pick both issues in the Issue step; they are priced together and the ticket stays one record. --- ## Set your country, currency and tax rate Source: https://pro.slickcell.com/help/country-currency-and-tax You set these when you opened the shop, and they show up on every invoice, receipt and label. This is where to correct them. 1. **Open the shop settings**: Settings → General. Your name, address, contact details and country are all here. 2. **Change the country if it is wrong**: The currency follows the country. It sets the sign shown on every money figure in the app. It does not convert anything, so changing it does not restate your history. 3. **Say whether you are tax registered**: If you are, give the rate. A default tax rule is created from it and applies to sales and repairs. If you are not, no rule is created and nothing is added to your prices. (This is a fact about the business, not a preference. The app asks rather than guessing from whether a rate happens to be filled in.) --- ## Devices, parts and accessories are not the same thing Source: https://pro.slickcell.com/help/devices-parts-and-accessories Your stock is three kinds of thing, and the app treats them differently on purpose. Getting this straight makes everything else about inventory obvious. 1. **Parts and accessories are counted**: A screen, a battery, a cable: you have eleven of them and they are interchangeable. One number, one cost, one price. 2. **Devices are individual**: Two second-hand iPhone 13s are not the same stock. One cost £215 and is in good condition; the other cost £180 and has a scratched back. Each is its own row with its own IMEI, cost, price and condition. 3. **A device model's quantity is counted, not typed**: Open a device product and the available figure is however many units are on the shelf. There is no quantity box, because there is nothing to type: add a unit and it goes up. (IMEI and serial are free text. A partial number, a shop reference, whatever you actually have is accepted; nothing is rejected for failing a format rule.) 4. **Selling works the same way**: An accessory goes on a sale by quantity. A handset goes on as the specific unit, priced from that unit, so the till cannot sell it at a price the shelf disagrees with. **Why can I not just set a stock number?** Because a number nobody can explain is worse than no number. Every quantity here has a movement behind it (a delivery, a sale, a repair, a stocktake) so you can always ask where it came from. --- ## Dispatch an order, and settle what follows Source: https://pro.slickcell.com/help/dispatch-and-settle By the end of this the goods have gone, anything wrong with them has an ending, and the money against the order is either verified or visibly not. Confirming a dispatch is the moment stock leaves your inventory. Creating one does not. 1. **Create the dispatch inside the order**: Open the order and use its dispatch section. Everything is dispatched against an order rather than from a separate picking screen, so what you are sending is always tied to what was approved. (The section appears once the approved quotation has been converted to a sale. Before that there is nothing committed to send.) 2. **Choose how it goes, then confirm it**: Your own delivery, a courier, collection, or a third party. A courier asks for the carrier, the tracking number and link, the expected date and any shipping charge; a collection asks for where, when it is ready, a collection code and who is picking it up. Confirming is the step that matters: reserved stock leaves your inventory only when a dispatch is confirmed, and the shop is notified at that moment. (You can send part of an order now and the rest later. The section tracks what is still reserved and not yet dispatched.) 3. **Let them book it in**: The shop records what arrived, line by line: accepted, damaged, missing, the wrong item, or rejected. Only what they accept enters their stock, so a short or damaged delivery does not quietly become a full one. 4. **Deal with a discrepancy**: Anything they did not accept becomes a discrepancy with a typed reason and, usually, what they would like done about it. You accept it, accept part of it, or reject it, rejecting needs a reason, because a rejection without one is just silence. 5. **Verify the payment**: When the shop pays, the payment arrives as a submission rather than as money in the account. Verify it, or send it back as an amount mismatch, a duplicate, something you need to talk about, or a rejection. Until it is verified it does not reduce what they owe. (Verifying is limited to the owner, a manager or an accountant. Everyone else can see the queue but not act on it.) 6. **Read the customer's statement**: Supplier Operations → Accounts, then pick a business customer. You get what has been invoiced, what has been verified, what is outstanding, what is under discrepancy, what is overdue, and the credit limit and terms you set for them: over a ledger with a running balance. **They say they have paid and I cannot see it** Check the verification queue. A submitted payment sits there until somebody verifies it, and by design it does not move the balance while it waits, which is exactly the situation the queue exists to make visible. **Can I dispatch specific handsets?** Yes. Where a line is for devices tracked individually, the dispatch lets you choose which units go, by their IMEI or serial, rather than sending a quantity and working out later which ones left. **Can I archive a customer who owes me money?** No, and that is the point of the block. Archiving is refused while there are open orders, undelivered dispatches, unresolved discrepancies or an outstanding balance. Turn new orders off instead, and archive once it is clear. --- ## Hand the device back Source: https://pro.slickcell.com/help/hand-a-device-over By the end of this the ticket is closed, the money is settled or explicitly not, and the warranty is running from today rather than from whenever the job was booked in. 1. **Get the job to completed**: A repair is finished when the work is done and tested. That is a separate step from the customer collecting it, because they usually are not the same day. 2. **Raise the invoice**: Generate invoice from the ticket. Any deposit already taken comes off it. 3. **Take the balance**: Whatever is left, by whatever method. The invoice settles as the payments land against it. 4. **Hand it over**: Handing over closes the ticket and starts the warranty from that moment. (Handing over an unpaid job is possible, but it asks for a reason and records who allowed it. That is the point: it should be a decision, not an accident.) **They are collecting it tomorrow** Leave it completed. Ready-to-collect is a real state, and the queue on the repairs screen counts it. **When does the warranty start?** At handover. If you change the length later, the expiry is recalculated from the same start date rather than from today. --- ## Invite staff and choose what they can do Source: https://pro.slickcell.com/help/invite-staff-and-set-roles By the end of this the person has their own login, sees the parts of the app their job needs, and cannot reach the parts it does not. Roles are enforced on the server, not just hidden in the menu, so a role that cannot refund cannot refund, whatever it types. 1. **Open the team**: Settings → Team. Everyone with a login is listed here with their role. 2. **Send the invitation**: Their email and the role you want them to have. They get an invitation and choose to accept it, signing in does not join anyone to your shop on its own. 3. **Pick the right role**: Owner has everything. Manager runs the shop day to day, including voids and write-offs. Technician works tickets and stock. Sales runs the till and books repairs in. Accountant reads the money without changing it. (Refunds are open to the counter; voids and write-offs are not. That split is deliberate: a mistake at the till should be fixable without finding a manager, and a reversal of settled money should not.) 4. **Check the load**: Workforce shows who has what on the bench, so assigning a job is a decision rather than a guess. **Someone has left** Remove their access from the team. Their work stays on the records they did it on, a removed person does not erase a history. --- ## Jump to any screen with ⌘K Source: https://pro.slickcell.com/help/jump-to-any-screen By the end of this you will be able to reach any screen in the app without touching the sidebar, and you will know what the four controls along the top of every page are for. One thing worth knowing up front: the palette finds screens and actions, not your records. Looking for a customer or a ticket number means going to that screen first. 1. **Press ⌘K**: Ctrl+K on Windows. The palette opens over whatever you are doing, and closes on Escape without changing anything. (There is a button for it in the header too, next to the shop name: the keyboard shortcut and the button open the same thing.) 2. **Type part of what you want**: “inv” finds Invoices, “stock” finds the stocktake and the stock movements, “tech” finds the technician views. Partial words are fine; you do not need the beginning of the name. 3. **Go deeper than a page**: Tabs and sections inside a page are in there too, so “faulty” goes straight to Inventory's faulty-items tab rather than to Inventory and then a hunt. 4. **Start something, not just visit it**: Some entries do rather than go: a new repair ticket, the barcode scanner. Enter starts them where you are. (You only see what your role allows. Nothing appears in the list that you would be refused after choosing it.) 5. **Use the dashboard for the ten common jobs**: The tiles under the header are the things a shop does all day: a repair, a sale, an invoice, a trade-in, a stocktake, a customer, an item, a lead, a manual money entry, a purchase order. **Can I search for a customer or a ticket number in it?** No. The palette finds screens, tabs and actions, not your records. To find a customer, open Customers and search there; for a repair, open Repairs. It is a way of getting somewhere fast, not a search of your data. **Can I scan a barcode into it?** Not into the palette. Scanning is its own thing: the scanner button in the header, or a paired phone at the till. **Can we change which quick actions appear?** Not from Settings. The set is fixed, and which of them you see follows your role: an accountant does not get New Repair, and only someone who can write to the cashbook gets the money-in-and-out tile. **Does the shortcut clash with the browser?** ⌘K and Ctrl+K are claimed by the app while you are on one of its pages. If you need the browser's own version, click into the address bar first. --- ## Read the profit and loss Source: https://pro.slickcell.com/help/profit-and-loss-report The reports read from the same ledger the till writes to. There is no second set of numbers, which is why a total here can be opened to show the invoices behind it. 1. **Pick the period**: Reports, then Today, 7 days, 30 days, this month, or a range of your own. Everything on the page moves with it. 2. **Read revenue**: The total is what was invoiced in the period, split between counter sales and repairs. Those two add to the total, if they did not, something would be wrong. (Invoiced is not the same as received. Cash actually taken is in the Account tab, and the two differ by whatever is still owed.) 3. **Read the cost side**: Cost of goods comes from the stock movements the sales caused, at the cost those items were carrying when they sold. Labour comes from the payroll runs. 4. **Open a figure**: Any total opens onto the records it is made of. That is the check worth doing when a number looks wrong. It will show you which sale is behind it. **Revenue looks higher than what we banked** It will be, whenever anything is unpaid. Revenue is what you invoiced; the Account tab is what arrived. **Why does an old sale show a different cost from today's price?** Because it is recorded at the cost the item carried when it sold. Changing a price today does not rewrite last month's profit. --- ## Quote an order, revise it, and convert it Source: https://pro.slickcell.com/help/quote-revise-and-convert By the end of this the shop has a priced quotation, you have their answer line by line, and the stock behind the approved lines is held against that order. Every version of a quote is kept. Nothing you send is overwritten by what you send next. 1. **Compose the quotation**: From the order, choose to prepare a quotation. It opens in your own till with the order's lines already in the basket, so you price it exactly the way you price anything else, discounts, tax and all. (That is why the quotation looks like a sale: it is being built by the same till, which is what keeps the eventual invoice consistent with the quote.) 2. **Send it**: Sending records it as a version and moves the order to awaiting the shop's approval. They see the priced lines, the quantities you can actually supply, and anything you have offered as an alternative. 3. **Read their answer line by line**: The shop answers per line rather than per quote. They can approve some lines and cancel others, so a quote is rarely a straight yes or no. Check which lines came back approved before you pick anything. 4. **Record an approval taken off the platform**: If they approved it by phone, by email or across the counter, record that instead of approving it yourself. You give the method, who approved it, when, and a note, and the record says the approval was entered by the supplier on the shop's behalf. (Use this only when the approval genuinely happened. It is audited, and it is labelled as recorded by you rather than given by them.) 5. **Revise, if it has to change**: A price moves, or a line you quoted is no longer there. Revising creates a new version, and because the shop has already seen the last one, the reason is required rather than optional. Both versions stay on the order. 6. **Convert it**: Converting the approved quotation turns it into a sale and reserves the stock behind the approved lines, so the same screens cannot be sold over the counter while this order is waiting to go out. **Can I change a quote without the shop knowing?** Not once they have seen it. A revision to a quotation the shop can already read requires a reason, and the previous version stays in the history beside it. **How long does a quotation stay open?** For the validity period set in your order defaults, after which a sent quotation lapses on its own. Supplier Account → Order Defaults is where that period lives, and it is worth checking rather than assuming. **Does reserving stock take it out of my inventory?** No. Reserving holds it against the order so it cannot be committed twice. Inventory only changes when you confirm the dispatch. --- ## Raise a purchase order Source: https://pro.slickcell.com/help/raise-a-purchase-order By the end of this the order exists with its lines, its costs and its expected date, and the delivery can be booked in against it. You need a supplier on the system. Adding one takes a name. 1. **Open Purchase Orders and start a new one**: Inventory → Purchase Orders → New order. Pick the supplier first: it decides what you can order and at what price. 2. **Add the lines**: Search your own stock and add what you need. The cost comes from the item and can be changed on the line if this order is at a different price. (The cost is stored on the line as it is now. Changing the item's cost later does not rewrite what this order said.) 3. **Set the expected date**: Used to flag an order that is late, so a delivery that never arrived does not sit unnoticed. 4. **Save it, then send it**: A draft can be edited freely. Sending it fixes what you asked for, which is what the delivery is later checked against. **What should I order?** Inventory shows what is at or below its reorder level. That list is the honest starting point for an order. --- ## Read paid, due and change on an invoice Source: https://pro.slickcell.com/help/read-paid-due-and-change-on-an-invoice An invoice shows what was charged, what has been paid and what is left. The last of those three is worked out from the first two. It is not a field, and nobody can edit it. That is the whole reason the totals on a report agree with the invoices underneath them. 1. **Open the invoice**: Sales → Invoices, then the invoice number. Repair invoices are also reachable from the ticket they belong to. 2. **Read the three figures**: Total is what was charged, including tax. Paid is the sum of the payments recorded against it. Balance is the difference. A partly paid invoice says so; a settled one says paid. 3. **Look at the payments**: Each payment shows its method, its reference and when it was taken. Two payments on one invoice is normal: a deposit and a balance, or a split at the till. 4. **Record another payment**: Take payment, then the amount and how it arrived. The balance updates because it is derived, not because anything was adjusted. (The app checks the balance you are settling against the one it holds. If someone else took a payment while you had the screen open, it refuses rather than double-counting.) 5. **Send it to the customer**: Print opens the document actions: the paper size, the address to email it to, and a link. The link is a copy the customer can read without an account: the same figures, from the same record, so there is no second version to keep in step. (Creating a link stops the previous one working. Give someone a new link and the old one they were sent goes dead, which is what you want when it went to the wrong address.) 6. **What they see**: The shop's details and tax numbers, each line with its quantity and tax, what has been paid and what is left. Nothing about cost or margin appears: the customer's copy carries what the customer is owed an account of, and no more. **Can I just change the balance?** No, and that is deliberate. If a customer is not going to pay the rest, write the balance off. That records a reason and shows up as a write-off rather than as money that was never owed. **Does a refund reopen the invoice?** No. A refund is its own record against the invoice. The invoice stays settled and the refund is visible beside it. --- ## Receive stock against a purchase order Source: https://pro.slickcell.com/help/receive-stock-against-a-purchase-order By the end of this the stock is on the shelf, the order shows what actually turned up against what you asked for, and the supplier bill has been raised from the delivery rather than from the order. That last part is the point: bill from what arrived and a short delivery cannot quietly become your problem three weeks later. 1. **Open the order**: Inventory → Purchase Orders, then the order the delivery belongs to. The order opens on its lines, which is where a delivery is checked. 2. **Choose Receive**: Every line comes up with the quantity still outstanding filled in. That is the common case: the whole order arrived. 3. **Correct anything that is short**: Change the quantity on any line that came up short. Leave the rest. You are recording what is in front of you, not what the paperwork says. (Damaged units go in the damaged box rather than the received one. They are recorded but not stocked, so nobody sells them by accident.) 4. **Post the receipt**: Stock goes up by what you counted, each line gets a movement behind it, and the supplier bill is raised for the delivered quantity. 5. **Check the order afterwards**: An order that arrived in full reads Received. One that did not reads Partially Received, and the outstanding quantity stays on the line until the balance turns up or you close it short. **Two deliveries against one order** Receive twice. The second receipt picks up whatever is still outstanding, and the order closes when the last of it lands. **The supplier sent something we did not order** Receive what you ordered, and raise the extra as its own line or its own order. Booking it against a line it does not belong to makes the cost wrong on that part forever. --- ## Refund a sale, and say where the goods went Source: https://pro.slickcell.com/help/refund-a-sale A refund is two facts, not one: money went back, and something happened to the goods. The app asks for both, because a shop that only records the first has a stock count that drifts every time something comes back. Refunds are limited to what was actually paid, and to lines that have not already been refunded. 1. **Open the invoice and choose Refund**: Sales → Invoices → the invoice, then Refund. You can refund one line or the lot. 2. **Pick the lines and the quantity**: Only what remains refundable can be chosen. A line already refunded once will not come up again. 3. **Say where each item went**: Back to stock as new, back as used, return to supplier, scrap, write off, or no return, when the customer keeps it. This is the step that keeps the shelf honest. (Anything marked used goes to a holding area rather than straight back on sale, so a second-hand item is inspected before it is sold again.) 4. **Choose how the money goes back**: The refund is taken from the payments that settled the sale, so it cannot exceed what was actually received. **The customer paid cash but wants it back on a card** You choose the method the money leaves by. The refund still points at the original payment, so the trail holds. **What if nothing comes back?** Choose no return. The money goes back and the stock count is left alone, which is the truth of that situation. --- ## Deal with returned and faulty stock Source: https://pro.slickcell.com/help/returns-and-faulty-items Something that comes back does not go straight onto the shelf. It waits in a holding area until somebody looks at it, which is the difference between a stock count you trust and one you do not. 1. **Find the holding area**: Inventory → Faulty Items. Everything a refund sent here is listed, with what it was and why it came back. 2. **Inspect it**: Record what condition it is actually in. That decides what can happen to it and, if it goes back on sale, what it is worth. 3. **Choose what happens**: Back to stock as new when it never left the box. Back as used when it did: it gets its own used listing rather than rejoining the new ones. To the supplier when it is their fault. Scrapped or written off when it is nobody's. (Used stock gets a separate listing on purpose. Mixing a returned item back in with new ones is how a shelf stops matching its own count.) 4. **Send the supplier ones back**: Anything marked for return to the supplier appears on the returns list with its reason, so a batch can go back together with a reference. --- ## Ring up a sale Source: https://pro.slickcell.com/help/ring-up-a-sale By the end of this the sale exists as an invoice, the money is recorded against it, and the stock has come off the shelf, all as one event, so there is no state where the sale happened but the stock did not. You need the till open. If the cash drawer is closed the app says so before it lets you take cash. 1. **Open Sales**: The POS tab is the till. The cart starts empty with a walk-in customer attached. 2. **Add what they are buying**: Search by name, SKU or barcode and add it. An accessory goes on by quantity. A used handset goes on as a single unit: you pick the actual handset, and its price comes from that unit rather than from the model. (Scanning is quicker: the search box takes a barcode scanner, and a staff phone can act as one.) 3. **Attach the customer, if there is one**: A walk-in sale needs nobody. Search for a customer when you want the sale on their record, and you must, if they are not paying all of it today. (The app will not let you leave a sale part-paid against a walk-in. A balance owed by nobody is a balance nobody can chase.) 4. **Take the money**: Choose the method and the amount. To split it, add a second payment line, card for part, cash for the rest. The change due is worked out as you type. 5. **Complete the sale**: The invoice, the payments and the stock movement are written together. If anything fails, none of it is written and the cart is still there. 6. **Print or send the receipt**: Print to the thermal roll, or send it. The receipt carries a code the customer can scan to see the invoice again later. **Can I sell something that is out of stock?** Not a device unit. You are selling a specific handset, and a sold one is not available. For parts and accessories the app will warn you rather than stop you. **The customer wants to pay half now** Attach them to the sale first, then enter the part payment. The balance shows on their record and on the invoice. --- ## What each role can do Source: https://pro.slickcell.com/help/roles-and-what-they-can-do Five roles, and the differences between them are about consequence rather than seniority. Anything that can quietly change money that was already settled is held back. 1. **Owner**: Everything, including billing, the plan and removing people. There is always at least one. 2. **Manager**: Runs the shop: tickets, stock, the till, reports, and the reversals, voids and write-offs that the counter cannot do. 3. **Technician**: Works the bench. Tickets, parts, stock and the repair side of the money. Can take a payment and issue a refund at the counter. 4. **Sales**: The counter. Rings up sales, books repairs in, takes payments and issues refunds. Does not void or write off. 5. **Accountant**: Reads the money (invoices, payments, reports, the cashbook) without being able to change any of it. (A read-only role is not a lesser one. It is the correct shape for someone whose job is to check the numbers rather than make them.) **Can I give one person a bit more?** Roles are fixed sets on purpose. A permission matrix that anyone can adjust becomes a permission matrix nobody can explain. --- ## Run a stocktake Source: https://pro.slickcell.com/help/run-a-stocktake By the end of this the system's figures match the shelf, and every correction has a count behind it rather than someone having typed a new number. Nothing moves until the count is approved. A part-finished count is safe to leave. 1. **Start a count**: Inventory → Stocktake → New count. Choose what you are counting: everything, just the parts, just the accessories, one category, or one supplier's items. (The system's quantities are captured the moment you open the count. Sales during the count are handled; you are not racing the till.) 2. **Count the shelf**: Enter what is actually there, line by line. Leave anything you have not reached. It is not treated as zero. 3. **Submit the count**: The variances appear: short, over, and by how much, with the cost of the difference. Nothing has changed yet. 4. **Get it approved and applied**: A manager reviews the variances and approves. Applying the count is what moves stock, and each correction posts as its own movement so the reason is visible afterwards. **Something sold while we were counting** That is fine. The count is compared against the snapshot taken when it opened, and movements since then are accounted for rather than overwritten. **Can I count just one shelf?** Yes: scope the count to a category or a supplier. A full count of a busy shop is rarely the right first move. --- ## Share a catalogue, and decide what buyers see Source: https://pro.slickcell.com/help/share-your-wholesale-catalogue By the end of this the shops you have granted access to can browse your items, see the price you set for them, and order against it without asking you for a list. Cost prices, margins, internal notes and reorder levels are never shared, in any mode. That is not a setting you have to get right. It is what the catalogue is allowed to contain. 1. **Turn the catalogue on**: Supplier Operations → Catalogue Sharing. Set the sharing mode: off, every active business customer, or only the ones you select. Off is the default, so nothing is shared until you decide it should be. 2. **Choose what quantity shows**: Quantity visibility is the setting above. If you pick availability only, set the low-stock threshold too. That is the figure at which an item starts reading as low rather than in stock. 3. **Price the items you want to sell**: In the shared items list, switch on the items you trade, and give each one a wholesale price, a minimum order quantity and a lead time in days. Leave the price blank and the item shows as price on application, which is the right answer for anything you quote per order. (Search your inventory to find items rather than scrolling: the list shows a page at a time.) 4. **Decide who gets in**: A shop asks for access and the request appears here. Approve it for your whole catalogue or for named categories, and set how long the access lasts. Access already granted is listed underneath, and you can revoke any of it, the shop is told either way. (You can also set access to approve automatically, in which case a request from a shop is granted the moment it is made.) **Can I show different prices to different customers?** Not today. Every buyer with access sees the same wholesale price you set on the item. Where a price genuinely depends on the customer or the order, leave it blank so the item reads as price on application and quote it on the order itself. **Will a buyer see what an item cost me?** No. Cost prices, margins, internal notes and reorder levels are never shared, in any mode. The buyer's view is built from a separate, restricted list of fields rather than from your inventory record. **What happens when access expires?** The shop stops being able to browse the catalogue. Anything already ordered is unaffected: an expiry ends browsing, not the relationship or its history. --- ## Start a free trial Source: https://pro.slickcell.com/help/start-a-free-trial By the end of this you will have a shop of your own in the app, on a 14-day trial of the plan you picked, with the dashboard open. It takes a few minutes and nobody from us needs to be involved. You need an email address you can read straight away: the second step sends a code to it. 1. **Pick a plan on the pricing page**: Choose Starter, Professional or Supplier Pro and monthly or yearly, then use that plan's trial button. The choice travels with you and arrives already selected at step five. (Come straight to the sign-up page without choosing and the app recommends Professional for a repair shop. You can change it in step five either way.) 2. **Create your login**: Your name, email and a password. That is the whole form, no plan to re-pick and no card. 3. **Enter the code from your email**: A six-digit code arrives at the address you gave. Type it in, or paste it. If it has not arrived after a minute you can ask for another one. 4. **Set up the shop**: Step one: whether you are a repair shop or a supplier, the shop's name and address, the country, which sets the currency, and whether you charge tax and at what rate. Step two: your opening hours, used for due dates and the open/closed marker on the dashboard. (Close the tab halfway through and your answers are still there when you come back.) 5. **Confirm the plan and open the shop**: Step three shows the plans you can pick from with the one you chose already selected. Tick the terms and choose Launch. The trial starts on that plan; you are not asked for a card. 6. **You are on the dashboard**: The shop exists and is empty. The next things most owners do are bring stock in and book a first repair, both linked below. **Does the trial need a card?** No. The trial runs for 14 days on the plan you chose. When it ends you pick how to pay, or you stop. There is nothing to cancel. **Can I change the plan later?** Yes, from Settings → Billing. Every plan has every feature; they differ in team size, locations and discounts. **I am a supplier, not a repair shop** Choose Supplier in step one. You will see Supplier Pro as your plan. --- ## Take a deposit on a repair Source: https://pro.slickcell.com/help/take-a-deposit A deposit is money against a job that has not been billed yet. Recording it here means nobody has to remember it at collection, the bill already knows. 1. **Take it at booking, or later**: The new-ticket panel has a payment step. On a ticket that already exists, Take payment does the same thing. 2. **Enter the amount and how they paid**: Cash needs the drawer open; the app says so if it is not. 3. **Look at the balance**: The ticket shows the agreed price, what has been taken and what is left. That figure is worked out, not typed. 4. **Collect the rest at handover**: When the invoice is raised the deposit is already applied, so what is asked for at the counter is the balance and nothing else. **The job was cancelled after a deposit** Refund it from the ticket. It came in as a real payment, so it goes back as a real refund rather than being deleted. --- ## Set up tax the way your shop charges it Source: https://pro.slickcell.com/help/tax-on-your-sales Your shop's default rate was set when you opened the account. Most shops need one or two rules beyond it, and this is where they go. A rule is a rate plus how it is applied, and it can be pointed at a category or a condition rather than at everything. 1. **Open the tax rules**: Settings → Tax rules, or Sales → Tax Rules. The default is the one already there. 2. **Understand the three treatments**: Exclusive adds tax on top of the price. Inclusive means the price already contains it. Margin means the tax is on the difference between what you paid and what you sold it for, not on the whole price. 3. **Scope a rule**: A rule can apply to a category, or to a condition: which is how used devices get treated differently from new stock without anyone remembering to switch anything at the till. (A line picks up the rule that fits it. Nobody has to choose the right tax on a sale.) 4. **Check it on a sale**: Put one of the affected items on a sale and look at the tax on the line. That is the fastest way to know a rule is doing what you meant. **We are not registered for tax** Then say so in Settings. No default rule is created, and nothing is added to your prices. --- ## Take a handset in part-exchange Source: https://pro.slickcell.com/help/trade-a-handset-in By the end of this you have bought a handset, paid the seller, and put it on the shelf at a cost you can prove, so when it sells, the profit on it is real. Buying a device is a purchase, not a note in the drawer. The record keeps the seller, the inspection and the money together. 1. **Start a trade-in**: Trade In from the dashboard, or Inventory → Trade-ins. Take the seller's name and a contact number. 2. **Record the device and inspect it**: Brand, model, storage, colour, IMEI: then the condition of the screen, the back, the camera, the port, and whether it is locked to an account. This is what your offer is based on. (A device still signed in to an account cannot be resold. Record it honestly here rather than discovering it at the counter later.) 3. **Make the offer**: Enter what you expect it to sell for and what it will cost to refurbish. The offer is what you are paying the seller, and the difference is visible before you commit. 4. **Approve and pay**: Approving fixes the offer. Recording the payment takes it out of the till, so the drawer and the day's takings agree. 5. **Put it on the shelf**: Add it to inventory and it becomes a device unit at the cost you paid, ready to sell. **The customer changed their mind** A trade-in that has not been paid can be cancelled. One already paid is a purchase you made, so it stays on the record.