Skip to content
  • There are no suggestions because the search field is empty.

Configure the Customer Profile for Forecasting

Setting up alternative names, weeks to retail, and revenue sources in customer profiles in the Manage>Customers section

 

Summary

Three fields in the Manage > Customers customer profile directly control how the Forecast module sources and interprets actualized data for each customer: Alternative NamesWeeks to Retail, and Forecast Revenue Source. Together, these fields ensure Vividly can match uploaded data to the right customer, convert consumption timing to shipment timing, and accurately populate velocity and store count actuals in the forecast. Configuring these fields correctly is essential for forecast accuracy, particularly for customers whose data comes from syndicated sources (SPINS, Circana, Nielsen/IRI) or ERP systems.

When to use this

  • When setting up a new customer that will be used in the Forecast module.
  • When a revenue upload fails with a "customer not found" error.
  • When the forecast is not accurately reflecting actualized data for a customer.
  • When switching a customer's data source (e.g., from ERP/accounting to syndicated data).
  • When distributor or indirect-customer forecast timing appears to be off by several weeks.
  • When onboarding and connecting POS or ERP data to customer profiles.

Steps

Accessing the Customer Profile

  1. From the left navigation bar, click "Manage" > "Customers".
  2. In the customer list, locate the customer you want to configure. Use the "Search Bar" to filter by name if needed.
  3. Click on the customer name or row to open their Customer Profile.

Setting Alternative Names

Alternative Names let Vividly match incoming data uploads (POS, ERP, syndicated) to the correct customer when the name in the data file differs from the Vividly customer name. For example, your SPINS export might label a geography as "PUBLIX CORP - RMA" while your customer is simply named "Publix" in Vividly. Without an alternative name, the upload will fail.

  1. Inside the customer profile, scroll down to the "Alternative Names" section.
  2. Enter the name or customer code exactly as it appears in your data source file.
    • Example (POS/Syndicated): If your SPINS geography is listed as "PUBLIX CORP - RMA", enter that exact string.
    • Example (ERP): If your ERP uses a numeric customer code such as "45821", enter that code here.
  3. Assign a tag to the alternative name to stay organized:
    • Syndicated Data — for names from SPINS, Circana, Nielsen, or IRI.
    • Accounting Source — for names or codes from your ERP/accounting system.
    • Deduction Matching — for names used in deduction backup files.
  4. Click "Save Changes".

Tip: You can add as many alternative names as needed for a single customer. A customer often has different identifiers across SPINS, Circana, and your ERP simultaneously.

Setting Weeks to Retail

Weeks to Retail is an integer value that tells Vividly how many weeks typically pass between when product leaves your warehouse (shipment) and when it appears in retail/POS data (consumption). This field is used by the Forecast module only.

This field is especially important for indirect customers (those receiving product through a distributor). It allows Vividly to aggregate retailer-level POS/consumption data into an accurate distributor-level shipment forecast by shifting the timing back by the appropriate number of weeks. It also drives the All Other Bucket calculation and appears in the First Receivers tab of the Forecast Export.

Example: If a product was consumed in the week ending March 1st and Weeks to Retail is set to 4, Vividly will treat the corresponding shipment as occurring during the week ending February 1st — shifting the consumption data back by 4 weeks to reflect when it needed to ship.

  1. In the customer profile, scroll to the "General Info" section.
  2. Locate the "Weeks to Retail" field.
  3. Enter an integer representing the typical shipment-to-shelf lag for this customer:
    • Typical range: 2 to 4 weeks for most retail accounts.
    • Default recommendation: Use 4 if you are unsure of the exact value.
    • Example: Entering 4 for Whole Foods means a retailer forecast week is shifted 4 weeks earlier in the distributor/first-receiver forecast.
  4. Click "Save Changes".
Note: Weeks to Retail is a Forecast-only field. It does not affect promotions, deductions, or revenue uploads. If this field is left at 0 or blank, no time shift will be applied, which can make the distributor/first-receiver forecast inaccurate for indirect customers.

You should see the updated integer value reflected in the field.

If the distributor or first-receiver forecast timing is off, return to this field and adjust the value to better reflect the actual lag for this customer's supply chain.

Selecting the Forecast Revenue Source

Forecast Revenue Source determines which uploaded data source Vividly uses to populate actualized weeks in the forecast for this customer — specifically, the velocity and store count inputs that drive the forecast calculation. When you are in the Forecast module, the actualized weeks pull from the data uploaded under the matching source in Business > Revenue.

Example: If a customer is set to SPINS as the Forecast Revenue Source, Vividly will use the weekly velocity and store count data from your SPINS uploads to actualize past weeks and set the baseline for future forecast weeks.

  1. In the customer profile's "General Info" section, locate the "Forecast Revenue Source" field.
  2. Select the one data source that best represents this customer's actuals:
    • Use SPINSCircanaNielsen, or IRI if you upload syndicated POS data for this customer.
    • Use Accounting Source if you use ERP/accounting data to actualize this customer's forecast.
    • The correct selection is the source you actively upload to Business > Revenue for this customer.
  3. Click "Save Changes".
