Short answer: Siebel module licensing prices each Siebel CRM application — Sales, Service, Call Center, Marketing, Partner Relationship Management, Field Service, Loyalty — as a separate line item on its own user metric. Every user needs a licence for every module they can access, and many Siebel options (Configurator, Analytics, Workflow) ship pre-installed but require their own licence. Module sprawl and accidentally enabled options are the two largest Siebel audit findings.
Key Takeaways
- Siebel is licensed module by module, not as one suite — each application (Sales, Service, Marketing, PRM, Field Service) is a separate line item on its own user metric, so you only license what you deploy but you license every module each user touches.
- A user authorized for two modules needs two module licences. A 1,000-person team across three modules can represent up to 3,000 module-user licences — module-to-user mapping is the core right-sizing exercise.
- Siebel options such as Configurator, Analytics, Email Response, and Workflow ship inside the base install but require a separate licence; accidentally enabled options are present in a significant share of Siebel estates (Oracle Licensing Experts, 2026).
- Siebel support runs at roughly 22% of net licence value per module per year, so dropping support on shelfware modules removes that cost from the recurring base permanently.
- Oracle's LMS scripts inventory which modules and options are installed and accessed, then claim a licence for every active combination — so the raw audit output overstates true liability until cross-module access and dormant options are corrected.
What This Guide Covers
- How is Siebel CRM licensed by module?
- What are the core Siebel base modules?
- Base application vs option: what is the difference?
- What are the most common Siebel option traps?
- How does cross-module access drive cost?
- How does Oracle audit Siebel modules and options?
- How to right-size your Siebel module stack
How is Siebel CRM licensed by module?
Short answer: Siebel is licensed module by module. Each Siebel application — Sales, Service, Call Center, Marketing, Partner Relationship Management, Field Service, Loyalty — is a separate product on its own order-form line with its own user metric. You license only the modules you deploy, but every user authorized to use a module needs a licence for that specific module.
Siebel CRM is not sold as a single all-you-can-use suite. Oracle licenses it as a portfolio of discrete applications, and your entitlement is the sum of the individual module lines on your order forms — nothing more. A Siebel module is a self-contained CRM application licensed as its own product; Siebel Sales, Siebel Service, and Siebel Marketing are three separate licences, not one. This modular structure is what makes Siebel both flexible and dangerous: flexible because you pay only for what you deploy, dangerous because it is easy to deploy — and grant access to — more than you bought.
The metric layered on top of each module determines who counts. Most internal Siebel modules are licensed on Named User Plus or Application User; customer- and partner-facing functionality often uses Registered User. We cover those metrics in depth in Siebel user licensing: Registered vs Named vs Concurrent. This page sits within the broader Oracle Siebel Licensing Guide, which maps support, end of life, and migration; here we focus on the module and option stack itself.
What are the core Siebel base modules?
Short answer: The core Siebel base modules are Siebel Sales, Siebel Service (Call Center), Siebel Marketing, Siebel Partner Relationship Management, Siebel Field Service, and Siebel Loyalty. Each is licensed separately on its own user metric. Industry editions — Siebel Financial Services, Communications, Public Sector — layer vertical functionality on top and carry their own pricing.
Siebel's module catalogue is broad, but most enterprise deployments revolve around a handful of base applications. Siebel Sales covers opportunity, account, and pipeline management for sales teams. Siebel Service (and Siebel Call Center) covers case management and contact-centre operations for service agents. Siebel Marketing covers campaign management and segmentation. Siebel Partner Relationship Management (PRM) covers partner-portal and channel functionality, typically licensed against external users. Siebel Field Service covers dispatch, scheduling, and on-site work order management for field technicians.
On top of these, Oracle sells vertical industry editions — Siebel Financial Services, Siebel Communications, Siebel Public Sector, Siebel Life Sciences — which bundle industry-specific data models and workflows and are priced as their own products. The practical point for buyers: the name "Siebel" on an invoice tells you almost nothing. You must read the order forms line by line to know which modules and editions you actually own, because that defined list is the entire boundary of what you are entitled to deploy.
| Module | What it covers | Typical user metric | Typical user class |
|---|---|---|---|
| Siebel Sales | Opportunity, account, pipeline management | Named User Plus | Employee |
| Siebel Service / Call Center | Case management, contact centre | Named User Plus / Concurrent | Employee |
| Siebel Marketing | Campaign management, segmentation | Named User Plus | Employee |
| Siebel PRM | Partner portals, channel management | Registered User | Customer/Partner |
| Siebel Field Service | Dispatch, scheduling, work orders | Named User Plus | Employee |
| Siebel Loyalty | Loyalty programmes, member management | Registered User | Customer/Partner |
Base application vs option: what is the difference?
Short answer: A Siebel base application is a standalone module such as Siebel Sales that delivers core CRM functionality. A Siebel option is an add-on — Configurator, Analytics, Email Response, Workflow — that requires an underlying base licence and is licensed separately on top of it. Options frequently ship pre-installed, so they can be activated and used without anyone purchasing the entitlement.
The base/option distinction is where Siebel licensing starts to bite. A Siebel base application is a complete CRM module you license as a product. A Siebel option is functionality that extends a base module but cannot be used without it — and which Oracle prices and licenses as a separate line. Crucially, several options are part of the standard Siebel install media: the code is present whether or not you bought the licence, so a configuration change or a workflow build can switch on a chargeable option without any purchase, download, or warning.
Common Siebel options include Siebel Configurator (guided product and pricing configuration), Siebel Analytics / Oracle BI Applications for Siebel (analytical reporting beyond standard views), Siebel Email Response (inbound email management), Siebel Workflow / Business Process Designer (process automation), and Siebel Smart Answer (knowledge-driven response). Each requires the relevant base module plus its own option licence. The forensic question in any review is not "what did we buy" but "what is switched on" — because Oracle's claim is built from the second list, not the first.
Insider note: Oracle's strongest Siebel claims rarely come from buying too few user licences — they come from options that were enabled by a developer or admin years ago and never licensed. The code shipped in the box; usage made it chargeable. Treat every enabled option as a line you must either license or switch off and document.
Our Compliance Review service inventories every installed module and active option, maps it to your entitlements, and flags the gaps before Oracle's LMS scripts find them.
What are the most common Siebel option traps?
Short answer: The most common Siebel option traps are accidentally enabled options that ship with the base install (Configurator, Analytics, Workflow), users accessing a module they are only licensed for under a different module, and external partner users running Employee-class functionality. These three patterns drive the bulk of Siebel back-licence claims because each is invisible until an audit surfaces it.
Siebel option traps share a common shape: usage outruns entitlement quietly, over years, with no procurement event to flag it. The recurring offenders are predictable. Accidentally enabled options top the list — Configurator or Workflow switched on during an implementation and never licensed, because the code was already present. Module bleed comes next: a user licensed for Siebel Sales who, through a configuration or role change, gains access to Service screens they were never licensed to use. Class mismatch rounds it out: external partner-portal users granted Employee-class functionality, which Oracle back-assesses at the higher internal price.
The financial consequence is amplified by Oracle's standard remedy. An option found in use is back-licensed to the date usage began, plus 22% support backdated across that period — so a single option enabled four years ago can generate a claim several multiples of its list price. Across Siebel engagements, the initial Oracle audit claim is typically 3-5x what the customer actually owes once dormant options are disabled, cross-module access is corrected, and entitlements are applied (Oracle Licensing Experts, 2026). The defence is forensic: prove what is genuinely in use, switch off what is not, and document the corrected position with evidence.
How does cross-module access drive cost?
Short answer: Because each Siebel module is licensed separately, a user who can access two modules needs two module licences — even if they are one person. Siebel responsibilities and views often grant access beyond what was licensed, so a thousand users with role-based access to three modules can require up to three thousand module-user licences. Access mapping is the single biggest cost driver.
Cross-module access is the most under-appreciated Siebel cost driver, and it stems directly from the module-by-module model. In Siebel, access is governed by responsibilities and views — and a poorly scoped responsibility can grant a Sales-licensed user visibility into Service or Marketing screens. Oracle's position is unforgiving: if a user can access a module, that user needs a licence for it, regardless of whether they use it daily or have ever clicked into it. So the licensable population for a module is not "who uses it" but "who can reach it."
This is why the licensed count can balloon far past headcount. Imagine 1,000 internal users, each with a role that touches Sales, Service, and Marketing screens: that is potentially 3,000 module-user licences, not 1,000. The right-sizing work is to map responsibilities to actual job function, strip cross-module visibility nobody needs, and reduce each user to the modules their role genuinely requires. Tightening responsibilities is one of the highest-yield corrections in a Siebel review because it attacks the multiplier directly. For the wider negotiation and cost levers around this, see our Oracle negotiation guide.
How does Oracle audit Siebel modules and options?
Short answer: Oracle's LMS scripts inventory which Siebel modules and options are installed and which users can access each, then build a claim for every active module-user combination and every enabled option. The audit measures installed-and-accessible, not used, so the raw output overstates liability until cross-module access and dormant options are corrected against entitlements.
Oracle's License Management Services (LMS) scripts for Siebel do two things. First, they inventory the installed footprint — which modules and which options are present and active in the environment. Second, they read the security model — responsibilities, views, and user records — to determine which users can access which modules. The output is a matrix of module-by-user access plus a list of enabled options, and Oracle's claim is built directly from that matrix against your purchased entitlements.
The systematic overstatement comes from the same root as every Siebel audit: the scripts measure capability, not consumption. An option present in the install media counts if it shows any sign of use; a user with a broad responsibility counts against every module that responsibility can reach. The remediation is evidence-based and methodical — you do not contest the script output, you demonstrate which access should never have been granted and which options were never genuinely licensed-relevant, then re-scope and document. For the full audit method — what LMS measures, what you are obliged to disclose, and how to challenge findings — see our Oracle Audit Defense Guide and our Audit Defense service.
How to right-size your Siebel module stack
Short answer: Inventory every installed module and active option, map responsibilities to actual job function, disable options you do not license and do not need, strip cross-module access nobody uses, and drop support on shelfware modules at renewal. Each step is documented with evidence so the reduced position is defensible against Oracle's LMS scripts.
Right-sizing the Siebel module stack follows a clear sequence, and like user-count cleanup, it is fully buyer-controlled. Start with a complete inventory: which modules are installed, which options are active, and which users can reach each module through their responsibilities. Then act on what you find — disable options you neither license nor need; tighten responsibilities so each user maps only to the modules their role requires; remove cross-module visibility that exists by accident; and identify modules carrying support that no active user depends on.
The recurring cost lever is support. Siebel support runs at roughly 22% of net licence value per module per year, so dropping support on a genuinely unused module removes that line from your support base permanently. A documented reduction — disabling two unlicensed options and de-supporting one shelfware module — can cut both audit exposure and annual support in a single renewal. This pre-emptive cleanup is the core of our License Optimization service, and it pairs with support de-bundling and third-party support, covered in the Siebel Licensing Guide. For results, see how we eliminated audit exposure in our healthcare compliance case study.
Siebel Module Licensing FAQ
How is Siebel CRM licensed by module?
Siebel is licensed module by module, not as one suite. Each application — Siebel Sales, Service, Call Center, Marketing, Partner Relationship Management, Field Service, Loyalty — is a separate line item licensed on its own user metric. You license only the modules you deploy, and each user must hold a licence for every module they can access, so cross-module access without entitlement is a common audit finding.
What is the difference between a Siebel base application and an option?
A Siebel base application is a standalone module such as Siebel Sales or Siebel Service that delivers core CRM functionality. A Siebel option is an add-on — such as Siebel Analytics, Configurator, or Email Response — that requires an underlying base application licence and is licensed separately on top of it. Activating an option without its licence is a frequent back-licence claim.
Do Siebel modules require separate licenses for each user?
Yes. A user authorized to access two Siebel modules — for example Siebel Sales and Siebel Service — needs a licence for both, even if they are the same person. Oracle counts module access per user, so a 1,000-person team using three modules can represent up to 3,000 module-user licences. Mapping who actually uses each module is the core right-sizing exercise.
What are the most common Siebel option traps in an audit?
The most common Siebel option traps are accidentally enabled options such as Siebel Configurator, Analytics, or Workflow that ship with the base install but require a separate licence; modules accessed by users who are only licensed for a different module; and partner-portal users running Employee-class functionality. Across Siebel engagements these unlicensed options are present in a large share of estates (Oracle Licensing Experts, 2026).
Can I reduce Siebel module costs by removing unused modules?
Yes. Because Siebel support is charged at roughly 22% of net licence value per module per year, dropping support on a module you no longer use removes that line from the support base permanently. Identify shelfware modules, confirm no active users depend on them, and de-bundle or terminate support on those lines at renewal to cut the recurring cost.
Is Siebel CRM Analytics licensed separately from Siebel base modules?
Yes. Siebel analytics capabilities — historically Siebel Business Analytics and Oracle BI Applications for Siebel — are licensed separately from the base CRM modules, typically on their own user or processor metric. Reporting that goes beyond standard Siebel views can trigger an analytics licence requirement, so confirm what your reporting layer actually invokes before an audit.
Does a Siebel ULA cover all modules and options?
No. An Oracle ULA (Unlimited License Agreement) covers only the specific Siebel products and options named in its scope. Modules and options outside that defined product list are not covered and remain separately licensable. Before certifying a ULA, confirm exactly which Siebel modules and options are in scope, because anything deployed outside the list becomes a back-licence exposure at certification.
Is your Siebel module stack overlicensed — or exposed?
We inventory every installed module and active option, map responsibilities to real job function, strip the access nobody needs, and hand you a defensible position — before Oracle's LMS scripts run. Independent, buyer-side, 600+ engagements.