Home

Introduction

Third Party Fulfilment Specialists (3PLs) play a key role in e-Commerce. OrderFlow has been designed from the ground up to meet the requirements of 3PLs.

This document is aimed at 3PL organisations who are using OrderFlow to meet the fulfilment needs of their clients.

This document aims to provide to provide practical information about

the most important features on the system that relate to the challenges 3PLs face
how to build on their own in-house capability, allowing them to service more client requirements without requiring the direct involvement of Realtime Despatch
how to become more self-sufficient in client 'onboarding', allowing each successive new client to be taken on at lower cost

A big challenge for 3PLs is providing the service their customers expect while keeping costs under control. Having software that is designed to meet this challenge is a start, but this is not all that is required. 3PLs have to be aware of the costs that they are likely to incur when taking on new customers, and understand how they can control these costs. This document provides a framework for doing this, both from a project management and technical point of view.

What Makes 3PLs Different?

3PLs provide warehousing and fufilment services to multiple retailers and other organisations (their clients).

Each client may have different requirements and be associated with multiple sales channels, each with its own integrations, import formats and even courier rules.

For this reason, a 3PL environment will tend to be inherently more complex, and dynamic. Even if individual client configurations are not changing much, the system as a whole will change as new clients get introduced.

3PL Services

Clients expect 3PLs to manage their stock carefully and ship their items promptly according to service level agreements, and to do so in a visible way. For this reason, visibility and reporting are key requirements.

Warehouse

OrderFlow provides for this through a read only user access to the system, and through powerful reporting functionality, from custom reports and dashboards, scheduled reports with automatic notifications, dashboards. Common reporting requirements are met through built-in reports on the key metrics.

3PLs can differentiate themselves through the level of service they provide, by finding the right balance between cost-effectiveness and a 'one size fits all' approach which does not allow them to fully address the needs of their largest, most demanding clients.

A 3PL may vary its offering across its clients in many ways, such as:

customised paperwork and despatch notes
modified courier choices or despatch workflows driven by differences in the nature of the products being shipped
different integration and import data format options
different reporting and notification options

OrderFlow's 'scoping' feature allows for shared configurations to be easily reused, while configurations that are bespoke to particular clients can easily be applied at an organisation or even channel and site basis.

Billing

3PLs need flexible billing that makes it easy to bill their clients. As with the services provided, a 'one size fits all' won't be appropriate, both in terms of the metrics used, as well as the rates applied to them.

Billing

A 3PL needs to be able easily set up custom metrics, and rates on a per client basis, and to generate billing reports which can be used to support invoicing with minimal additional manual intervention.

OrderFlow services this requirements through a billing module which supports monthly or weekly billing.

Customer Onboarding

The other area of major importance to 3PLs is efficient take-on.

The challenge for a 3PL is to be able to cost effectively bring new clients onto the system. For clients who are shipping large volumes, a significant onboarding cost may be acceptable, but for smaller clients, the cost of onboarding may be a key factor in determining whether a client will ever be profitable.

OrderFlow has many built-in features to make taking on new clients as easy as possible for 3PLs.

However, the features on their own are not enough. Just as important is the knowledge transfer that will ensure that in time you (the 3PL) are able to take new clients quickly and cost effectively.

Understanding how this process works is the subject of the next section of this document.

Checklist for New Prospects

Below is a quick checklist that should be considered in the early stages of any discussion with potential new clients.

It aims to help identify requirements that might impact significantly on the cost and timescales of the implementation if the prospect becomes a customer.

Sales channels

How many sales channels will present orders to the OrderFlow platform?
Are orders from multiple sources going to be received from a single channel (i.e. Amazon and eBay orders routed through the shopping cart)?
Are these sales channels supported by existing integration modules available within OrderFlow?
Are all SKUs uniquely identified with a single reference that is used by all the sales channels and will be contained within the order data received by OrderFlow?
Do the stock updates pushed to different sales channels need to be configured to minimise the risk of overselling?
Does the prospect have a testbed environment for each of the sales channels, are these testbeds representative of the live environments?

Products

Which sales channel will be the 'master' that is be used to update the product catalogue within OrderFlow?
Will all the SKUs be uniquely barcoded when they are received, is there a requirement to add individual barcodes to some or all products as part of the delivery receipt process?
Is there a need to support anything other than the 'default' product type (e.g. product kits, product bundles, tracked products, virtual products etc.)
Do different SKUs need to be need to be held in specific types of location or in distinct areas of the warehouse?
If the prospect requires specific rules to be applied to some products will the product information received from the master sales channel provide sufficient information to identify the relevant products? a bit unclear about this

Couriers

Which couriers and courier services are required to support the prospect?
Are these courier services supported by existing integration modules available within OrderFlow?
Will the order information received from the prospect contain information that specifies which service should be used to does OrderFlow need to apply more complex courier selection logic?
Will the information required to apply courier selection logic always be available as part of either the order or product data (e.g. will weights always be part of the product definition if they are required to calculate a shipment weight)?
If orders need to be shipped internationally does the product or order information contain the information required to create the necessary customs information?
Is the courier selection logic channel specific?