Warning: Select only ONE source. If multiple sources that have data uploaded are selected, Vividly will add all volumes together in the forecast table, resulting in double or triple counting. This inflates your forecast and size-of-business figures. For best practice, select one and only one Forecast Revenue Source per customer.
 
Note: There is a system-level distinction between Accounting Sources and Non-Accounting Sources. You may select more than one source of the same type (e.g., two Accounting Sources), but you cannot select one Accounting Source and one Non-Accounting Source simultaneously. In either case, selecting multiple sources with uploaded data risks double-counting and is not recommended. 
 
You should see the selected source reflected in the field. The forecast will use data from this source to actualize past weeks on the next data refresh. 
 
If you are direct with a customer but experience large order fluctuations (e.g., resets or bulk orders), consider using a syndicated source (SPINS, Circana, Nielsen) instead of Accounting Source. Syndicated data provides a more consistent view of true consumer demand and more stable store counts for forecasting.

 

Expected Result

After correctly configuring all three fields:

  • Alternative Names: Data uploads that reference the alternative name will automatically map to the correct customer. Revenue upload errors for "customer not found" will be resolved.
  • Weeks to Retail: The Forecast Export's First Receivers tab will correctly shift retailer consumption data back by the configured number of weeks to reflect accurate distributor/first-receiver shipment timing. The All Other Bucket calculation will also use this value.
  • Forecast Revenue Source: Actualized weeks in the Forecast module will populate with the correct velocity and store count data from the selected source. Future forecast weeks will be calculated based on these accurate actuals.

Troubleshooting

Problem: Revenue upload fails with "Vividly was unable to find the highlighted customers."

  • Likely cause: The customer name in the data file does not match any customer name or alternative name in Vividly.

  • Fix: Open the customer profile in Manage > Customers, scroll to "Alternative Names", and add the exact name or code from the data file. Re-upload the file after saving.

Problem: Forecast shows unexpectedly high or doubled volume for a customer.

  • Likely cause: More than one Forecast Revenue Source is selected and data has been uploaded for each selected source. Vividly totals all volumes, causing double or triple counting.

  • Fix: Open the customer profile, review the "Forecast Revenue Source" field, and de-select all but the one source that corresponds to your uploaded data. Save changes.

Problem: Distributor or first-receiver forecast is offset by several weeks compared to expected shipment timing.

  • Likely cause: The Weeks to Retail value is incorrect, too high, too low, or set to 0.

  • Fix: Open the customer profile and update "Weeks to Retail" to the correct number of weeks. Typical values are 2–4 weeks; use 4 as a default if uncertain. Save changes and review the First Receivers tab of the Forecast Export to confirm timing.

Problem: Syndicated data uploads successfully but the forecast does not actualize for a customer.

  • Likely cause: Forecast Revenue Source is not set, or is set to the wrong source type (e.g., Accounting Source when data was uploaded as SPINS).

  • Fix: Open the customer profile and confirm the "Forecast Revenue Source" matches the type of data uploaded for this customer in Business > Revenue. Save changes.

Problem: Alternative name was added but the Deduction Matching logic is not working as expected in the DRM module.

  • Likely cause: The alternative name tag is set to "Syndicated Data" or "Accounting Source" instead of "Deduction Matching." Only the Deduction Matching tag drives system logic in DRM.

  • Fix: Edit the alternative name in the customer profile and confirm the Deduction Matching tag is assigned. Save changes and re-run the deduction scan.

Frequently Asked Questions (FAQs)

Q: Can I add multiple alternative names for the same customer?

A: Yes. You can add as many alternative names as needed. This is common when a single customer appears under different identifiers across SPINS, Circana, and your ERP system simultaneously.

Q: What happens if I don't set a Weeks to Retail value?

A: If the field is left at 0 or blank, no time shift will be applied. This can result in inaccurate first-receiver and distributor forecast timing for indirect customers. Set a value even if you are uncertain — the recommended default is 4 weeks.

Q: Why would I use syndicated data (SPINS/Circana) as my Forecast Revenue Source for a direct customer?

A: Even if you ship directly to a retailer, syndicated data provides more stable store counts and base velocity inputs. Direct order data can fluctuate significantly due to large orders for resets or promotions, which distorts the forecast baseline. Syndicated data reflects true consumer demand and provides more consistent store count actuals.

Q: The Preset Customer feature auto-populated some alternative names. Do I still need to add more?

A: Possibly. The "Associate Preset Customer" feature provides a starting set of common alternative names from Vividly's internal library (400+ customers). However, your specific POS or ERP export files may use unique codes or names not in the library. Review each upload for "customer not found" errors and add any additional alternative names as needed.