Vendor Management Workspace - States

[Tommaso2]

Hi all,

It is possible to manually define the state of the vendor in the company table (e.g. Selected, Terminated and so on).

When a Vendor Manager uses the VMW, the state of the Vendor is Operational?

The other states have to be manually updated because additional integrations are needed?

For example Supplier Lifecycle Management for Onboarding, Contract Management etc?

Thank you,

Tommaso

[danmjunqueira · Accepted solution]

Yes, your understanding is correct. Here's a clear breakdown regarding Vendor Management Workspace (VMW) and the vendor state handling:

1. Default State Behavior in VMW
When using Vendor Management Workspace, vendors (companies) are stored in the core_company table.

By default, when a Vendor Manager creates or edits a vendor in VMW, the State is typically set to "Operational".

This is the default out-of-box behavior unless customized.

2. Manually Updating Vendor States
Other states such as "Onboarding", "Terminated", "Selected", or "Inactive" do not change automatically unless:

You implement custom workflows

You integrate with other applications (like Supplier Lifecycle Management, Contract Management, or Procurement)

So yes, manual updates or custom automation are needed to move the vendor between lifecycle stages beyond "Operational".

3. Integrations Required for Full Lifecycle Automation
To automate vendor state transitions, you typically need:

Supplier Lifecycle Management (SLM): for structured onboarding, risk assessment, scoring, etc.

Contract Management: to manage contract status and trigger vendor changes based on expiration or renewal.

Procurement or Sourcing integrations: to influence vendor usage or status based on activity or performance.

Without these integrations, the system has no context to change vendor state beyond what the user manually updates.

Summary:
Yes, VMW sets vendor state to "Operational" by default.

Yes, other states must be manually managed unless additional modules (like SLM or Contract Management) are integrated.

Custom flows or scripts can be built to automate transitions if needed.

[danmjunqueira · Accepted solution]

Here are the confirmations to your questions:

1. Is Vendor Score the average of Vendor Score KPIs?
Yes, the Vendor Score shown in Vendor Management Workspace (VMW) is typically calculated as the average of all active KPI scores associated with the vendor. This includes metrics like quality, cost, delivery, compliance, and other performance indicators configured in your environment.

The final score may also be weighted if you are using weighted KPIs. Check the KPI definitions to confirm if any weights are applied.

2. Where are survey results used? Are they reflected in the "Vendor Satisfaction by vendor" chart?
Yes, the results from vendor surveys (sent to stakeholders for feedback) are typically processed and stored in Vendor Satisfaction scores, which contribute to the "Vendor Satisfaction by Vendor" chart on the VMW homepage.

That chart is usually populated from:

Survey results linked to the vendor

Calculated satisfaction metrics (averages of survey question responses)

Data stored in tables like sn_vdr_score_vendor_satisfaction

If you're not seeing survey results reflected in the chart, check:

Whether the surveys are linked to the correct vendor records

If the survey questions are mapped to satisfaction KPIs

If any scheduled jobs or score calculation jobs are pending or failing

[danmjunqueira · Accepted solution]

You're welcome, and these are great questions. Below I tried to bring some clear answers with real examples to help clarify each point.

1. SLAs in Vendor Management Workspace (VMW)
You’re right that SLAs are not just tied to incidents. In VMW, SLAs can be linked to broader vendor performance metrics, not limited to ITSM records.

a) Service-level agreements tied to vendor contracts
Example:
A vendor agrees in the contract to provide a system availability of 99.9% uptime per month.

You can create a Contract record in VMW.

Link an SLA Definition that checks system uptime metrics.

If uptime falls below 99.9%, the SLA is breached, and it’s visible in the vendor performance dashboard.

b) Service delivery metrics
Example:
A vendor must deliver laptops within 7 business days after request approval.

Create an SLA that starts when a catalog item (request for hardware) is submitted and ends when the delivery task is marked complete.

Track actual delivery time vs. commitment.

Report on SLA breaches per vendor or service category.

c) Contractual obligations
Example:
A vendor is contractually required to provide quarterly security audit reports.

Create a custom task or milestone with a schedule (e.g., every 3 months).

Attach an SLA that tracks completion of that obligation.

If the vendor fails to upload the report by the due date, SLA is breached.

This helps go beyond just incidents and measure non-incident-based performance commitments.

2. How vendor costs are managed
You are correct that “Total Cost of Contracts” is the primary visible field in the Details tab. However:

This field aggregates the cost values from all contracts linked to the vendor.

Costs per contract can include:

Total contract value

Annual cost

Recurring cost

Cost type (e.g., fixed, per unit)

If needed, you can:

Extend the contract table to add more detailed cost breakdowns

Use Performance Analytics to track vendor cost trends

Link contract costs to project spend or resource allocation for more insights

3. Who receives vendor surveys (best practice)?
Best practice is to send vendor surveys to internal stakeholders who interact directly with the vendor, including:

Service Owners

Vendor Managers

Business Relationship Managers

Key users in departments using the service/product