Paperwork

What recipient paperwork is required and does the layout vary significantly from that used by other clients?
Can the prospect provide an example of the required paperwork?
Does the paperwork contain pricing details, is OrderFlow required to calculate any of the pricing elements or is all the necessary information contained within the order data received from the sales channel?
Are there any variable elements that require logic to be embedded in the paperwork?
Is product specific paperwork required (OrderFlow datasheets)?
Is a returns label or returns form required?
Is the paperwork channel specific?

Returns

Do customer returns need to be supported?
Does the returns process differ significantly from those already supported for other clients?
Does the returns process require any integration with client systems (e.g. to create an RMA or pass back details of the returns that have been processed by OrderFlow)?
What information does the prospect need to process customer refunds or the despatch of replacement items?
Is the returns process channel specific?

Internal Users and Client Access

Will access to the new client organisation within OrderFlow need to be limited to specific members of staff?
Will the prospect require read-only access to OrderFlow?
Will the prospect need to be given the ability to make any changes within the OrderFlow environment?

Reporting and Dashboards

Will the prospect need access to any new reports or dasboards that are not already provided to existing clients?
Do these need to be defined as automated periodic reports or will the client run them manually from within OrderFlow?

Billing

Will the billing metrics differ from those already supported for other clients?

Purging and Anonymisation

Has the data purging policy in place within the live OrderFlow environment been made clear to the prospect?
Does the prospect have any specific requirements for the anonymisation of their data?

Preparing for the Challenge

Your clients expect a high degree of professionalism, in the way that you manage their stock, in the promptly fulfilling their orders, and in accounting for your activity. Having the right system in place is crucial. The system setup is not a one off exercise. Each time you take on a new client, system setup will need to be performed. Even the configuration for your existing clients will need to change periodically to reflect new requirements. Throughout the whole period, you will continually be looking to operate more efficiently, and to add to your capacity to service your customers.

Each one of these situations will require changes to the OrderFlow environment, which will in turn have cost implication. You should be aware of these, but over time look to minimise these costs by working more cost effectively.

Our interaction with 3PL customers is designed around a long term process to improve your understanding of the system so that you can make changes cost effectively. Whether this involves running your day to day operations, or taking on new customers, our goal is to help you realise the full potential of OrderFlow, while at the same time keeping costs under control.

In the early days, our initial focus is to get you up and running smoothly with your first client. As you introduce more of your client base onto OrderFlow, we aim to help you to become more self-reliant in bringing on new customers, and increasingly, take advantage of some of the more advanced features that OrderFlow has to offer.

Involvement of Realtime Despatch

The initial launch of the first client will be led by Realtime Despatch. The process for this is covered in detail in the Customer Implementation Project Guide. If OrderFlow is not yet live in your 3PL warehouse, we would encourage you to read this document to help you become more familiar with the implementation process.

Once you are live and up and running with your first client, you will then want to start bring other clients onto OrderFlow. Typically, we will still be very involved in taking on your second client. However, emphasis during the second implementation will be on building your capability, so that you can start doing more of the onboarding. This document aims to facilitate this process.

Once you have implemented two or three clients, our further involvement will depend on your capabilities. We may only do some of the work, for example, just the more complex configuration. How far you go down this route will of course depend on your in-house technical capability, your willingness or desire to be more self-sufficient, and the extent to which you are trained to take on more of the technical tasks.

Project

Positioning Your Offering

Every 3PL wants to provide the best service they can offer, and we know only too well how difficult it is to say 'No' to client requests. However, there is an obvious cost implication that goes with the level of service that is offered.

Of course, all 3PL clients are different. Some will want the best quality service possible, and will have the volumes and funding available to support this. Others are more cost conscious, and their primary concern is to get the job done at the best possible price.

It is important to consider what kind of service it is realistic to provide, and how the service can be tailored to match the service level.

Most 3PLs will bill their customers based on a variety of metrics, relating closely to warehouse activity, for example to order volumes, receipts and space utilisation. In that sense, there is a close association between their revenues and their activity. However, the cost of taking on a new customer tends to be an up front cost. The 3PL may choose to absorb a portion of this cost initially, or may choose to pass this cost on directly to the client.

In the latter case, it is particularly helpful to do some up front requirements gathering prior to committing to a new client take on, to limit the extent to which unanticipated costs need to be passed on to the client.

These aspects are covered in more detail in the Onboarding Planning section of this document.

The exact volume thresholds at which it becomes economic to provide different levels of service will vary according your familiarity with the system, your in-house technical capability, and the margin you are receiving per order shipped. Some examples are shown below as a guideline for a representative B2C operation.

Note also that API-based integrations are suitable for high volumes and involve lower effort to run on a day to day basis, but do involve a lot more setup effort. These are also covered in the table below.

Example Service Volume Thresholds

Daily Orders	Example Integrations	Example Service
Under 20	None	manual data entry
20 to 50	Manual entry	or standard CSV file upload
50 to 100	Custom CSV file upload	standard API integration
100 to 200	Custom CSV file upload	standard API integration with only limited customisations
Over 200	More advanced or customsed API integration	More advanced customisations, bespoke workflows or development work may be justified at these volumes.

