Shops, web and marketing

These are the customer-facing and everyday apps. They demonstrate well, which makes them useful in sales conversations — and they are frequently how a client first decides Odoo is worth having.

Point of Sale

POS is a shop till that shares products, stock, customers and accounting with everything else. That sharing is the entire point: a sale in the shop reduces the same stock a delivery would.

What actually matters when implementing it:

Sessions. A session opens, sales happen, the session closes with a cash count. Closing produces the accounting entries. The open-and-close cycle is what finance will ask about, so understand it before anything else.

Payment methods. Cash, card, and whatever is local. Each posts to a journal — and getting that mapping wrong makes the daily close disagree with the bank.

Offline behaviour. POS keeps working when the connection drops and syncs afterwards. Clients always ask, so know the answer.

Hardware. Receipt printers, scanners, cash drawers. Find out what the shop already owns before promising anything.

Multi-branch. One database, several shops, stock per branch. This is where POS meets the warehouse design from stage 04.

Before — on paper 8 steps

1. Three branches run three separate tills and three Excel files.
2. A customer asks whether another branch has the item.
3. The cashier telephones that branch. Nobody picks up.
4. The customer leaves and buys it elsewhere.
5. Each evening the cash is counted and written in a book.
6. The books reach head office weekly, or when somebody drives over.
7. Transfers between branches are agreed on WhatsApp and recorded nowhere.
8. At year end the physical count disagrees with every file.

A sale lost because the information existed, in a building four kilometres away.

After — in Odoo 5 steps

1. One database, three shops, one product list.
2. The cashier sees the stock of the other branch on the same screen.
3. The session is closed with a counted cash figure and posts its own entries.
4. A branch transfer is an internal movement, recorded as it happens.
5. Head office sees today's sales per branch without telephoning anybody.

The branches stop being three businesses that share a logo.

Website and eCommerce

The Website builder is drag and drop, and clients can run it themselves after a short handover. Do not turn yourself into their web designer; configure it, train them, step back.

eCommerce is the part that needs a consultant, because it is not really a website question:

• Which products are published, at which prices, with which taxes?
• How is stock shown — real availability, or always available?
• Delivery methods and shipping costs.
• Payment providers, and what happens when a payment half-completes.
• What the order becomes internally: a quotation, or a confirmed order?
• Who handles a customer ordering something that just sold out in the shop.

That last question is the one that separates a working online shop from a source of daily complaints, and it is a stock design decision, not a web one.

Marketing

Email Marketing and SMS are straightforward: lists, templates, send, measure. Marketing Automation builds multi-step campaigns that react to behaviour, and is Enterprise only. Events and Surveys are self-contained and easy wins.

Your job here is configuration and deliverability — sender domains, unsubscribe handling, list hygiene — not writing the client’s campaigns.

The quiet productivity apps

These are rarely in the scope and are often what makes users like the system.

• Documents — filing with workspaces, tags and automated rules. Frequently the app that finally replaces a shared drive nobody could search.
• Sign — electronic signature on contracts and forms. Very little configuration, and clients love it.
• Knowledge — internal articles and procedures. A good place to put the documentation you write during the project, where staff will actually find it.
• Approvals — simple internal request-and-approve flows.
• Discuss, Calendar, Appointments, WhatsApp — communication, meeting scheduling and messaging.

Learn what each does, even briefly. A large share of client requests that sound like custom development are one of these apps.

Where beginners go wrong

• Treating POS as separate. Its stock and journals belong to the same design as everything else.
• Mapping payment methods carelessly, so the daily close never balances.
• Becoming the client’s web designer.
• Publishing eCommerce stock without deciding the availability rule.
• Assuming Enterprise apps are available. Check the edition.
• Ignoring the productivity apps, then quoting custom work for something Documents or Approvals already does.

Practise this

1. Open a POS session, sell, close it with a cash difference, and find the entries produced.
2. Add a card payment method posting to its own journal, and check the closing figures.
3. Publish three products online with different taxes, and place an order as a customer.
4. Sell the last unit of a product in POS and see what the website then shows.
5. Set up a Documents workspace with a rule that files incoming vendor bills automatically.
6. Build a Sign template for a simple contract and send it to yourself.

Exercise 4 is the useful one. It makes the shared-stock idea concrete, and it is exactly the scenario a retail client will ask you about in the first meeting.