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 Names, Weeks 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
- From the left navigation bar, click
"Manage">"Customers". - In the customer list, locate the customer you want to configure. Use the
"Search Bar"to filter by name if needed. - 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.
- Inside the customer profile, scroll down to the
"Alternative Names"section. - 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.
- Example (POS/Syndicated): If your SPINS geography is listed as
- 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.
- 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.
- In the customer profile, scroll to the
"General Info"section. - Locate the
"Weeks to Retail"field. - 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
4if you are unsure of the exact value. - Example: Entering
4for Whole Foods means a retailer forecast week is shifted 4 weeks earlier in the distributor/first-receiver forecast.
- Click
"Save Changes".
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.
- In the customer profile's
"General Info"section, locate the"Forecast Revenue Source"field. - Select the one data source that best represents this customer's actuals:
- Use SPINS, Circana, Nielsen, 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.
- Click
"Save Changes".
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)
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.
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.
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.
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.