As the above table shows, there may be times where it will not make commercial sense to bring a customer onto OrderFlow, as the revenue that is likely to be generated will not justify the cost of taking that customer onto the system. Of course, the order thresholds above are only a guide and may vary from client to client, but illustrate the need to match the offering provided to the prospective client with the revenue they are likely to generate.

Thoughts on an Ideal Organisation Setup

The 3PL project manager responsible for onboarding a new client needs to progress two conversations simultaneously, one with the client whose orders you are fulfilling, and the other with Realtime Despatch, who are helping you to get the job done.

It is both a people-oriented and technical role. A people-oriented task in managing the expectations of your clients, and a technical role, at least in the sense that getting the job done often involves technical tasks.

Another crucial role for a 3PL organisation is the IT Manager. Having an IT Manager or Executive who has the technical skill and interest in getting the most out of OrderFlow can be a tremendous cost saver for the 3PL business.

An effective IT Manager will ideally be able to:

perform the key project management role in new client implementations
coordinate with Realtime Despatch Customer Delivery as well as the 3PL clients to deliver changes to the OrderFlow environment
understand and articulate requirements for new features and complex configurations
troubleshoot IT issues local to the warehouse, concerning printing, networking, etc.
be one of the main 'power users' of the OrderFlow software, serving as a point of contact and information for operational staff
take responsibility for the user acceptance testing (UAT) of new software releases

It is important to note that while Realtime Despatch may play a role in actively project managing the first client implementation, responsibility for this task should rapidly move to the 3PL with each successive implementation. This is because the 3PL is the only party that actively maintains relationships with all parties involved, including the client and Realtime Despatch.

