Optimization Engine Logic

4.1 How recommendations are generated 

Qhub recommendations are generated using a structured decision flow: 

Collect and normalize data 

The platform collects licensing, configuration, and usage signals from your Microsoft environment and normalizes them into a consistent internal model (users, SKUs, service usage, assignments, and activities). 

Classify users and licenses 

• Users and objects are classified into categories such as: 
  • Active vs. inactive (based on sign-in and/or workload activity) 
  • Assigned vs. unassigned licenses 
  • Over-licensed vs. right-sized (based on observed feature/workload usage) 

Apply rule sets and heuristics 

• The Optimization Engine applies a set of expert-defined rules and thresholds derived from Microsoft licensing best practices and typical enterprise patterns. Examples: 
  • Identify licenses assigned to users who have been inactive beyond a threshold. 
  • Identify expensive license plans where observed usage does not justify the plan. 
  • Identify unassigned (unused) prepaid licenses that can often be reduced at the next contract opportunity. 

Generate “candidate actions” 

• For each user/license/SKU, the engine creates candidate actions such as: 
  • Remove license 
  • Downgrade license 
  • Reassign license 
  • Review / validate (when confidence is lower or dependencies are likely) 

Estimate impact (cost + risk) 

• Each candidate action is enriched with: 
  • Estimated annual savings (based on price source and license quantities) 
  • A confidence level / risk indicator 
  • Evidence signals (e.g., inactivity duration, absence of workload usage) 

Prioritize recommendations 

Recommendations are ordered to help you focus on the “highest impact, lowest risk” actions first. 

Important 

Qhub provides data-driven insights and recommendations. It does not automatically make changes in your tenant, and it does not replace your contractual documentation (e.g., Microsoft Product Terms, EA/MCA/CSP agreements, custom amendments). Always validate high-impact changes with your internal stakeholders and, where appropriate, LicenseQ consultants. 

4.2 Data points used 

The Optimization Engine uses multiple categories of signals. Not every organization has the same telemetry available, so results may vary depending on permissions, data scope, and available reports. 

Licensing and entitlement data

Used to understand what you have purchased and how it is currently allocated: 

• License SKU / plan name (e.g., Microsoft 365 E3/E5, add-ons) 
• Part numbers (where available) 
• Purchased quantity (prepaid) 
• Assigned quantity (consumed/allocated) 
• Unassigned quantity (prepaid but not allocated) 

Identity and user metadata

Used to identify who the license is assigned to and to group users: 

• User identifier (e.g., UPN) 
• Tenant / domain (in multi-tenant scenarios) 
• Group membership or organizational attributes (if available) 
• Role indicators (e.g., privileged/admin accounts, where applicable) 

Activity and usage signals

Used to determine whether a license is needed and which workloads are used: 

• Sign-in activity (e.g., last sign-in date) 
• Workload usage signals (e.g., Teams, Exchange, SharePoint, OneDrive usage indicators) 
• Service-specific usage (e.g., Power BI usage, security workload usage) where available 

Product capabilities and dependencies (license logic)

Used to interpret what a license enables: 

• Mapping of license plans to enable workloads/features 
• Known “feature gates” (what you typically lose/gain when moving between SKUs) 
• Add-on equivalencies (where a downgrade could be combined with a smaller add-on) 

Qhub maintains an internal “license capability model” that maps SKUs to feature sets and uses telemetry to infer whether those features are required. 

Pricing inputs

Used to calculate savings: 

• Microsoft default price list (list price) and/or 
• Customer-specific or partner price list (discounted prices) if provided or configured 
• Currency and annualization assumptions 

Savings are shown as monthly amounts and the default price source is Microsoft list price unless a custom price list is configured. 

4.3 How savings are calculated 

Savings in Qhub are expressed as monthly savings potential. The general formula is: 

Monthly savings = (Price per license per month) × (Number of licenses that can be removed or downgraded)

Remove license scenario (unassigned or inactive)

If a license is identified as removable, savings are calculated as: 

• Remove savings = Monthly price of the SKU × Count of removable licenses 

Examples: 

• Removing 10 unassigned licenses of SKU X 
• Removing licenses assigned to users inactive beyond the configured threshold

Downgrade scenario (SKU→lower SKU) 

If the engine recommends downgrading, savings are calculated as: 

• Downgrade savings = (Monthly price of current SKU − Monthly price of target SKU) × Count of users eligible for downgrade 

