Project Task Coordination for NetSuite Driven Sales Organizations

This article is relevant if you use NetSuite in a sales and delivery model that demands a high degree of coordination between multiple parties, suppliers and actors.

Background

One of our clients is in the commercial fixtures business. They are specialist in the configuration of premium fixtures which demand planning efforts to supply a unique bundle of commercial quality goods. The nature of the planning work requires multiple back-and-forth conversations with many actors to confirm all order elements meet specifications for fit, price and delivery schedule.

This business model is not uncommon for distribution and job cost manufacturing organizations. For our client, firmly in the distribution industry, the work begins with an NetSuite Estimate record. The Estimate is the first place that the Sales Consultant listens to customer requests and plans out the configuration. The configuration effort takes industry knowledge because it demands gathering information about specialized products and parts from many different suppliers. The general sales process is considered a project because it often takes extended time and multiple efforts to ultimately deliver the goods.

Consequently, the sales and delivery project effort can be characterized as a long task list that demands status and follow up with multiple actors. Before my client worked with our firm, they organized around three NetSuite native records:

  1. Estimate: The Sales Consultant would listen to customers concerns and work with other team members to source the products and prices from various suppliers. The customer would have to review the Estimate in detail and sign off that it indeed represented the desired configuration. Sometimes, more than one Estimate would be required because the job was to be delivered in multiple phases.
  2. Sales Order: When the customer approved the project to move forward, the Estimate would then be transformed into one or more Sales Orders.  To handle the volume, the responsibilities move from the Sales Consultant to a Project Manager. NetSuite naturally copies line items from the Estimate to the Sales Order.  This NetSuite fundamental copy function, powerful in many respects, has inherit limitations in this business model (discussed below).
  3. Purchase Order: Our client keeps few inventory in stock due to the special nature of each project. Thus, they use NetSuite drop ship / special orders to drive purchase functions. Here again, NetSuite uses a copy function to transform Sales Order lines to NetSuite Purchase Orders. The Project Manager works with a Warehouse and Delivery Specialist to ensure the entire order is delivered to the customer according to specification.

NetSuite Transaction Lines as Project Tasks

Each line on the transactions represent a “ToDo” list. The nature of the work demands phone calls and emails to customers, suppliers and sometimes delivery people to ask “where is my product?”. ¬†My client extended NetSuite by adding custom transaction columns to hold extra notes, status fields and follow up attributes on the transaction line level. ¬†It is understandable my client extended NetSuite by adding transaction columns in this manner. However, the Sale Consultants, Project Manager and Warehouse Delivery Specialist would have a demanding time “staying on top of it all”.

The team’s efforts were thwarted by two key software architecture constructs:

  1. Line Edits: transaction lines can not be edited outside of their transactional parent (header). For example, you can’t modify a purchase order line without putting the purchase order into an edit function.
  2. Line Copies: lines are copied as they are transformed from one record type to another. Thus the line status on the Sales Order is not the same line on the Purchase Order — although the good being sought is exactly the same. Modifying the custom status fields on the purchase order line does not modify the custom status fields on the sales order.

Solving NetSuite Project Task Coordination

The key to solving this challenge is to understand NetSuite’s transactional engine and to couple it with two key architectural elements:

  1. Project Record: A custom record that can be extended in any desired fashion to group and organize transactions and tasks.
  2. Task Coordinator: Each good represents a task no matter where it is in the sales / delivery life cycle. Thus, copies of tasks are to be avoided — we need a solid pointer we can trust.

The NetSuite Project Record Challenge

The first challenge relates to a NetSuite Project in a Sales Model. NetSuite offers two types of Project records. One structure is called a Job, is available to all NetSuite accounts, and it is effectively a sub entity of the customer. The challenge is that the reporting for customers across projects is tricky. NetSuite offers another Project record when you purchase the Service Resource Planning¬†(SRP) add-on module. This Project model runs independent of Jobs but is really designed for companies that are tracking and billing timesheet entry (for example, we use this module to run our systems integration practice). These two project concepts don’t work well for my customer.

The next major challenge for my client is when to constitute a project. Some of the orders are small and thus can be delivered quickly. A basic sales order gets the job done and the concept of the project seems heavy. Yet, larger efforts should be a project. Like many things in sales processes, the consistency in data gathering practices is difficult and thus my client’s attempts to constitute projects between the team members was incomplete and unsatisfactory.

BackFill Custom Project Record