An IT manager (or staff within the 3PL's IT department) can be even more effective in an OrderFlow environment if they are able to take their knowledge a step further, taking on technical tasks such as:

performing basic setup for new client implementations
setting up and testing e-Commerce and courier integrations for new clients
setting up custom import data mapping, courier selection and shipment batching rules
creating custom reporting and even dashboards
creating bespoke paperwork

With capabilities in these areas, the 3PL customer will be less reliant on Realtime Despatch's Customer Delivery team for some of the most common day-to-day system implementation tasks. This is a clear cost saving opportunity.

All of these activities are covered by either customer accessible published documentation and Step by Step HowTos, or a combination of both.

Realtime Despatch is able to provide advanced technical training to 3PL customers looking to build their capabilities in this area.

Planning for Onboarding

From the point of view of the 3PL business, onboarding is the process of bringing on new clients. From a systems point of view, a 3PL client takeon should be thought of as a project in itself.

For straightforward or vanilla implementations which largely involve just a replication of an existing configuration, the project will be small in scope. However, for larger, more bespoke clients, the takeon may be a significant project in itself. It is very helpful to think about the task in those terms, so that each project can be planned and managed appropriately.

The planning stage involves two main activities:

Requirements Gathering to determine the scope and to get an indication of the likely cost of the project.
Activity or Task Planning to ensure that the necessary activities are effectively planned, both in terms of resource requirements and timing.

High Level Requirement Considerations

It is very useful to have a high level understanding of what types of tasks are involved during an onboarding process, and at least an order of magnitude understanding of effort that may be involved.

In this section we detail some of the areas in which requirements may vary considerably, and what impact this can have on the effort required.

The table below gives an indication of some of the example requirements which may determine the overall effort. In the table below, we classify these example requirements according to whether they are simple, medium or complex. Needless to say, the amount of time that you would need to budget can vary greatly depending on whether we are dealing with a simple or complex requirement.

Example Requirements

Areas to Consider	Simple Requirement	Medium Requirement	Complex Requirement
Basic Setup	Customer does basic setup without supervision	Customer does basic setup with supervision	All setup done by Realtime Despatch
Project Management	No project management required	Project management done by customer	with involvement of Realtime Despatch
e-Commerce Integration	Replicate setup from existing channel	Make use of existing integration with bespoke elements	New bespoke e-Commerce integration
Data Import Rules	Use import rules from 'cloned' channel	Simple bespoke import rules	Complex bespoke import rules or data transformations
Courier Integration	Reuse existing courier integration	Make use of existing courier integration, but with different services or destinations	New courier integration
Courier Selection	Reuse existing courier selection logic	Simple bespoke courier selection logic	Complex bespoke courier selection logic
Customer Paperwork	Reuse existing paperwork with different logo	Simple bespoke despatch note	Complex bespoke despatch note
Reporting and Dashboards	Enable existing reports	Simple additional reports for client	Complex reporting requirements for clients

It may not be helpful to try to put a specific time estimate of the above elements, but the following yardstick may be useful:

the Simple Requirements described above are ones that could be managed as part of the overall project effort, with each individual task likely to involve 2 hours or less of effort
the Medium Requirements are ones which would need to be project managed individually as separate pieces of work, but would tend to be measured in hours rather than days of effort. We would ordinarily seek approval for the work required for these tasks.
the Complex Requirements are ones that individually may require anything around one or two days of effort to a number of weeks, depending on the area. These we would not undertaken without specific approval to proceed with the work required.

Requirements Scoping

The details discussed in the previous section will hopefully help determine how you as the 3PL should be positioning your commercial offering client prospects.

In order to translate this into a specific project plan, it is useful to get as much detail as possible on the requirements for the project. For this reason, requirements gathering is a task typically undertaken by the 3PL in direct consulation with the client. Realtime Despatch does not maintain any direct relationship with 3PL clients unless this is necessary to address specific questions or technical issues.

In many cases, it will be appropriate to get this information before committing to take on the new client. This can be helpful not only in planning internally for warehouse activity, but also for planning for the system tasks required to bring the customer on, and for ensuring that there is a shared understandng on the cost implication of a new client takeon.

Some of the key questions that should be covered as part of this requirements gathering process are listed below.

Overall Profile

These questions are around the client's business, in terms of its nature and scale.

Does the new client have an existing business (i.e. a current daily order load), or is this a new business?
What order volumes will need to be fulfilled? Will orders be received continuously, daily or only sporadically?
How many SKUs will the 3PL be maintaining stock for the client?
What is the profile of the orders in terms of average number of lines, proportions of single line and single item orders?
To what destination countries is the client shipping?

Answers to the questions above will give an indication of the likely scale and complexity of the implementation task, and the likely benefits of customising the implementation to match the client's order and product profile. It will help to determine what kind of customisation is viable from a cost/benefit point of view.

Sales Channels

If the client is operating multiple sales channels, then there are some additional questions to consider:

How many sales channels will present orders to the OrderFlow platform?
Are orders from multiple sources going to be received from a single channel (i.e. Amazon and eBay orders routed through the shopping cart)?
Are these sales channels supported by existing integration modules available within OrderFlow?
Will all of the sales channel share the same product catalogue?
Are all SKUs uniquely identified with a single reference that is used by all the sales channels? Will this reference be contained within the order data received by OrderFlow?
Is there a 'master' channel that the client uses to maintain an overall view of products and inventory across the sales channels?
Do the stock updates pushed to different sales channels need to be configured to minimise the risk of overselling?

Answers to the questions above will help identify complexities in the implementation that will require careful consideration and potentially implementation effort.

e-Commerce Integration

These questions deal with the mechanics of getting the details of products and orders from the client's e-Commerce system into OrderFlow, Where appropriate, it will also cover notifications on shipments, stock updates, and returns from OrderFlow to the client's e-Commerce system.

Note that if more than one integration is required for different sales channels, these questions will need to be specified separately by sales channel. It also covers the any notifications that go from OrderFlow to the e-Commerce system, for example, to handle stock updates and shipment despatch notifications, plus any other integration requirements.

What type of integration will be used for the client? Options here are direct integration using the e-Commerce system's API, direct integration using the OrderFlow API, or indirect integration using file transfers?

If we are planning to use direct integration using the e-Commerce system's API, then the following questions are applicable:

What e-Commerce system is the client using? Is this a system for which there is already an integration with OrderFlow?
Does the client have a test instance of their e-commerce system(s)? This will make the implementation much easier!
Are there any non-standard configuration points in the client's e-commerce system(s)? Are we able to use use out-the-box integrations?
What data flows need to be covered in the integration? The most widely used data flows are order import, product import, inventory notification, and shipment despatch notification.
Does pricing information need to be captured for the purposes of reporting or paperwork generation?

Products

The following are more detailed questions about the product that will have an impact on the customer takeon requirement.

What is the nature of the products that the client is selling, in terms of size, average value?
Will all the SKUs be uniquely barcoded when they are received, or is there a requirement to add individual barcodes to some or all products while receipting?
Is there a need to support anything other than the 'default' product type? Examples of other product types include kits, product bundles, tracked products, virtual products etc.
Do different SKUs need to be need to be held in specific types of location or in distinct areas of the warehouse?
Do products need to be batch-tracked, or do they have expiry dates?

Depending on the answers to the above questions, setup will be required. In the most simple case, the 3PL will be fulfilling simple products that have been barcoded prior to being received in the warehouse.

Courier Integration

This concerns the choice and use of couriers for shipping of parcels to the end customers.

Which couriers and courier services are required to support the client?
For which of these is international shipping required? Please specify country destinations.
Are these courier services supported by existing integration modules available within OrderFlow?
Do you the 3PL already have established relationships, both technical and commercial, with the courier required for integration?
Will the client be using their own courier customer accounts, or will they be using those held by the you the 3PL?
Will the order information received from the client specify which services should be used, or does OrderFlow need to apply custom logic to determine the appropriate choice?
Is the courier selection logic channel specific?

Of course, the effort required for the implementation may vary considerably depending on the answers to the questions. If the new client is using the same courier services and logic already implemented elsewhere on the system, then the implementation effort may be trivial. However, if new courier logic, services, destinations or even integrations are required, the effort required will be more substantial.

Some further questions that will need to be verified with the client prior to agreeing to implementation:

Will the information required to apply courier selection logic always be available as part of either the order or product data? For example, will weights always be part of the product definition if they are required to calculate a shipment weight?
If orders need to be shipped internationally does the product or order information contain the information required to create the necessary customs information?**

Locations

Although not a prerequisite of the OrderFlow environment most 3PLs prefer to dedicate specific areas within the warehouse to each client. Locations can be restricted to a single client organisation or can be shared.

Incoming locations within the Goods-Inward area and mobile locations used for picking are typically defined as shared. A typical configuration will ensure that most pick locations, bulk storage locations and return locations are client specific but may also define an area of shared space to allow for occasions when a dedicated areas becomes full.

Will the new client require new locations to be created (both physically and within OrderFlow) or can existing locations be assigned to them?
Does the client stock require locations if different sizes or types (e.g. shelves, bins and pallet spaces).

Paperwork

The primary consideration here is around the use of the despatch note that is included with each shipment to the end customer?

Will the new client require a custom despatch note, or are they happy to have their logo a standard despatch note or one used by an existing client?
Can the client provide an example of the required paperwork?
Does the despatch note documentation need to be multilanguage and display non-ASCII characters?
Are there any specific fonts that need to be installed to render or print the despatch notes?
Does the paperwork contain pricing details? Is OrderFlow required to calculate any of the pricing elements or is all the necessary information contained within the order data received from the sales channel?
Are there any variable elements that require logic to be embedded in the paperwork? For example, should new customers receive a 'welcome' note, or is there an integrated courier label?
Is product specific paperwork required (OrderFlow datasheets)?
Is a returns label and/or returns form required?
Is the paperwork channel-specific? If not, then please specify which existing paperwork should be used.

If a bespoke despatch note is required, the effort required will of course depend on the complexity of requirement, and how accurately this can be conveyed to the Realtime Despatch Customer Delivery team.

Note that some of our 3PL customers have developed an in house capability of producing their own despatch note. This is helped OrderFlow's ability to test the production of despatch notes.

Returns

Requirements relating to returns (if present at all) can very from the use of the basic out of the box features right through to more complex workflows involving integration with third party systems.

Do customer returns need to be supported?
Does the returns process differ from those already supported for other clients? If not, please specify if appropriate which existing process to use.
Does the returns process require any integration with client systems? These may, for example, create an RMA or pass back details of the returns that have been processed by OrderFlow.
What information does the client need to process customer refunds or trigger the despatch of replacement items?
Is the returns process channel-specific?

If any non-standard returns related requirements are present, these will need to be scoped as part of planning for the project implementation.

Client Access

OrderFlow can be optionally be configured to allow the client access to the system on a read-only basis.

Will the client require read-only access to OrderFlow?
Will the client need to be given the ability to make any specific targeted changes within the OrderFlow environment?

Note that specific client access requirements will need to be scoped if present, and will certainly need to additional configuration work (assuming development changes are not required).

Workflow and Business Rules

This concerns whether there are any custom workflow or business rules required for the client.

What Service Level Agreements have been made with the new client? For example, are there any cut-off times for same day despatch?
Will there be any client-specific picking required?
Are there any other specific workflow rules or processes required for the client? For example, is there a need to hold certain shipments for approval, etc.
Is there any need to ringfence stock by channel? For example, is there any need to separate stock that can be used for trade as opposed to consumer orders

Again, the implementation effort will depend on whether it is possible to reuse the rules already being applied for an existing client, or whether there are new rules to consider.

Reporting and Dashboards

OrderFlow can be configured to provide additional management information and operation capability through custom reports and dashboards.

Will the new client need access to any new reports or dasboards that are not already provided to existing clients?
Do these need to be defined as automated periodic reports or will the client run them manually from within OrderFlow?

Note that it is possible for 3PL technical staff to be trained in providing reports. A knowledge of SQL is required. Custom reports provided by Realtime Despatch can vary greatly in complexity and preparation time, from around an hour or two in simple cases through to days in more complex cases.

Billing

If you are using OrderFlow's billing module, then the following applies:

Will the billing metrics differ from those already supported for other clients?

If custom metrics are required, we will request further detail on the specific metrics that will be used for the client.

Purging and Anonymisation

Data that is received from clients may need to be anonymised and will eventually be purged from the system. The following questions apply here:

Has the data purging policy in place within the live OrderFlow environment been made clear to the client?
Does the client have any specific requirements for the anonymisation of their data?

Timing

The timing of a new client implementation may have to be carefully coordinated to avoid any business disruption for the client. The receipt of stock is obviously required for a new client to go live, but planning is required to ensure that the stock can be checked in without due delay after arrival. We request that you be able to answer the following questions prior to agreeing to the client takeon.

Where is the stock (physically), and when will it arrive in the warehouse?
Are you able to control and/or carefully coordinate the timing of the go-live?? This is to help ensure that it is properly supported by Realtime Despatch and can proceed smoothly?

Project Phases

As with an entirely new OrderFlow implementation, a 3PL client implementation can be divided into different stages. While the project is progressing, it is useful to be aware of these phases, and in particular, into what phase particular activities fall. In some cases, it may be necessary to have formal sign-off on the phases.

The different phases are shown in the diagram below, and described in the section that follows.

Phases

Planning

This involves identifying the scope of the project, and involves getting answers to the questions covered in the previous section.

Preparation

This involves preparing any solutions for complex configuration, paperwork, etc., and is done initially outside of the live OrderFlow instance.

Setup

Execute the steps to put the client live in 'test mode'. Normally the new client's organisation and channel on OrderFlow have a 'test' status. This allows for example for test orders to be received, processed, and subsequently cleared down.

Any other configuration changes required to support testing and subsequent go-live are applied at this point.

Testing

This involves executing processes end to end on the live system, but in test mode. Because of the test status of the new client's organisation and channel, processes can be tested end-to-end as many times as is necessary to ensure that you the 3PL are properly prepared for processing live orders.

The orders are typically sourced from the client's test system, as they may be updated as part of end-to-end testing.

At this point verification should take place on all interactions with the e-Commerce system, as well on courier integrations and the format and content of labels and despatch notes.

The mechanics for ensuring that the client's correct stock position can be reflected at the point of go live are also tested.

Go Live

Here the client's organisation and channel will be switched to live status following the input of the correct stock position. Connectivity is switched over to live systems, so that from this point onwards, live orders from real end users can be processed.

The Go Live phase is completed when all of the processes are fully operational, and have been verified against the requirements identified during the Planning Phase.

Responsibility Matrix

As you as a 3PL become more experienced in working with OrderFlow and bring new clients onto the system, you can expect responsibility for different parts of the process will increasingly move from Realtime Despatch to your own organisation. Encouraging this process will help with cost savings, in allowing you to make better use of your 'in house' resources, and avoid unnecessary Realtime Despatch consultancy charges.

The Responsibility Matrix table below shows how this responsibility may evolve from the earlier days with the first client implementations through to a situation of greater self-sufficiency and independence.

Responsibility Matrix

Project Phase	Initial Responsibility	Target Responsibility
Planning	Led by 3PL with assistance from Realtime Despatch	Fully managed by 3PL. Involvement from 3PL in planning for advanced tasks
Preparation	Performed by Realtime Despatch	Performed by 3PL
Setup	Performed by Realtime Despatch	Performed by 3PL
Testing	Performed by 3PL with some backup support from Realtime Despatch	Performed by 3PL, generally without support
Go Live	Coordinated with direct Realtime Despatch Involvement	Performed by 3PL, with Realtime Despatch available for support if necessary

Realtime Despatch is able to provide advanced technical training to help foster greater autonomy in carrying out customer implementations.

In the next section of the document, we go through the main technical tasks that are associated with each phase in the project implementation.

Onboarding Phased Rollout

With the knowledge gained in the previous section of the document, we are now in a position to describe, through the different phases, the steps involved in onboarding a new 3PL client.

Planning

From the perspective of Realtime Despatch, the Planning phase begins at the point when the you as the 3PL notify Realtime Despatch of your intention to bring on a new customer.

If you are expecting a significant involvement on the part of Realtime Despatch in the new client takeon, we encourage you to involve us as early as possible in the process, even if it is just to give you a rough indication of the effort required.

Note that this may take place at even at the presales stage, before the retailer is officially confirmed as a 3PL customer.

Once there is agreement to proceed in outline, the next step is to obtain a detailed understanding of the requirements for the project.

To assist this process, we may ask you to complete a 3PL Onboarding Requirements Questionnaire, particularly if there are multiple areas in which Realtime Despatch needs to be involved in the project implementation.

This step is led by the 3PL IT Manager, and involves the following:

understanding the requirements from the point of view of the client
deciding what involvement you would like from RTD in the different parts of the project
prepare the 3PL Onboarding Requirements Questionnaire for that customer
approve any work that Realtime Despatch needs to cover to carry out the implementation

Note that Realtime Despatch is not able to provide a fixed cost estimate of the overall work required for a client takeon. This is for two main reasons:

the effort required will depend greatly on the level of involvement, the technical skill and resource availability on the part of the 3PL
in general it is unlikely to be determine accurately and in fine detail the precise nature of the requirements

Where there are tasks that need to be undertaken that require significant effort by Realtime Despatch (see the Medium and Complex Requirements in Onboarding Planning section), Realtime Despatch will quote individually for the tasks through separate tickets on the Realtime Despatch Support Portal.

Once the work has approved and resourced, and the timings for the project have been defined and agreed, we're ready to move the Preparation phase.

Preparation

The Preparation phase includes is the work that is done largely off system (normally locally in the Realtime Despatch development environment), but may also include elements of configuration and testing performed on the 3PL's test instance.

By definition, no work carried out during this phase is done on the 3PL's live OrderFlow instance.

Common tasks undertaken as part of the preparation phase include:

identify the existing organisation that will be cloned when creating the new client's organisation
set up the integration with the client's test e-Commerce environment
set up the integration with the test environments for the courier integrations that the client will be users
preparation of any custom paperwork (e.g. despatch notes)
setup of any import data transformations for the incoming data
preparation of any custom reports required for the clients
if there are any different courier selection rules, write and unit test these
if separate batching is required, write and unit test the batch selection
verify any configuration required for custom workflow requirements. e.g. shipment state workflow to custom batching logic
plan for further configuration changes required during the Setup phase, if appropriate

The preparation tasks are generally technical in nature. The deliverables for each task will be in the form a demonstrable ability to meet stated requirements, and the necessary documentation required to delivery the necessary changes into the live environment.

Preparation Best Practices

We recommend that you maintain for each implementation you create an Onboarding Steps document, which refers to the documentation for each configuration change that needs to be applied during the Setup phase.

The recommended best practice is to try to verify as much up front as possible outside of the live environment, in order to ensure that changes are delivered in a coherent way into the live environment.

Setup

While Preparation takes place either outside of the customer environment or in the 3PL test environment, Setup is done on a test channel and/or organisation in the 3PL's live OrderFlow instance.

The key tasks include the following:

cloning the organisation that is being used as a template for the new client's organisation.
obtain and set up credentials and endpoints etc. for e-commerce and courier integrations. At this point you will still be connecting to test systems.
verifying and modifying 'copy sensitive' properties cloned from the source organisation. Here we want to ensure that the account numbers, URLs and other settings copied from the source organisation are not mistakenly left over in the new organisation
review all of the following: properties, scripts, import mappings, input files, schedule handlers, periodic reports, task definitions for the new organisation & channel(s). Check the scope of each of these.
create new locations, if necessary. This will be required if the stock is being stored in locations that have been reserved specifically for that organisation.
create or apply any custom reports.

You then want to carry through any changes that need to be pushed through from the preparation phase.

If you have created an Onboarding Steps document, then follow through this during the testing phase.

The kinds of tasks that will be involved here are:

copy across any customer paperwork into the new environment
create any new batch types specific to customer
copy across batch selection logic
copy across courier selection logic
copy across any import handler and rules that have been created

Setup Best Practices

In an ideal scenario, any complex rules that are defined above will have been tested during the Preparation phase before they are copied into the live environment.

There will still need to be further end to end testing at this point (covered in the next section). However, this testing should be as close as possible to a formality, picking up minor issues. It is best to avoid allowing the live environment to be treated as a 'playground' or 'sandbox'.

Testing

Once the Setup is complete, the Testing phase can commence. Testing involves a combination of isolated and end-to-end testing of all of the processes being introduced. The Testing phase takes place in the 3PL client's live OrderFlow instance, but using organisations and channels that are in 'test' mode. External integration (to e-Commerce and courier systems) is still using test endpoints.

Testing Scope

Unless there are significant new workflows being introduced as part of the new client implementation, most of the testing will be around the following:

the data flows to and from the e-Commerce integration
the data flows to and from the courier systems
the formatting and content of courier labels, despatch notes and other custom paperwork
the order processing workflow

A minimal set of end to end tests will involve the following:

verification of the mechanism for initially receiving and updating product information from the client's e-Commerce system
import of orders from from the client's e-Commerce system
matching of order to stock on OrderFlow (done automatically if process is turned on)
matching of order to courier selection
creation of batch or other picking task for order, and picking notes if report picking is used
picking of order
packing of order, including printing of courier label and despatch note
despatch of order, with notification of despatch to the client's e-Commerce system
update of stock position from OrderFlow to the client's e-Commerce system

Variations

You will also want to test variations. A variation in this case is an end to end test that involves different inputs, resulting in different outcomes and behaviour as orders flow through the system:

orders with bundles
orders to different destinations
orders to company and personal addresses
orders with different couriers and service levels
orders with different priorities
orders in different batches, or at least batches with different picking methods
workflows involving kitting, manifesting and collect from store

It is important to test all of the main variations to ensure that associated requirements have been properly met.

Verification

An important responsibility of the 3PL during the testing phase is to perform detailed verification. A cursory look at outputted documents, or an assumption that only some variations need to be tested - these won't do. The 'devil is in the detail' cliché is particularly relevant here, as any mistake that needs to be corrected after Go Live can be potentially costly and disruptive.

Some of the important questions to answer as part of this verification include:

Are all of the expected address fields present on imported orders? Are the in the correct place, and are they labelled correctly on the GUI.
Are all of the expected contact fields present, including company and contact names?
Has pricing information been correctly imported? Consider order, shipping and line pricing values.
Are address and contact information being transmitted as expected to the courier system? If possible, log into courier systems and check.
Are labels being printed correctly, and are all contact/address fields showing correctly on labels?
Is the paperwork correct? Check for layout, correct display of addresses, contact information and pricing if appropriate. Check for typos and formatting errors.
Are despatch notifications working correctly? Are they being received by e-Commerce system as expected?
Are despatch references updated correctly, and sent to e-Commerce system in despatch notification?
Are stock levels being updated as expected? Do spot checks in e-Commerce system against levels.
Is the product catalogue is accurate complete?
Are enhanced product definitions are set up, with valid barcodes, weights, location restrictions, etc.?

Preparing for Go Live

Part of the Testing Phase is to prepare for Go Live, to ensure that the system is ready to handle live orders from the day that these need to be shipped.

Important things to consider include:

Are you are able to identify orders that are still pending versus ones that have been process separately on other system(s)?
Are you ready to import an accurate stock position at the appropriate moment?
Have you agreed with Realtime Despatch's Customer Delivery team on the date for the Go Live?

The exact mechanism for getting the correct stock position on the system can differ according to the Go Live scenario. For example, one option is to make the client's organisation live first, and use the stock checking feature on OrderFlow to ensure that stock levels are correct. An alternative approach is to do a full stock position import just before go live through a single stock level import in a standard XLS or CSV format.

Whichever of these approaches you intend to use, you should be ready to apply one of these at the point of Go Live.

Testing Best Practices

Note that if the earlier steps have been prepared carefully according to best practice, then the Testing phase should only raise minor issues.

Note that it is important to use end-to-end testing, rather than just isolated testing of parts of the process.

We recommend that during Testing you set up a Live Switchover Steps document, which can be followed at the point where you transition to live. This helps to ensure that the live switchover takes place as smoothly as possible.

Go-Live

Go Live

The Go Live step is where you transition to processing live orders on the live system. If Realtime Despatch is significantly involved in the new client takeon, then this date will have been discussed and agreed beforehand with Realtime Despatch.

Go Live Steps

Steps involved as follows:

Do pre-flight checks to ensure that products definitions are correctly synchronised.
Clear down any existing tests orders on the system. This can be done using the OrderFlow 'Channel Cleardown' feature.
Import an updated stock position if necessary.
Switch over to using live endpoints for e-Commerce and courier integrations.
Set the status of the organisation and channel to live (note that this step may be split into two as described in the next section)
Ensure that schedules (and periodic reports, if required) are active for the new client's organisation and channel.
Ideally import selected orders and process just these, to sanity check the basic configuration.
Implement any remaining live switchover steps, preferably following instructions prepared in a Live Switchover Steps document.

From this point onwards, you are in full live operational mode.

Two Stage Go Live

Note that it is possible to transition to live in a two stage procedure, with organisation and stock control elements switching to live for a brief period while orders are still being processed in test mode. This can help to derisk the transition to live and give you more time to ensure that stock levels are accurate and inbound processes are working, before starting to process orders:

The stages involved here are:

Organisation Go Live: here the client's organisation is live, but the channel is still in test mode. Note that it is not possible to do stock or product cleardown once the organisation is live. However, you are able to continue to process (and clear down) test orders.
Channel Go Live: both the organisation and channel are in the live state. From this point onwards you cannot clear down stock, products or orders.

Once you are live, the final part of the process to perform a review, and to validate that the implementation is working as expected based on requirements. Ensure not to skip this step to avoid any unpleasant surprises.

Go Live Best Practices

We recommend that you plan to go live no later in the week than Wednesday. If support issues are raised, these can be addressed during the week rather than be deferred to the weekend, when resource availability is limited.

After Go Live

In the days and weeks following Go Live of a new client, it is important to verify that all the processes are functioning as expected. These can include:

Ensuring that no shipments are getting 'stuck' in the workflow
Ensuring that any courier 'end of day' processes correctly process the new client's shipments
Ensuring that periodic reports are generating and exporting the required reports
Ensuring that the client's billing entries are being correctly generated

Any issues that are discovered during this time should be reported to Realtime Despatch and will be addressed through the normal support process.

Integration

This covers some of the concepts that are relevant for 3PLs.

Basic forms of integrations

e-Commerce Integrations - what these are in a nutshell Courier Integrations - what these are in a nutshell

e-Commerce Integrations

Shopify Magento

Check with us on a particular integration. Magento, descriptions on module, 6x6 module.

Ensure that the mapping of data is in line with requirements of carrier.

Magento Integration

Describe the options available.

Courier Integrations

Own account vs client account integration. Carrier choice for particular customers.

Courier selection.

Paperwork

This covers some of the concepts that are relevant for 3PLs.

Best practice recommendations. Standardise on the paperwork that you output.

Links to the documentation.

Ability to reuse standard documentation, only changing logos where necessary. Link to HowTo.

OrderFlow is capable of supporting arbitrary paperwork, but setup can be time consuming.

Reporting

Custom Reports

Remotely Accessible Reports

Periodic Reports

End of day reports ... periodic reports.

Can send formatted emails, attachments.

Send files to FTP servers.

Also, possible for clients to run their own reports.

Set up reports for role based access.

Read-only Report Access

Read only views.

Billing

OrderFlow has a billing module which can be used to record billing records which in turn can be used to invoice clients.

You can set your own metrics.

Client Access

In this chapter we talk about client access.

You will want to give client access to your customers.

You will need to ensure that they are read only enabled.

Need to ensure that they are given the correct scope and site access.

Explain what the user will be able to see.

Reference to section on reporting.

Write functions that are read only enabled:

order submission
PO submission
data import