Table of Contents

Anonymous Shopping

Anonymous shopping is the site that is crawled and indexed by google and others.  

Anonymous shopping is not handled by the system - however all required data is provided to an anonymous site to use on request by the site (most sites automate a data request nightly and request only updates).

Normally the same structure is used as the logged in site - just the pages are wired to the local site data instead of our system.  So the pages are normally a copy of the logged in pages - this helps make the user experience seamless.

A user can browse the anonymous site, add items to a cart with quantities and using RRP - when they get to the checkout pages and either provide login details or create a login - they will transition seamlessly to the logged in shopping site.  The cart on the anonymous site is passed to the logged in site and becomes a sales order that is awaiting payment or fulfillment (depending on the customers terms).  Any credit card payments are managed via the logged in site.

External Shopping Sites (eg Shopify or Magento or others)

Where you use an external shopping site consider the following development may be required

1. External sites are an integration
   1. Processes in either system can push data to the other system as a step - ie as it happens
   2. Batch process can request or push data to other systems regularly - ie every 15 mins
   3. Integrations typically involve many touch points leading to more possible points of failure and related expense
   4. We recommend avoiding external shopping sites - however we know not all customers will follow that advice
2. Available stock feed will be required regularly to update the site and should lie about the stock levels
   
   1. Example 100 in stock, 50% of sales via website, 100 will last 4 days at normal sale levels and take 5 days to restock, Tell website there are only 50 in stock
3. May want customer credit notes to be made available on the website
   1. Requires current unallocated amount - not just credit note amount
   2. Recommend batch update > then a live check in order checkout
4. Orders may be picked up or may be pushed in
   1. Pushing orders uses XML via gRPC and is the most modern integration method
   2. Orders may be paid or part paid requiring a payment to also be created
   3. Orders will have to pass validation checks prior to picking, Address, stock available, stock known etc.
5. Customer information will be required in both places
   1. Option 1 - changes pushed from website to our system and from our system to website as they happen or in batch
   2. Option 2 - update addresses on debtors as orders flow in
6. Customer login may dictate customer setup
   1. Business customers with multiple stores may require each store to login and not see other stores details
      1. May require parent child relationships (100% owner set on child) in SaaSplications with Child debtor set to "Invoice my Parent".  Hence orders will be on child accounts but invoices will all be in the one parent account.
7. Specialist products or processes can be managed across the systems
   1. Eg items that can be split into smaller components
   2. Configuration products
   3. Repairs
   4. Bulk returns with internal inspection processes
   5. others as defined required by each business
   6. Note that the more processes being integrated the less likely an external integration is the best solution.

Logged in Shopping

Once a user has logged in - all information is provided by our server.  This makes it easy to provide customer specific pricing, promotions, products, terms, invoice and payment history etc - any information about the customer can be provided.  For example - if the customer has a partially completed unsubmitted order they can open it and continue adding to it then submit it.

Customers creating a login for the first time may simply enter their email address in a checkout page - we can then use that to create a login and move them to a logged in status - while also sending them a password for future use.  So the experience can be seamless and simple for the customer.

Customers that are COD terms may use credit cards and save card details for future reuse - see Customer Credit Cards.  The funds are reserved when going to pick and only taken once the pick is complete - so the customer is only charged the goods you have been able to send to them.  This reduces refunds and back order problems often seen with pay in advance systems.

People that are contacts at multiple customers can change roles within the shopping site - to shop on behalf of business 1, then business 2 and then personal shop - all in the same login session.  This is useful for customers that have buyers that represent multiple outlets.

Web Portals

If you need a web portal for employees (eg delivery drivers) or customers (job portals) or suppliers

1. Define the business process that you need to support
2. Talk with us about the process steps in detail
3. Create the screens and then wire them up using the JavaScript SDK - or we can do that for you.

Example portal - Tours - Drivers Portal

The ideal webstore, customer or employee portal

• uses the same information and business processes as the rest of the business
• allows you to decide which functions a customer can do and what they cannot do - and allows treating different customers differently
• sits inside a richer site with blogs, brochure pages, etc.  Hence the common use of Wordpress - however the JavaScript SDK means any Javascript enabled environment can be used.

Because our system provides the data, images, and business processes (eg shopping cart, recommended products or order qty's, etc) - building logic and flows on the web is very fast because they already exist in the system so building a customers web experience is drawing screens and then wiring them up.

Where to start

We have starting points for your business with working examples which you can use or slightly modify - however - every business is different and it is common to design and build what you want without using the starting point.

So look at your competitors, find companies you would like to emulate, talk to your customers about what they want and build up a wireframe for discussion.  Wireframe (example Balsamiq or Mockflow) design the screen experience / flows / information you would like to present then we (or your web developer) can quickly (in weeks) have things exactly as you would like them to be.

Because our system is so flexible - you can change how you want it to be once you test it or after customers or employees provide feedback from using it.

Javascript and understanding our business objects

See also information on the JavaScript SDK (that has been also made available as a Wordpress Plugin - see Useful information when dealing with WordPress) makes it as easy as wiring up the fields on the screens to the system.

When building the webpage flow - we will build screens in the back end that support your flows and viewing them can be used to gather field information to use with the SDK.

How to review the business objects

Login to the back end screens using the same login as you would use for the website - then use the navigator to review the objects, fields etc.  You can test the server responses to any flows here - to check if any problems are due to the server response - or the webpage build.

to find the field names, queries etc and test if the system is returning the information you need to show on the screen from the query - click to open the traffic debug and view the objects and fields.