If a downgrade requires a compensating add-on, the add-on cost is included: 

• Downgrade savings (with add-on) = (Current SKU − (Target SKU + Add-on)) × Count

Annualization and price source caveats

Savings are estimates and depend on: 

• Whether the platform uses list price or your actual discounted prices 
• Contract model constraints (e.g., CSP/NCE cancellation rules, EA renewal timing) 
• Whether taxes, local pricing, or special amendments apply 

Best practice: use the savings numbers to prioritize actions and to build a business case. For contract-level decisions, align the model with your actual commercial terms and price lists. 

4.4 Why certain recommendations are prioritized 

Qhub prioritizes recommendations to help you focus on quick wins first and avoid unnecessary disruption. 

Typical prioritization factors: 

Estimated savings impact 

Higher annual savings opportunities appear higher. 

Confidence level / evidence strength 

Recommendations backed by strong signals (e.g., unassigned licenses, long inactivity) are prioritized. 

Ease of execution 

Actions that are typically simpler and safer to implement are shown earlier. 

Risk indicator 

Lower-risk actions (e.g., remove unassigned licenses) are prioritized over higher-risk actions (e.g., major SKU changes for business-critical users). 

Contract timing relevance (optional) 

If contract timing is configured (e.g., renewal/true-up windows), the platform may highlight items that matter most ahead of key decision moments. 

The product either already uses, or can later incorporate, a prioritization score that combines “impact × confidence ÷ risk”. 

4.5 Recommended risk interpretation 

To help users act responsibly, recommendations should be interpreted with a risk lens. A simple and practical guidance framework is: 

Low risk 

Typical examples: 

• Unassigned licenses (prepaid but not allocated) 
• Licenses assigned to accounts clearly deprovisioned or dormant (where policy allows removal) 

Why low risk: minimal business disruption, clear evidence, easy rollback. 

Medium risk 

Typical examples: 

• Downgrades based on usage patterns where occasional/rare feature use may not be visible 
• Inactivity-based recommendations where exceptions may exist (leave, seasonal workforce, service accounts) 

Why medium risk: requires stakeholder validation and exception handling. 

High risk 

Typical examples: 

• Downgrading users in regulated/critical roles 
• Removing licenses that enable security/compliance features without confirming business requirements 
• Changes affecting privileged/admin accounts or shared service accounts 

Why high risk: higher chance of business impact, compliance impact, or operational disruption. 

Recommended workflow: 

Low risk → batch/pilot execution 

Medium risk → validate with managers/app owners, then staged rollout 

High risk → validate + document + consider expert review 

4.6 Assumptions and configuration 

The Optimization Engine applies default thresholds and rules. These defaults can be tuned to your organization. 

Common configurable assumptions include: 

Inactivity definition 

“Inactive” may mean: no sign-in activity for 90 days, and/or no workload activity for 90 days. 

Underutilization thresholds 

Minimum activity thresholds for specific workloads or features to justify a license plan. 

Scope filters 

Exclude or flag categories such as: 

• Privileged/admin accounts 
• Service accounts 
• Executives/VIPs 
• Regulated roles 

Price list selection 

Use Microsoft list price vs. a customer-specific price list. 

Tip: Document your organization’s chosen settings (inactivity window, exclusions, price source) so you can interpret results consistently across teams and over time. 

4.7 Limitations 

While the Optimization Engine provides robust, data-driven recommendations, there are limitations: 

Contract nuance is not fully visible 

The engine cannot automatically interpret every nuance of your contractual terms, custom amendments, legacy offers, or specific cancellation windows. 

Telemetry does not capture everything 

Some business-critical use cases can be infrequent and may not be reflected in usage telemetry. 

Complex bundling may require interpretation 

Certain enterprise deals and custom SKU mixes require manual review to ensure the “best” optimization is also commercially and operationally correct. It is strongly advised to involve LicenseQ experts to ensure the best outcome. 

Recommendation: always cross-check high-impact decisions against your contract documentation and internal policies.

4.8 When to consult LicenseQ experts 

Consider involving LicenseQ consultants when: 

• You are restructuring or renewing a large Enterprise Agreement or major CSP/NCE commitment. 
• You are planning significant seat reductions, plan changes, or re-baselining that could have contractual or commercial impact. 
• You see substantial compliance risks or discrepancies between Qhub insights and your internal understanding. 

LicenseQ experts can help interpret complex scenarios, validate assumptions, and design an implementation and negotiation strategy based on Qhub outputs.