The goal is to gather qualitative input on vendor performance (e.g., satisfaction, responsiveness, issue resolution). Avoid sending it to general users unless they are meaningful consumers of the service.

4. "To open tickets to vendors" — how does it work?
There is no out-of-box feature in VMW to open a ticket directly to a vendor like you do in ITSM. However, there are ways to approach this:

a) Standard Incident Process (mapped to vendor)
Create an incident or problem record

Use a vendor assignment group

Notify or integrate with the vendor via email or API

b) Custom Case Management
You can create a custom “Vendor Case” table, or use existing Case Management features to:

Log issues against vendors

Track resolution

Link to contracts or SLAs

c) Vendor Risk Management plugin
If you have Vendor Risk Management (VRM) enabled:

You can open risk issues or assessments linked to vendors

These can function like tickets, with workflows and remediation tracking

VRM also provides a structured way to manage third-party risks, assessments, and exceptions — which sometimes replace traditional “tickets”.

In resume
SLAs Can track delivery, compliance, and contractual obligations, not just incidents;
Vendor Costs Total cost is aggregated from contracts; for more detail, extend or report;
Surveys Should go to internal users directly involved with the vendor;
Tickets to Vendors No direct OOTB vendor ticketing, but possible via incidents, cases, or VRM;

[danmjunqueira · Accepted solution]

Yes, your understanding is correct. Here's a clear breakdown regarding Vendor Management Workspace (VMW) and the vendor state handling:

1. Default State Behavior in VMW
When using Vendor Management Workspace, vendors (companies) are stored in the core_company table.

By default, when a Vendor Manager creates or edits a vendor in VMW, the State is typically set to "Operational".

This is the default out-of-box behavior unless customized.

2. Manually Updating Vendor States
Other states such as "Onboarding", "Terminated", "Selected", or "Inactive" do not change automatically unless:

You implement custom workflows

You integrate with other applications (like Supplier Lifecycle Management, Contract Management, or Procurement)

So yes, manual updates or custom automation are needed to move the vendor between lifecycle stages beyond "Operational".

3. Integrations Required for Full Lifecycle Automation
To automate vendor state transitions, you typically need:

Supplier Lifecycle Management (SLM): for structured onboarding, risk assessment, scoring, etc.

Contract Management: to manage contract status and trigger vendor changes based on expiration or renewal.

Procurement or Sourcing integrations: to influence vendor usage or status based on activity or performance.

Without these integrations, the system has no context to change vendor state beyond what the user manually updates.

Summary:
Yes, VMW sets vendor state to "Operational" by default.

Yes, other states must be manually managed unless additional modules (like SLM or Contract Management) are integrated.

Custom flows or scripts can be built to automate transitions if needed.

[Tommaso2]

Hi! Thanks for your reply.

Additional confirmations:

- Vendor Score is the average of Vendor Score KPIs?

- Once the surveys are sent to the stakeholders to get feedback on vendors, where and how the result of the questions is used? In "Vendor Satisfaction by vendor" chart in the VMW homepage? (If not, how that chart is populated?)

Many thanks!
Tommaso

[danmjunqueira · Accepted solution]

Here are the confirmations to your questions:

1. Is Vendor Score the average of Vendor Score KPIs?
Yes, the Vendor Score shown in Vendor Management Workspace (VMW) is typically calculated as the average of all active KPI scores associated with the vendor. This includes metrics like quality, cost, delivery, compliance, and other performance indicators configured in your environment.

The final score may also be weighted if you are using weighted KPIs. Check the KPI definitions to confirm if any weights are applied.

2. Where are survey results used? Are they reflected in the "Vendor Satisfaction by vendor" chart?
Yes, the results from vendor surveys (sent to stakeholders for feedback) are typically processed and stored in Vendor Satisfaction scores, which contribute to the "Vendor Satisfaction by Vendor" chart on the VMW homepage.

That chart is usually populated from:

Survey results linked to the vendor

Calculated satisfaction metrics (averages of survey question responses)

Data stored in tables like sn_vdr_score_vendor_satisfaction

If you're not seeing survey results reflected in the chart, check:

Whether the surveys are linked to the correct vendor records

If the survey questions are mapped to satisfaction KPIs

If any scheduled jobs or score calculation jobs are pending or failing

[Tommaso2]

Hi! Thank you for your precious support.

Other doubts:

- I received this reply about SLAs in VMW, can you please provide a real concrete example for each bullet point for clarification:

SLAs in VMW are not limited to incidents. The platform supports comprehensive SLA tracking that includes:

• Service-level agreements tied to vendor contracts - monitoring vendor performance against agreed-upon service commitments

• Service delivery metrics - tracking delivery times, service quality, and compliance rates

• Contractual obligations - ensuring vendors meet their commitual commitments beyond just incident response

- How vendor costs are managed? I only see "Total Cost of Contracts" field in Details tab

- Who are usually the stakeholders that receive the surveys (best practice)?

- "To open tickets to Vendors" means via standard incident or it exists a ootb functionality to open tickets from the VMW? Maybe with Risk plugin?

Many thanks!

Tommaso