The key to solving this for the client is to use a new custom project record so that we could gain complete control over the use of the record. More importantly, the real innovation is a backfill concept to automatically constitute project records on behalf of the team without their consideration (meaning, they don’t have to think about it). ¬†See the following automation logic:

  1. On Estimate: Take the title of the Estimate and automatically create a project record when the Estimate is saved. The name of the project will be called “customer: title”. ¬†Of course, we can configure it to name anyway that is meaningful.
  2. Auto Create Opportunities: in our client model, since they always start with Estimates (which may be considered backwards from the typical process flow), they wanted to use Opportunities when the value of the Estimate was of greater amounts. The Opportunities would be used to help drive forecasting. Thus, auto create a linked Opportunity against the Estimate and project when the Estimate was over a parameterized amount.
  3. On Sales Order: If the Sales Order was created from the Estimate, the project would already be associated. But just like the Estimate, if no project was created, one would be created automatically. However, for those large projects with multiple sales orders, it would be easy to select an existing project thus linking the Sales Order to other related Sales Orders.

Task Coordination Record and BackFill

The next major innovation is to create a task coordination system that would allow all the actors to focus on each¬†good at hand. Tasks would automatically be created as soon as products would be identified in transactions. In my client’s process, this would be at the time of the Estimate creation (but not always). The task now would hold all the data about the status, notes, and delivery times.

Task Coordination Reference During Transaction Transform

As outlined above, when the transactions would naturally transform, the references to the task coordination would copy — such as the Sales Order line to the Purchase Order line. Yet, the copy is just a reference to the same Task Coordination record. Thus the entire team could focus on single reference of the right task no matter where it was in the sales and delivery process. ¬†Click the¬†image above for a better conceptual understanding.

Task Coordination Parent and Children

The pattern of a header and related line is fundamental in transaction systems.  So too with the Task Coordinator records. The concept supports a parent task, linked with the original transaction, and it supports line tasks, represented by the item lines on the NetSuite transactions. This allows Opportunities to automatically calculate overall status based on the summary of children status. Presentation can be organized into groups and sets. Further, with the linkage to our custom Project, we now can bring the entire set of coordination into a central focus.

Leverage NetSuite Inline Edit Task Coordination

As my clients and staff know by working with me, I love spreadsheets for project management. The power of list management with quick updates and filtering can help organize action to more easily stay on top of projects. For those interested, see the innovation I built for Google Sheets in this How to: Google Sheet Script to Edit Cell Contents.  But of course, I am not the only one that wants to manage a list in this way.

Given we are using a custom task coordination record, we can leverage NetSuite inline list edit functions to drive a filtered spreadsheet experience making it very fast to stay on top of edits. Because the inline edits can trigger logic, we can easily drive subsequent action and notification based on the change of task status. This is near impossible (a subject for a future article) to do with NetSuite native lines.

Watch NetSuite Project Tasks Coordinator Video (8:44)

To help illustrate this capacity, I created a video (duration 8:44) of the work we did in our development environment. We produced the effort to be an extendable framework designed to be fitted the specifics of our clients’ processing model. ¬†Like all the software we build, it is license free for our client’s use.

Innovate on the NetSuite Platform

The Project Task Coordinator is a framework that can be used by any organization wishing to get in front of their NetSuite driven project efforts. More importantly, the invention is an illustration of how we synthesize our client’s concerns against our deep NetSuite platform understanding to drive creative solutions. If you have a similar concern, or sense that the right thinking can¬†change your situation, let’s have a conversation.

Be Sociable, Share!

Marty Zigman

Holding all three official certifications, Marty is Southern California's NetSuite expert and leads a team of senior professionals at Prolecto Resources, Inc. He is a former Deloitte & Touche CPA and has held CTO roles. For over 25 years, Marty has produced leadership in ERP, CRM and eCommerce business systems. Contact Marty to setup a conversation.

More Posts - Website - Twitter - Facebook - LinkedIn - Google Plus - YouTube

| Tags: , , | Category: CRM, ERP, Management, NetSuite | 2 Comments

2 Comments

  1. Patrick
    Posted September 20, 2017 at 5:12 pm | Permalink

    Hi Marty

    I watched the latest video in youtube which about process item fulfilment via Google Sheet.

    Our company is looking this integration which we want is :
    Step 1. Get Open Sales Order into Google Sheet
    Step 2. Worker based on the Sales Order lists to preform pick and pack in Google Sheet [auto updated into NetSuite]

    In your video, the item fulfilment transaction did not require Bin#. So is it possible with Bin# as well ?

    Also we want to perform Bin Transfer form in Google Sheet as well.

    Pls advise how much for above works. Many Thanks

    Regards
    PL

  2. Posted September 24, 2017 at 9:07 am | Permalink

    Hi Patrick,

    All of your requests are possible through the enhancements of the restlets and Google Sheet functions. That is the essence of this framework. I recommend sending me a note and we can start a conversation.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>