Oracle Siebel CRM Licensing FAQ

Oracle Siebel CRM perpetual licensing requires understanding user types, metrics, and modules to ensure compliance and optimize costs. Effective license management can save significant costs and prevent compliance issues.

Siebel CRM covers various CRM functionalities, each potentially licensed differently, so it’s crucial to grasp these details. This FAQ provides detailed answers to help you confidently navigate Siebel’s on-premises licensing model.

Siebel CRM Licensing

What is Oracle Siebel CRM, and what does on-premises perpetual licensing mean?

Oracle Siebel CRM is a comprehensive Customer Relationship Management suite, originally developed by Siebel Systems and now part of Oracle’s product portfolio. It includes modules for sales, service, marketing, partner management, loyalty programs, analytics, and more, all designed for deployment on your servers (on-premises).

On-premises perpetual licensing means you purchase a license indefinitely (perpetually) in your environment, typically with a one-time fee per user or processor, plus optional annual support. This differs from cloud or subscription (where you pay recurring fees; here, you own the rights to run the software internally as long as you comply with the license terms.

Oracle Siebel on-premises licenses are perpetual – they do not expire – though you will likely maintain a support contract and support. (Oracle’s cloud CX products are separate and not covered in this FAQ, which focuses exclusively on on-premises Siebel licensing.)

Which Siebel CRM modules are available under on-premises perpetual licensing?

Oracle Siebel CRM is modular. Major Siebel product lines available for on-premises perpetual licensing include:

• Siebel Sales – for sales force automation (accounts, contacts, opportunities, quotes, etc.).
• Siebel Service – customer service, helpdesk, and contact center management.
• Siebel Marketing – for campaign management, segmentations, and marketing resource management.
• Siebel Field Service – for managing field technicians, dispatch, and service orders.
• Siebel Loyalty – for customer loyalty programs and rewards management.
• Siebel Partner Relationship Management (PRM) manages partner/reseller interactions via partner portals.
• Siebel Analytics is for reporting and business analytics (functionality is now largely part of Oracle Busigence).
• Other components include Siebel Customer Order Management (quotes and product configuration), Siebel Tools (configuration/development environment), and various industry-specific solutions (e.g., Siebel Financial Services, Siebel Communications for telecom, etc.).

All these modules are available as on-premises software. Each may have its licensing requirements, but all typically use a perpetual license model (one-time purchase per metric, plus support). In practice, a Siebel deployment often involves a Siebel CRM Base module plus one or more of these specific modules to fit the business.

What is an Application User license in Siebel?

Application User is one of the primary user-based licensing metrics for Siebel CRM. An Application User license is defined as an individual authorized to use the Siebel application, regardless of whether they are actively using it at any given moment. In other words, every person given login access to the Siebel system counts as an Application User and must have a license.

This metric is typically used for internal employees using Siebel. Key points about Application User licensing:

• It is a named-user license (not a concurrent license). If a user has access, they require a license even if they log in rarely or never.
• Licenses are assigned per individual (you cannot share one license among multiple people).
• Example: If your company has 150 employees with Siebel login accounts (even if only 100 use it regularly), you must license all 150 as Application Users.
• This metric is common across Siebel modules (e.g., Siebel Sales, Service, etc., often sold per Application User).

In summary, Application User = per named person with access. Always ensure that the total number of individuals with Siebel access does not exceed your Application User licenses, or you may face compliance issues.

What is Siebel?

Named User Plus (NUP) is another user-based metric Oracle uses for some Siebel components. It is similar to Application User, based on named individuals authorized to use the software. The “Plus” in Named User Plus indicates that non-human-operated devices (like automated scripts or interfaces) that access the software also count as named users, and it comes with some Oracle-specific counting rules.

Key aspects of Named User Plus:

• It counts all humans and devices that access the software. For example, if a script or a kiosk accesses Siebel directly, it would consume a NUP license like a user.
• Suppose you use any multiplexing (middleware that pools connections). In that case, Oracle’s policy is that you must count the end-users behind the multiplexing, not just the single technical user (i.e., measure at the “front end” of the multiplex).
• Oracle enforces minimum NUP quantities per processor for certain products. That means if you choose NUP licensing, you must have at least a certain number of NUP licenses per CPU of the server, as defined in Oracle’s rules. (For example, if a Siebel component had a rule of “25 Named Users Plus per processor minimum” and you run it on an 8-core server, you’d need at least 200 NUP licenses, even if actual users are fewer.)

Many Siebel CRM modules use the Application User metric rather than NUP. However, some related components or older licensing schemes might use NUP (for instance, Oracle Application Management Suite for Siebel can be licensed per Named User Plus).

The NUP metric is more commonly seen in Oracle’s technology products, but it is good to understand since it may apply to certain Siebel-related licenses.

Bottom line: Named User Plus is a named-user license with additional Oracle counting rules. If it’s the metric for a Siebel component, you must count all individuals (and devices) accessing that component, adhering to any minimums.

What is Processor licensing in the context of Siebel?

Processor-based licensing means you license the Siebel software by the processing power of the servers (CPUs) it runs on, rather than by individual users. In Oracle terms, a “Processor” license typically allows unlimited users to access the software on a server with a certain number of CPU cores (Oracle counts cores with a core-factor table to determine processors).

This model is often used when counting users is impractical (for example, a public-facing system with many external users), or when an organization wants the flexibility to have unlimited users.

Key points:

• Unlimited users: If you license by Processor, you do not need to count individual user licenses for that component—any number of users can use it, up to the hardware’s capacity.
• Based on cores: Oracle defines the number of processor licenses required by counting the cores in the server and applying a factor per core (for example, an 8-core server might count as four processors after applying a 0.5 core factor per core, so you’d buy four processor licenses). In simpler terms, more CPU cores = more processor licenses needed.
• When to use: Processor licensing is ideal for Siebel deployments with a large or unpredictable user base, such as an externally-facing customer portal with thousands of users, where buying per-user licenses would be cumbersome or more expensive. It’s also used if you have many service accounts or integrations where user counting is complex.
• Cost vs. benefit: Processor licenses are expensive, but if you have a huge user count, they can be cost-effective compared to thousands of named users. They also automatically cover new users as your organization grows since you’re licensing capacity, not headcount.

Not every Siebel module is offered in a Processor metric option, but some are. For example, Oracle’s price list shows that Oracle Application Management Suite for Siebel can be licensed by a processor instead of NUP, with a minimum of 4 processors. If you choose processor licensing, understand Oracle’s core factor calculation and any minimum processor purchase requirements.

In summary, Processor licensing lets you cover a Siebel application by machine capacity for unlimited users, which is useful for high-volume or external use cases, albeit at a higher cost structure.

What is a Registered User metric in Siebel, and when is it used?

Registered User is a licensing metric used for external (non-employee) users of Siebel applications, such as partners or customers. Like an Application User (a named individual authorized to use the software), a Registered User is specifically restricted to business partners or customers, not employees.

In practice, Oracle uses the Registered User metric for Siebel modules designed for partner or customer access (external-facing modules). Key points:

• External users only: Registered Users are typically partners, dealers, or customers who log in to a Siebel-based portal or application. Oracle’s terms explicitly state that a Registered User cannot be a customer employee. Employees should be licensed as Application Users instead.
• Examples: The Siebel Partner Portal and related partner modules often use the Registered User metric. For instance, if you have 50 partner sales reps using your Siebel PRM portal, you would need 50 Registered User licenses for Siebel Partner Portal. Similarly, a Siebel Customer Portal (self-service) could be licensed by Registered Users (each customer with login access).
• Similar to named user: Like Application User, this is a named-user metric (each named external user needs a license). It’s not a concurrent license; it’s based on the count of individuals authorized.
• Why separate metric: Oracle differentiates external users because they often price these licenses differently (usually higher per user) since external users can be numerous and provide different business values. External user metrics (like legacy Concurrent or Registered) are more costly than internal ones.

In summary, Registered User licenses cover partners/customers accessing Siebel. Make sure you purchase the correct type of license for external users. Using an internal metric (like Application User) for external people is not compliant – Oracle expects you to use the external metrics for non-employees. If the number of external users is very large, you might consider processor licensing instead, but otherwise, count each partner/customer that gets access as a Registered User.

Are there other usage-based licensing metrics in Siebel (for example, by records or transactions)?

Yes. In addition to user-based and processor metrics, some Siebel modules use usage-based metrics tied to the volume of data or transactions.

These metrics measure something other than just users. Examples include:

• Member Records: Siebel Loyalty modules are often licensed by the number of loyalty program members. For instance, the Siebel Loyalty Engine might be licensed in packs of 100,000 member records. If you have 500,000 members in your loyalty program, you might need to purchase 5 units of the “100k Member Record” license. (Oracle’s price list shows Siebel Loyalty Standard Edition priced per 100k Member Records, with a minimum purchase of a certain number of units).
• Customer Records (Contacts): Siebel Marketing is a good example. The Siebel Marketing Server is licensed by the number of unique customer records (prospects/contacts) that can be targeted, usually in tiers (e.g., up to 500k records, up to 1M records, etc.) and often per server. Oracle states: “The Siebel Marketing Server program is licensed on a Computer basis together with the number of unique Customer Records you may access using the program.”. This means you buy a license for each server running the Marketing Server, and you select a tier based on how many contact records will be used in campaigns (with larger tiers costing more).
• Electronic Order Lines: For Siebel Order Management, while users entering orders manually are covered by user licenses, any orders injected electronically (through EDI, XML, integration from a website, etc.) might need a separate license measured in number of order lines. Oracle’s definitions mention that orders entered from other sources must be licensed by the Electronic Order Line metric, typically in blocks of a certain number per year.
• Claims: In Siebel modules for insurance or warranties, there are metrics like “1,000 Claims” – you license a certain number of claims processed yearly. For example, Siebel Warranty or insurance claim processing might require buying licenses per batch of 1,000 claims processed annually.
• Device/Server metrics: Some integration or technical components can have metrics like Connector (per integration connector), Application Instance (for integrated application instances), or simply per Computer (for certain server-side components, each installation counts). For instance, as noted above, Siebel Marketing Server uses “per Computer” plus records.

These usage-based metrics are typically for specific add-on modules rather than the core CRM base. They ensure your license by the scale of usage. For example, a company with a huge marketing database will pay more than one with a small marketing list, independent of user count.

Important: When licensing such modules, carefully estimate your usage (records, transactions) to purchase the appropriate amount and remain compliant if usage grows (you may need to true-up if you exceed licensed quantities).

Licensing for Major Siebel Modules

What is the Siebel CRM Base license, and is it required for all users?

Yes, the Siebel CRM Base license is a foundational entitlement, and typically, every Siebel user needs a Siebel Base license as a prerequisite. Oracle’s policy is that, at minimum, each employee user of Siebel must be licensed for the base application.

The Siebel CRM Base provides core CRM functionality (common entities like Accounts, Contacts, Activities, etc. that underpin all modules).

Key points about the Base license:

• Prerequisite for other modules: If a user is going to use Siebel at all (whether for Sales, Service, etc.), you start by licensing them with the Siebel CRM Base application user license. Then, you add on specific module licenses as needed. Oracle notes: “Every Siebel customer must license, at a minimum, one Siebel CRM Base Application. Typically, each employee user of Siebel applications requires a base… All users requiring a base must license the Siebel CRM Base.”.
• Industry Base Options: Besides the generic base, Oracle offers industry-specific modules (for example, Siebel Financial Services Base, Siebel Communications/Media/Energy Base, Siebel Public Sector Base, etc.). These are used if you are deploying an industry-specific version of Siebel. In those cases, a user might need generic and industry-based options. Oracle’s guidance: if you use an industry solution, all users must have the standard Siebel CRM Base and the industry base for that sector.
• One per user: You do not need to double-count base licenses for the same person. One user = one base license. After that, you can mix and match additional module licenses for that user.
• Example: Suppose you have 100 users in a Siebel deployment: 60 in Sales, 40 in Service. All 100 would need the Siebel CRM Base license. Then, 60 would also have Siebel Sales module licenses, and 40 would have Siebel Service module licenses (some might have both if they perform both roles).

In summary, the Siebel CRM Base is the entry ticket for any user. It ensures they have rights to the core Siebel platform. Virtually all Siebel modules (except a few utilities) require the user to have a base license. Always include the base license in your planning for the number of Siebel users.

How is Siebel Sales (Sales Force Automation) licensed?

Siebel Sales functionality (Sales Force Automation) covers modules for managing leads, opportunities, accounts, contacts, forecasting, etc. Licensing for Siebel Sales generally works as follows:

• Each sales user must be licensed as an Application User (per named user). As discussed, every salesperson who uses Siebel must have a license.
• Sales users will require the Siebel CRM Base license (as a prerequisite) and usually the Siebel Sales module license. Oracle’s price list doesn’t have a single line item called the “Siebel Sales” module; instead, sales functionality is encompassed in the base, and there is a set of optional add-ons. The base license often covers core sales functions (account and opportunity management). Additional sales capabilities come as add-on modules:
  • Example add-ons: Siebel Forecasting, Siebel Sales Coach/Methodology modules (like Siebel Target Account Selling (TAS) or Siebel Enterprise Selling Process), Siebel Proposal & Presentations, etc., are features you can license on top of the base if you need them. Each of these, if used, would typically be licensed per Application User as well.
• In practical terms, many customers simply count all their sales team members and buy that number of Siebel Base licenses and (if needed) Sales option licenses. The base license might suffice if your sales deployment uses only standard features. If you implement specific add-on modules (for example, Siebel Quotes and Order Capture might fall under Order Management licensing), you’d license those per user, too.
• Example scenario: 50 salespeople using Siebel for contact, opportunity management, and forecasting. You would purchase 50 Siebel CRM Base user licenses and 50 Siebel Forecasting licenses (assuming forecasting is an optional module). If those users also use the quoting system (which might require a Siebel Order Management license), you’d get 50 of those. Essentially, each user consumes one license type for each module they use.

Importantly, Siebel Sales is licensed by user, not by revenue or pipeline. The capacity of data (number of accounts or opportunities) doesn’t directly factor into licensing cost – it’s about how many users access the system. Ensure every sales user is counted, including the base and any relevant optional modules.

Also, remember that if you’re in a specific industry edition of Siebel (like Siebel Pharma or Siebel Finance), your users might need the industry base license in addition to the standard base, as noted earlier.

How is Siebel Service (Call Center) licensed?

Siebel Service, which includes call center and customer service modules, is also primarily licensed per user (Application User metric). Each customer service agent or call center representative who uses Siebel requires a license.

Key points for Siebel Service licensing:

• Like Sales, every Service user (agent) needs a Siebel CRM Base license plus the Siebel Service module license. Siebel Service capabilities cover service requests, trouble tickets, a knowledge base, email response, etc., and are part of the Siebel CRM application.
• Oracle’s price list includes various service-related modules, such as Siebel Email Response, Siebel Call Center (telephony/CTI integration), Siebel HelpDesk (for internal IT support desks), and Siebel Quality Management. These are add-ons under the Service umbrella. If you deploy them, they would typically each be licensed per user.
• Computer Telephony Integration (CTI): If your call center uses CTI (screen pop, dialing, etc.), Siebel CTI is an add-on module licensed per user (Application User) as well. So, each agent using CTI needs that entitlement.
• Internal vs. External Service: If you have an internal helpdesk (using the Siebel HelpDesk module to support employees), those users are still counted as standard Application Users. If you offer a customer self-service portal (where customers can log their service requests), that falls under external user licensing—we cover that separately in the external user’s questions.
• Example: A call center has 30 agents and five supervisors using Siebel. Each of those 35 people needs a Siebel Base license and a Siebel Service license (often sold as Siebel Call Center user licenses). If they also use Email Response, you’d also get 35 Email Response licenses. If CTI is enabled for all, 35 Siebel CTI licenses will be required. Essentially, each distinct module used by those users adds a per-user license.

Remember, Siebel Service modules are user-based. It doesn’t matter how many tickets or calls are handled (there’s typically no transaction metric for standard service requests). The important part is counting all the staff who use the system.

Also note that if a person has multiple roles (say, a salesperson occasionally also looks at service requests), that person would need to be licensed for both the Sales and Service modules. Modern Oracle licensing has no “concurrent agent” licensing for Siebel Service—it’s all named user.

How is Siebel Marketing licensed?

Siebel Marketing (part of the Oracle Siebel Marketing Automation suite) has a unique licensing model combining user and campaign contact volume licenses.

Key components of Siebel Marketing licensing:

• Marketing Users: Your marketing team members who use the Siebel Marketing application (for designing campaigns, building segments, etc.) are typically licensed as Application Users, similar to sales and service users. For instance, if you have 10 marketers using the system, each needs a Siebel Base license and likely a Siebel Marketing user license (such as Siebel Campaign Management or Marketing Resource Management module, if those are separate). Oracle’s price list indicates modules like Siebel Campaigns/Marketing and Siebel Marketing Resource Manager, which would be user-based. These cover the functionality for the marketers themselves.
• Marketing Server / Contacts: The Siebel Marketing Server, which executes campaigns and segmentation, is licensed by a combination of server and data volume. Specifically, it is sold per “Computer” (server) with tiers for the number of customer records (contacts) you will manage in marketing. For example, you might buy “Siebel Marketing Server – up to 500,000 records” for one server. You can buy a higher tier (up to 1M, 5M, 10M, or unlimited records) with more contacts. Each marketing server you deploy needs its license.
• Example: Suppose you have a marketing database of 800,000 contact records and run Siebel Marketing on two servers (one production, one test maybe). You might purchase two licenses of “Siebel Marketing Server – up to 1,000,000 records” (to cover each server up to 1M contacts). If your database grows beyond that, you’d move to the next tier license.
• Email Marketing / Advanced Capabilities: Siebel Marketing also includes specific features like Email Marketing Server, Dialogue Manager, etc., which may have their licensing (sometimes bundled or sold as options in older price lists). Be sure to check if those components (e.g., outbound email campaign server) require separate licenses or if they are included.
• Summary: Internal licensing – count your marketers as named users. External metric – license the marketing engine by how many contacts it will process. Oracle’s definition clarifies that the marketing server license is tied to unique customer records (prospects and contacts) accessible by the program.

The Siebel Marketing module pricing scales with the size of your marketing operation by combining user and data metrics. Always monitor your contact counts against your licensed tier.

If you exceed your purchased record tier (say you licensed up to 1M contacts and now have 1.2M), you should acquire additional licensing (upgrade to the next tier) to remain compliant.

How is Siebel Field Service licensed?

Siebel Field Service covers the functionality for dispatching technicians, managing work orders, spare parts, scheduling, etc. Licensing for Field Service has two main aspects:

• Field Service Users: The employees who use the Siebel Field Service module – dispatchers, field service engineers/technicians (if they log into Siebel on their laptops or mobile), and field service managers – must be licensed as Application Users. Just like other modules, each named user requires a license. For example, suppose you have 50 field technicians using the Siebel mobile client and five dispatch coordinators using the system. In that case, that’s 55 Siebel Field Service user licenses (each of those 55 also needs the Siebel Base license).
• Scheduling Engine (Field Resource): Siebel offers a scheduling/optimization engine (called Oracle Real-Time Scheduler or Dispatch Manager) that automatically assigns and schedules tasks for field service. This component is licensed not by user but by the number of Field Resources scheduled. A Field Resource is defined as any person to whom the scheduler can assign work – this includes field technicians, dispatchers, or anyone whose calendar is managed by the scheduling engine. The license metric is usually per “Field Resource” and may have a minimum purchase (for instance, a license at least 40 field resources, for example, minimum).
  • In practice, if you want to use the automated scheduling optimization for 50 techs, you would buy 50 Field Resource licenses for the scheduler component (often, the product name is Oracle Real-Time Scheduler for Siebel). Oracle’s price list definition: “Field Resource is defined as dispatchers using the programs, as well as engineers, technicians, representatives or other persons scheduled by the programs.”.
• Example: You have 50 techs and five dispatchers using Siebel Field Service. They all use the application, so purchase 55 Siebel Field Service user licenses. Additionally, you deploy the scheduling engine to optimize assignments for those 50 techs. You must license 55 Field Resources (because dispatchers might be considered resources too if they are scheduled or dispatching). If Oracle’s minimum for that product is 40, at least 55 meets it. If you only had 10 techs, you might still have to buy 40 Field Resource licenses if 40 is the minimum bundle.
• Other Field Service modules: Small add-ons (like Siebel Spare Parts Management, etc.) follow the same pattern—per user or per “item.” For example, Siebel Spare Inventory might be just part of the field service base, whereas something like Siebel Scheduler is the main separate metric, as described.

In summary, the licensing Field Service = count your people using it (user licenses) + count those being scheduled (Field Resource licenses if you use the scheduling engine). Ensure you do not overlook the Field Resource metric – it effectively covers the optimization engine. If you’re not using automated scheduling, you might not need that, and only standard user licenses apply.

How is Siebel Loyalty licensed?

Siebel Loyalty is a module for managing loyalty programs (points, tiers, promotions, member activities). Its licensing is two-fold, covering both the backend program size and the users administering it:

• Loyalty Engine (Members): The Siebel Loyalty Engine (which runs the loyalty program rules, tracks points, etc.) is typically licensed by the number of loyalty program members. Oracle uses a metric called Member Records, often sold in blocks of 100,000 members. For example, the price list shows Siebel Loyalty Engine Standard Edition – metric: 100K Member Records (minimum 5). This implies you must purchase a minimum of 5 x 100k = 500k member records worth of licenses to use that edition, and if your program grows, you buy more blocks. There might be different editions (Standard vs Multi-Partner) with different minimums.
  • Example: If your loyalty program has 1.2 million members, you would purchase 12 units of the 100k Member Record license. Oracle defines a Member Record as each unique loyalty member account in the system.
• Loyalty Application Users: The internal staff who set up and manage the loyalty program in Siebel (e.g., loyalty managers, marketing analysts, and customer service reps handling loyalty inquiries) need Application User licenses. Siebel Loyalty provides user roles like Loyalty Manager and Loyalty Member Services Representative, which appear separately priced user licenses in the Siebel price list. For instance, you might buy 2 Loyalty Manager user licenses for two admins and 10 Loyalty Member Service Representative licenses for 10 call center reps who handle loyalty customer calls. These are each per named user.
• Customer Access: If customers themselves access loyalty information via a portal (checking points, redeeming rewards online), that would be considered an external user scenario. Oracle had a module, the Siebel Loyalty Customer Portal. Those external users (customers) might be covered either by a separate external user metric or by the fact that you licensed the member records (depending on Oracle’s rules). Often, the member record metric covers the customers as entities, but if customers log in, sometimes Oracle expects an external user metric or a processor license. (This can be a bit complex – it’s worth clarifying with Oracle if a customer-facing loyalty portal is in use. In many cases, the combination of loyalty engine by member count and maybe a Siebel Customer Portal license covers it.)
• Summary: License the size of your loyalty program (members) plus license the employees managing it. For example, a retail company with 1 million loyalty members and a team of 5 loyalty managers would get (1) 10x100k member record licenses (to cover 1,000,000 members) and (2) 5 user licenses (e.g., 1 Loyalty Manager + 4 Loyalty reps, or however the roles split). If the program later grows to 1.5 million members, they’d need to buy additional member record licenses to remain compliant.

Siebel Loyalty’s member-based licensing ensures that larger loyalty programs pay more, aligning cost with value received. Always project your membership growth because exceeding the licensed member count could put you out of compliance (Oracle may audit the number of member records in the database). On the user side, count everyone internally who will use the loyalty module screens and make sure they have user licenses.

How is Siebel Partner Relationship Management (PRM) licensed?

Siebel PRM allows partner organizations (resellers, dealers, agents, etc.) to interact with your CRM – for example, through a Partner Portal where they can register deals, track opportunities, or place orders.

Licensing for Siebel PRM involves both the partner users and the internal users who manage partner relationships:

• Partner Portal Users (External Partners): These are typically licensed using the Registered User metric (as discussed earlier). Each partner user who will log in to the Siebel Partner Portal requires a Registered User license. These users are not your employees, so you cannot use an Application User license for them; it must be the partner-oriented license. For instance, if 30 individuals from various partner companies will use the portal, you need 30 Registered User licenses for Siebel Partner Portal (or more, if you anticipate growth – licenses are sold in whole units per user).
• Partner Modules and Options: Siebel PRM includes specific functionalities like Partner Commerce, joint partner marketing, etc. Oracle’s rule for PRM is that any optional partner modules must be licensed at a quantity no greater than the number of Partner Portal users licensed. For example, if you have 100 Partner Portal user licenses, you can have up to 100 Siebel Partner Commerce licenses (but you could choose fewer if not all partners use that feature). Since that wouldn’t make sense, you cannot have more partner module licenses than portal users. Oracle states: “Siebel partner options must be licensed at the same level or less than the Siebel Partner Portal for each partner user. For example, if the customer licenses 100 Siebel Partner Portal, then Siebel Partner Commerce must have a quantity of 100 or less”.
• Internal Partner Managers: Your employees who manage partner accounts (often using a Siebel Partner Manager module) are licensed as normal Application Users. In the price list, Siebel Partner Manager is an internal module for employees and is licensed per Application User. So if you have five channel managers who oversee partners, each needs a Siebel Partner Manager user license (and a Siebel Base license, as always).
• Partner Companies: Historically, Siebel had a metric for “Partner Organization” or “Partner Company” licensing (counting the number of partner businesses). Oracle seems to focus now on individual partner users instead, but be aware if you have an older contract. Sometimes, licensing was per partner company. In modern terms, Registered User per partner user is the norm.
• Example: You run a partner program with 20 partner firms, each with three users who will access the portal (total 60 partner users). Internally, three channel managers handle these partners. You would license 60 Registered Users of Siebel Partner Portal. You’d also license 3 Application Users of Siebel Partner Manager (for your internal folks). If you also allow partners to use, say, the Siebel Configurator or Quote functionality through the portal, you may need 60 of the corresponding partner option (like “Configurator for Partners”) licenses as well to match the 60 users, in addition to the portal itself.
• Note on portals: Siebel PRM is one type of external portal (for partners). The Siebel Customer Portal is also for end customers (like an eService web portal). Each has its licensing; PRM uses partner (registered user) licensing as described.

In summary, Siebel PRM = licensed external partner users + internal users. Always use the Registered User metric for partner users to stay compliant and ensure the number of any partner-specific module licenses does not exceed your licensed partner user count. If your partner user count is very large, consider whether a processor license might be more economical, but typically, Registered User suffices since partner communities are finite and identifiable.

How is Siebel Analytics (Business Intelligence) licensed for on-premises use?

Siebel Analytics was the name for Siebel’s BI capabilities (reporting and dashboards) which, after Oracle’s acquisition, evolved into Oracle Business Intelligence Enterprise Edition (OBIEE) and related products. Siebel user counts do not license the Siebel Analytics functionality but fall under Oracle’s BI licensing.

Here’s how it works:

• Oracle BI Platform: Siebel’s analytics modules (like pre-built Siebel Sales Analytics, Siebel Service Analytics, etc., in older versions) now require an Oracle Business Intelligence license. Oracle BI (whether OBIEE 11g/12c or Oracle Analytics Server/OAC nowadays) is typically licensed by Named User Plus or Processor, much like other Oracle technology products.
• Named User Plus for BI: If you have a known set of users who will run reports or view dashboards, you can license the BI Server by Named User Plus. You need an NUP license for each person who will access the analytics. Oracle usually sets a minimum number of NUP licenses per processor for BI. For example, if you choose that route, Oracle BI might require a minimum of 10 or 20 NUP per CPU.
• Processor for BI: If the analytics is being accessed widely (or you want to allow Siebel users to run reports without counting each one for BI licensing), you can license the BI component by Processor (CPU cores on the BI server). This covers unlimited users of the BI system.
• Siebel Analytics vs Oracle BI: Practically, you will buy a license for Oracle Business Intelligence Suite (or Oracle Analytics) rather than something labeled Siebel. For example, Oracle BI Foundation Suite was historically used. If you only use the Siebel pre-built analytics and only for Siebel data, Oracle once bundled one BI user license with Siebel, but generally you should assume you need full BI licensing. Oracle’s docs mention that one Named User Plus for Oracle BI Administrator may be included for Siebel Analytics. Still, any regular end users need licensing (that reference suggests a limited-use license might come with Siebel for one admin).
• Example: You have 50 Siebel users who need to use analytics dashboards. You could buy 50 Named User Plus licenses of Oracle BI (ensuring you meet any minimums). Alternatively, if your BI server has four cores, you could buy 2 processor licenses for Oracle BI (assuming a core factor of 0.5, 4 cores = 2 processors) to cover unlimited users. You would choose whichever is more cost-effective and aligns with your usage.
• Note: The Siebel application user licenses do not automatically cover the analytics features—the BI portion is a separate product. So, even though Siebel Analytics is conceptually part of the suite, licensing-wise, it’s separate. Plan for a BI license if you intend to use the analytics functionality on-premises.

In summary, Siebel’s analytics capabilities are licensed under Oracle’s BI licensing model—by Named User Plus or by Processor. Count how many people need to access reports or consider CPU licensing for broad access. Remember to license the database that stores the Siebel data warehouse or analytics schema (likely an Oracle Database, which has its licensing).

Do I need separate licenses for Siebel Tools (development tools) or other components?

Yes, Siebel Tools, the client application for configuring and customizing Siebel (used by developers and system administrators), is a licensable product. In an on-premises Siebel environment, you should account for licenses for the following components beyond the end-user modules:

• Siebel Tools: Oracle requires a license for each user of Siebel Tools (the development/configuration environment). Siebel Tools is listed and priced per Application User on the price list. Typically, a few people in IT or consulting roles use Tools to modify Siebel applets, business components, etc. You’d need 3 Siebel Tools user licenses if you have three developers. (In some cases, one Siebel Tools license might be included with a Siebel enterprise license bundle, but generally, it’s separate.)
  • Note: Oracle sometimes had a policy that Siebel Tools users also count as Siebel Base users, but effectively, if a developer is also an end-user, they’d need both licenses. However, Siebel Tools users are often not counted in the normal user licenses if they are solely developing on a non-production environment. Having proper Siebel Tools licenses for all who use it is safest.
• Test Automation / Test Framework: Siebel has a module called Siebel Test Automation Interfaces (for automated testing of Siebel). This, too, is a licensable component (per Application User). If you use Oracle’s Siebel Test Automation feature and have QA engineers or a test system using it, you might need to license that. Many customers use third-party testing tools instead, but it’s worth noting if you plan to use Siebel’s built-in test automation.
• Siebel Web Channel / Self-Service: If you deploy the Siebel Web Channel (for building self-service portals), you might need a certain number of base licenses and at least one Tools license as prerequisites. Oracle documentation indicates, for example, that using Siebel Web Channel requires, at minimum, one Siebel Tools user license and 100 Siebel Base users (this is likely an example requirement). The idea is that a company should already own Siebel and have some user base to extend it via Web Channel.
• Integration/Middleware Components: Some Siebel integrations (like Oracle Policy Automation connectors or Enterprise Application Integration (EAI) connectors) might come with Siebel or require separate licenses. For instance, Siebel comes with some standard connector modules, but if you use Oracle Policy Automation with Siebel (for guided interviews or decision support), that OPA component might have its license (often, Siebel bundles a restricted-use license for OPA if used only with Siebel).
• Database and Middleware: Not exactly “Siebel component” licenses, but remember you need to license the Oracle Database (or whichever database you use) and potentially Oracle WebLogic server if you use it for Siebel (WebLogic basic license is included with Siebel for the Siebel web server component as far as Oracle policy states, but the database is not included).

To answer the question directly, Siebel Tools requires a license for each tool user. Other components, like test automation or specialized connectors, may also require licenses. Always check the price list or Siebel licensing guide for these non-end-user components in your architecture. In many cases, they are licensed by user or by installation.

Failing to license developers/testers can be an oversight—include those in your count for compliance. For example, if you were audited, Oracle would likely ask, “How many people are using Siebel Tools?” and expect you to have that many Tool licenses.

External and Partner User Licensing

How are external customer self-service users licensed in Siebel?

When you expose Siebel functionality directly to your customers (end consumers or clients of your company) via a self-service web portal (often called Siebel eService or Siebel Customer Portal), licensing shifts from internal user metrics to external metrics.

Key points for customer self-service licensing:

• External User Metric: For customers, historically, Siebel offered the Concurrent User metric, and now the Registered User metric (for named customers) or processor licensing for large populations. The idea is that you should not use an internal Application User license for a customer. Oracle’s policies distinguish that Concurrent User shall only be customers or prospects, not employees. Concurrent User was a legacy metric where you estimated the maximum simultaneous customer logins. Oracle nowadays prefers other approaches (concurrent user metric is legacy and no longer sold in most cases).
• Registered User for Customers: If you have a relatively defined number of customer users (like a portal for, say, 5,000 known customers/suppliers), Oracle may license those as Registered Users (just as with partners). The definition of Registered User includes customers as well as partners. So, you’d need a license for each customer with a login. This works if the number of customers with access is limited or if you only allow certain customers into the system.
• Anonymous or Mass Consumer Access: If your Siebel is exposed to potentially tens of thousands or millions of consumers (for example, a telco allowing any customer to log cases or check bills), counting each named customer user is impractical. In such scenarios, Processor licensing is often the solution. You license the Siebel Customer Portal or eService application by server processors to allow unlimited customer users. It’s more costly per server, but it covers all users. This avoids tracking every individual user in terms of licensing.
• Concurrent User (legacy): Some older Siebel contracts used “Concurrent Customer User” – e.g., you might have 100 concurrent user licenses, meaning up to 100 customers can be on the system at a time. However, Oracle’s current stance is that if you exceed any such limit, you must convert to Named User/Registered User or Processor licenses. They generally don’t sell new concurrent licenses now. So new licensing would count each customer (registered) or go processor.
• Example: You operate an online support portal for customers. You have ~2000 customers who might use it, but at peak, maybe 200 concurrently. Options:
  • You could license 2000 Registered Users (so each customer that could log in is covered).
  • Or license the portal by, say, 4 Processors on the server to cover unlimited usage (this could be more straightforward if the user base might grow).
  • If you had an old 100 concurrent user license and your usage grew to 120 concurrent, Oracle would require you to migrate that to the new model (likely buying either 120+ Registered Users or the processors) because you exceeded the legacy grant.
• Cost consideration: External user licenses are often more expensive per user than internal ones (since Oracle anticipates fewer of them or more value from external use). Processor licensing for external-facing modules is also priced with that in mind.

In summary, for customer self-service portals, plan on either licensing named external users (Registered Users) if the community is contained or licensing by Processor if it’s a broad consumer-facing system.

Do not let customers use the system under your internal licenses—that’s against policy and a common compliance issue. Always ensure an external user is accounted for under an appropriate external metric. It’s wise to discuss your specific use case with Oracle; they may propose an optimal licensing approach (for instance, sometimes a combination: a certain number of external user licenses for power users and a processor license for the rest).

How are partner users licensed differently from employees in Siebel?

Partner users (external) are licensed differently than internal employees due to their external status. We covered Siebel PRM licensing earlier; here, we’ll emphasize the differences between an external partner user and an internal user:

• Metric Difference: Internal employees sometimes use the Application User metric (or Named User Plus), whereas partners must use an external metric. For Siebel, that is a Registered User (a named external user license). In older terms, partners could also be covered by concurrent user licenses (when those existed) or by a partner-specific metric. The key is that you cannot use an internal user license for a partner or vice versa – the contracts forbid it.
• Pricing: External user licenses (like those for partners) typically cost more per user than internal licenses. Oracle does this because external licenses might cover revenue-generating activities, and often, the numbers are smaller (or if larger, they expect you to use a processor). Internal licenses are cheaper per user because you need many for a whole workforce.
• Usage Restrictions: An employee license allows using Siebel for your internal business. A partner (Registered User) license allows that partner to use the system but only for that partner’s business with you, not for them to service other clients. The license terms often note that the software can’t be used for the operations of a third party beyond what’s authorized. In simpler terms, partner users can access your Siebel to do things like register deals, but they are not allowed to use your Siebel environment as a general CRM for their unrelated business.
• Counting: You must count all partner individuals who will access. You typically know your internal users from Active Directory or HR records. For partners, you might have to coordinate with each partner organization to know how many of their staff have accounts. Be careful: if a partner shares one login among 5 people (to try to save licenses), that’s not allowed under the license agreement (one user license = one person, not a shared account).
• Partner Company vs Individual: Oracle’s definitions include a “Partner Organization” concept (for marketing analytics) and a “Partner Company” metric (an older style of licensing by company), but the prevalent method now is per individual user. If you have many partner companies, each with few users, it’s straightforward: just count the users. If you have a scenario like a partner company with 100 users, you must license all 100 if they all need access.
• Internal Users Managing Partners: Remember that your employees who manage the partner relationships use Siebel, too (through partner manager screens), and thus need internal user licenses (Application User). This is not an external license; they are just normal users.

Employees and partners are licensed using different user categories to reflect their different relationships to your business. Partners = Registered User metric (external license); Employees = Application User metric (internal license).

Make sure to segregate these in your license count. In an audit, Oracle will likely ask for a list of Siebel users and their classifications (employee vs. partner vs. customer) and verify that you have the appropriate license types for each category.

Many compliance issues arise from companies giving partners or customers access under cheaper internal licenses, which is not compliant. Always match user type to the correct license type.

Do I need to license non-production (development and test) environments for Siebel?

Yes. Oracle requires all environments where the software is installed and used be properly licensed, including development, test, QA, and disaster recovery environments. There is often confusion on this point, so important clarifications:

• No free ride for non-prod: Using Siebel in a development or test environment is still considered use of the software and thus requires a license. Oracle’s licensing policies state that each environment must be fully licensed, separate from production. No blanket rule says, “if it’s not production, you don’t need a license.” Each installation must have a corresponding license entitlement.
• How to license dev/test: Generally, you license dev/test users like production users. Suppose your Siebel licenses are user-based and your developers or testers are already counted as Siebel users. In that case, you may not need additional licenses for them – provided they are the only ones using those environments. For example, if the same 10 licensed users in production also access the test system, you’re not doubling the user count; those 10 licenses cover their use in any environment. However, if you have additional users who only use the test system (say, testers who don’t have production access), they also need licenses.
• Server-based licensing in test: If Processor licenses you in production, your test servers must also be licensed by Processor. There is no concept of “using prod licenses for test” in Oracle’s view – you’d also need to purchase licenses to cover the test server cores. (One exception: Oracle sometimes allows using a backup or DR server without additional license if it’s cold standby or used <10 days a year, etc., but that’s for disaster recovery. For active dev/test, those are active use.)
• Oracle Technet License (OTN) confusion: Oracle provides software for download under a Development license (OTN license), free for development and prototyping only, not for proper internal testing or staging. That does not cover a full test environment used for internal projects. So you cannot rely on OTN free licenses for a long-running Siebel test instance that multiple users access, which would violate the terms (OTN is more for a developer individually trying things out, not company-wide testing).
• License segregation: In practice, many companies don’t purchase separate “test licenses” – they simply ensure they have enough licenses to cover the total named users across all environments. You’re covered for user licenses if the same users go across environments. For processor licenses, some companies license only production by processors and use Named User Plus licenses for non-prod where user counts are limited. However, mixing metrics can be tricky (see next question).
• Audit risk: Oracle’s audits often check if you have unlicensed installations. If they find a Siebel test environment and see that it’s running on a server and users are accessing it, they will expect those users to be licensed. If you assumed your production license covers it implicitly, that could be flagged as a shortfall. Oracle’s stance: “Must license separately from production” for dev/test.

The bottom line is to include your dev/test environments in your licensing count. Either allocate some of your existing licenses to cover those (ensuring named users match up), or formally purchase additional licenses if, for example, you have a separate team of testers or a separate server that isn’t covered.

Some organizations negotiate discounted license fees for non-production environments, but that would be a special arrangement (there’s no official discount; it’s at Oracle’s discretion). Always clarify in your contract if non-prod usage is covered. Absent that, assume every environment must be fully licensed to be safe.

Can I mix different licensing metrics (user vs processor) for the same Siebel deployment?

Mixing metrics in a single Siebel deployment is generally not recommended and can be legally complex. Oracle expects you to choose one primary metric for a product or component.

However, there are a couple of scenarios to consider:

• Different modules, different metrics: It is possible to license different Siebel modules with different metrics. For example, you might license Siebel CRM Base and Sales modules by Application User (for your employees), but license a Siebel Customer Portal by Processor (to cover unlimited customers). This is a form of mixing, but it’s done module by module. This can be compliant as long as the metric chosen fully covers each module’s usage. Oracle allows, for instance, internal modules on user metrics and external modules on processor metrics since they are distinct licenses.
• Same module, two metrics (not allowed): You generally cannot license the same product in the same environment partly with users and partly with processors. For example, you shouldn’t attempt to cover some of your Siebel Sales users with Named User licenses and then say, “Additional users are covered by a processor license on the same instance.” Oracle’s rules for Named User Plus per processor minimums implicitly discourage mixing – if you try to mix, you must still meet the minimum NUP for the processors used. Essentially, if you have a processor license on a system, Oracle considers that it covers all usage, so having some users counted separately doesn’t reduce the processor requirement.
• Conversion triggers: Sometimes, a mix occurs during a transition. You might switch to processor licensing if you have 100 user licenses and suddenly need to add many more users. Oracle would typically have you migrate entirely to processors for that module (potentially giving credit for your existing user licenses). Running both side by side is unusual because you could risk undercounting. Oracle’s policy is often “choose one metric per product in an environment.”
• Audit perspective: Oracle will look at your entitlements and deployments during an audit. If they see you have user and processor licenses for the same application deployment, they might question it. Usually, one set would cover all usage. For instance, if you bought processor licenses for Siebel CRM, those allow unlimited users. So technically, you wouldn’t need any Named User licenses anymore for that deployment (you might repurpose them elsewhere if allowed, or they’re just excess).
• Best Practice: Pick the metric that covers your scenario and stick with it for that module. If you have distinct user populations (internal vs external), it’s fine to license them differently because they use different Siebel modules/portals. Just keep clear boundaries. Document which licenses cover which user groups.
• Example scenario: You have 500 employee users and unknown customer users. You decide to license employee usage by Named User Plus (500 NUP licenses for Siebel CRM). For the customer-facing portal, you buy 2 Processor licenses for that portal component. This is acceptable because the customer portal is a module different from the internal CRM. You wouldn’t “mix” for the same functionality – each portion is separately licensed appropriately.

In summary, avoid mixing metrics for the same component, but you can use different metrics for different components as needed. If in doubt, consult Oracle or a licensing expert when designing a solution requiring both metrics. They can confirm the acceptable approach. Improperly mixing metrics can lead to compliance issues – for example, giving external users access with only internal user licenses is not allowed (that’s mixing user populations with the wrong metric). The safe route is one metric per module/environment, so it’s unambiguous what covers what.

Is the old Concurrent User licensing model still available for Siebel CRM?

Concurrent User licensing for Siebel is considered a legacy model. Oracle no longer sells Siebel licenses for new purchases on a concurrent user basis.

Here’s the background and current state:

• Legacy of Concurrent Users: In the days of Siebel Systems and early Oracle, certain Siebel modules (especially external-facing ones like customer self-service or partner applications) were offered on a Concurrent User metric. For example, you could have X concurrent customer users. A concurrent license means you can create many user accounts, but only that number can be logged in simultaneously.
• Oracle’s move away from concurrency: Oracle generally moved away from concurrent user licensing in favor of Named User (or Registered User) and Processor metrics. Concurrent models are harder to audit, and Oracle prefers the certainty of named licenses. Oracle’s policy requires migrating to current metrics if a customer exceeds their concurrent entitlement, even by one user.
• If you have existing concurrent licenses, you can usually continue to use them under grandfathered rights as long as you stay within the limits. But you need to be extremely careful not to exceed the concurrent count at any time. If you do, you’re technically non-compliant, and Oracle could insist you convert to named user licenses for everyone (which could be a significant cost increase).
• Migration: If concurrent licensing isn’t sufficient (e.g., user counts grew), you might proactively negotiate a migration to Named User Plus or Processor. Oracle often provides a conversion ratio or credit for existing licenses when migrating to new metrics (this would be part of a licensing discussion or during a renewals true-up).
• No new sales on concurrent: If you try to buy new Siebel licenses, Oracle will quote you per user or processor, not per concurrent user. So, any expansion of usage will effectively push you into the modern metrics.
• Example: Suppose you have 50 Concurrent Partner User licenses from a very old contract. Those allow, say, 50 partners to be on at once. If your partner program grows and now maybe 60 want to use concurrently, you cannot buy 10 more concurrent licenses (Oracle won’t sell them). Instead, you’d likely have to migrate to 60 (or more) Registered User licenses. If you failed to notice the overage and got audited, Oracle’s finding would be that you must purchase 60 Registered User licenses (and terminate concurrent ones) because you exceeded the old allowance.

In summary, Siebel’s Concurrent User metric is essentially retired. You’ll use Named/Registered User or Processor metrics if you’re a new customer. Treat those concurrent limits as hard caps if you’re an old customer with a legacy contract. Oracle’s current licensing rules require migration to the newer metrics if those caps are exceeded.

If feasible, it’s often wise to voluntarily transition to current metrics and simplify compliance management (concurrency can be tricky to monitor, and any mistake can be costly).

Is Siebel able to provide any special license bundles or enterprise agreements?

Oracle does offer special licensing arrangements for large deployments, though they are not specific to Siebel alone. However, it can include Siebel as part of a broader deal. Two notable concepts are Custom Application Suite (CAS) licensing and Enterprise (or Unlimited) licenses:

• Custom Application Suite (CAS): This is a bundle licensing approach where multiple Oracle applications (e.g., Siebel plus maybe other Oracle apps) are bundled under a single custom metric, often called a Custom Suite User. In the context of Siebel, Oracle could bundle several Siebel modules together so that one user license covers all of them. For example, under CAS licensing, a user might be licensed to use Siebel Base, Siebel Sales, and Siebel Service collectively as a suite instead of buying each separately. The price would be set based on that bundle. This is typically negotiated for clients who use many modules extensively and want simplicity. CAS is not a standard publicly available metric; it’s a negotiated agreement.
• Enterprise Licensing / Unlimited License Agreement (ULA): Oracle sometimes allows an enterprise license for Siebel, meaning you pay a large fee to cover unlimited use within a scope. An Unlimited License Agreement might cover Siebel CRM (perhaps along with other Oracle products) for your whole enterprise for some time, after which you either lock in the usage or renew. Enterprise licensing lets a customer deploy Siebel to any number of users or servers without counting during the agreement term. This is suitable for large organizations where counting every user is impractical or when planning to roll out Siebel to a large population (e.g., all employees) and want cost predictability. After the ULA period, you typically certify your usage, which becomes your perpetual limit.
• Siebel Employee/Customer/Partner bundle: In some price lists, Oracle has packaged Siebel applications by user type (Employee apps vs Customer vs Partner apps). They sometimes create packages like a “Siebel CRM Enterprise License” with several modules for a fixed number of users. These are more like marketing bundles than formal metrics. However, if you foresee using many parts of Siebel (Sales, Service, Marketing, etc.), ask Oracle if there’s a bundled pricing option rather than line-item pricing for each module.
• Negotiation: These special arrangements usually result from direct negotiations with Oracle. They will assess your overall usage, and if it’s large, they might propose a ULA or CAS for a fixed fee. This can simplify compliance (because you don’t have to track each user/module individually during the agreement), but it requires commitment (you pay a big sum regardless of actual usage).
• Example scenario for ULA: A global enterprise wants to deploy Siebel CRM to 20,000 employees across various divisions (some will use Sales, some Service, etc.), and also open self-service portals to millions of customers. Instead of counting exact users and buying a mix of licenses, they negotiate an enterprise license: for a set price, they get unlimited Siebel usage for 3 years. This covers all employees and all customers. After 3 years, they certify that 22,000 employees and 5 million customers were using it, and those become the perpetual entitlements. This way, they avoided the risk of underestimating licenses during rollout.
• Be mindful: Enterprise deals don’t mean “ignore all rules” – they come with their terms and need careful negotiation on what’s included. If you have a Siebel ULA, ensure it covers all the modules you plan to use (list them explicitly). Also, clarify if it includes Siebel Tools, etc., or if those are separate.

In summary, while the standard Siebel licensing is module-by-module, user-or-processor, Oracle can provide custom bundling or unlimited agreements for Siebel in large environments. These can simplify licensing management.

Companies should weigh the cost vs. benefit: if you expect growth or have a complex multi-module deployment, these deals might save money and headaches. Always get any such arrangement in writing as an amendment to your Oracle contract, with clear definitions of what it covers.

Best Practices for Siebel License Management

What are the consequences of not being properly licensed on Siebel?

Using Siebel without sufficient licenses (i.e., being “under-licensed” or otherwise out of compliance) can lead to serious consequences:

• License Audit and Fees: Oracle has a License Management Services (LMS) team to audit your deployment. Suppose an audit finds you’ve been using more licenses than you purchased. In that case, Oracle will require you to purchase the necessary licenses retroactively, often at list price, plus backdated support fees for the period of unlicensed use. This can result in a huge, unexpected bill.
• Penalty or Compliance Payments: In some cases, if the gap is severe or appears willful, Oracle might impose penalties or require a settlement fee on top of just buying the licenses. At a minimum, you’ll have to fund the shortfall promptly. No company wants an unplanned expense because of an audit.
• Termination of Support or License: In extreme cases, violation of license terms could technically give Oracle the right to terminate your license or support agreement (though this is rare; typically, they prefer to bring you into compliance through purchase). But theoretically, non-compliance is a breach of contract.
• Operational Risk: If you are found non-compliant, until you resolve it, you may be restricted from getting new versions or support. Oracle could withhold patches or technical support for your Siebel system if you’re out of compliance, which could hurt your operations.
• Legal Risk: Oracle’s license agreements are legal contracts. Failure to comply could escalate to legal disputes. It’s better and far cheaper to remain compliant than to fight a legal battle or pay settlements.
• Examples of non-compliance:
  • A common one is overusing user licenses – e.g., you bought 100 licenses but had 120 active user accounts. This triggers compliance issues.
  • Another example is using Siebel modules you haven’t licensed: perhaps a technical team enabled a Siebel module (since Siebel software is usually technically unlocked) that you didn’t purchase, and people started using it. That’s unlicensed use and would be flagged.
  • If external users (partners/customers) are allowed on the system without the proper external user licenses, Oracle will classify them as unlicensed users, which could be very expensive to correct after the fact.
• Reputation and Procurement Impact: Being found non-compliant can strain your relationship with Oracle. It may reduce your negotiation leverage and paint your organization as a higher risk, possibly affecting discounts on future deals.

The consequence is primarily financial pain. Many companies have had to pay significant sums due to Siebel (and other Oracle products) license audits because they were not actively managing their license usage. It’s not worth the risk.

Ensuring that every Siebel user is accounted for and every module in use is licensed will save you from these compliance nightmares. Oracle’s audit teams routinely check Siebel deployments, so assume you could be audited anytime and manage your licenses accordingly.

What are some best practices for staying compliant with Siebel licensing?

Proactively managing Siebel licenses will help avoid the issues mentioned. Key best practices include:

• Maintain an Accurate User Inventory: Regularly review who has access to Siebel. Ensure there are no active user accounts beyond your licensed count. When employees leave or change roles, promptly end-date or disable their Siebel accounts. A common compliance issue is companies not removing access for departed users, leading to more named users than licenses. Have a process with HR to notify IT of departures so you can free up those licenses.
• Align Licenses with Roles/Modules: Document which users are using which Siebel modules. Ensure that if, for example, a user needs the Siebel Marketing module, that user is included in the marketing license count. Avoid giving access to a module to someone who isn’t licensed for it. This might involve carefully setting up Siebel responsibilities to control access. (If a user tries to access an unlicensed module, license keys should normally prevent it. Siebel license keys can restrict access to modules you didn’t buy, but admin oversight is still important.)
• Monitor Customizations: Be cautious with customizations. If you create custom views that use the underlying functionality of an unlicensed module, you can inadvertently become non-compliant. For example, suppose you didn’t license the Siebel Contracts module, but a custom screen effectively replicates it or uses its data tables. In that case, an auditor might consider the use of the Siebel Contracts module. The best practice is to only use features of modules you have licensed. Map your configurations to the proper licensing.
• Periodic Internal Audits: Do your own “true-ups” at least annually (if not more often). Compare actual user counts and usage to what you have purchased. Oracle even provides LMS scripts and tools to help identify usage – you can run these internally to see if you’d pass an audit. Check for any modules that may be enabled or any interfaces (like a test integration user) that might count as a user.
• License Management Team: Identify someone in your organization (or a team) responsible for software asset management (SAM), specifically for Oracle/Siebel. They should maintain entitlement documentation (the Oracle ordering documents, proof of licenses) and track deployments. They can use SAM tools like Flexera, Snow, etc., to monitor Siebel usage.
• Training and Awareness: Make sure administrators and developers know the licensing implications of their work. For instance, if an admin adds 10 new users to the system, they should know that means they need 10 more licenses (unless spares exist). Or if a developer wants to enable a certain module, they should confirm if it’s licensed. This awareness prevents accidental compliance slips.
• Keep Proof of Retirement: When you retire a Siebel module or reduce user count (say after an organizational change), keep records of when and how access was removed. In an audit, you want to show that any accounts present in historical data are deactivated and shouldn’t count. Siebel admin tools allow you to end-date users – use that feature to mark inactive users.
• Stay Current on Support: While not directly a compliance issue, keeping your support active ensures access to Oracle’s assistance. In case of any ambiguity, you can ask Oracle to clarify your license position. Also, if you ever need to buy additional licenses, it’s easier to do it as an uptick under support rather than reinstalling lapsed support (which incurs penalties).

By following these best practices, you create a defensible position in case of an audit and, more importantly, you avoid overspending. Many organizations find after a review that they had more licenses than needed (paying support on shelfware) or vice versa. Regular reviews can identify and correct that, optimizing cost while staying compliant. Compliance is not a one-time task but an ongoing part of Siebel administration.

How can I track and audit Siebel user licenses effectively?

Effective tracking and auditing of Siebel licenses can be achieved with a combination of Siebel’s internal data and external tools/processes:

• Use Siebel Administrative Reports: Siebel provides administrative screens or reports (depending on the version) to list all user accounts and their last login time. You can regularly export a list of all active users. By comparing this with your licensed count, you can spot discrepancies. Also, track which responsibilities or views each user has – that indicates which modules they use.
• Oracle LMS Scripts: Oracle’s License Management Services group has diagnostic scripts for Siebel that can enumerate usage. You can request these from Oracle or find them on Oracle support. Running these internally (especially before a true audit happens) will show what Oracle would see, such as the number of users, modules enabled, etc. It’s a proactive way to catch issues early.
• Software Asset Management (SAM) Tools: Tools like Flexera, Snow License Manager, or ServiceNow’s SAM module can be configured to track Siebel usage. They may use connectors or agents to pull user counts or even monitor who’s logging in. At minimum, you can use them to maintain a record of entitlements and compare to user lists. Some SAM tools might not have an out-of-the-box Siebel connector (Siebel is less common than Windows or Oracle DB), but you can often manage it via data imports.
• Manual Audits: Periodically, have your licensing or IT asset management team perform a manual audit:
  • Pull the list of Siebel users from the database (e.g., via a SQL query on the S_USER table for active users).
  • Verify each user’s status (still with company? correct license category?).
  • Check that no generic accounts are being used improperly (generic or shared accounts can be a compliance red flag unless each is licensed and only one person uses it).
  • Document the count of users per module.
• Module Usage Tracking: If possible, track the usage of certain features to ensure you’re not inadvertently using an unlicensed module. Siebel’s license keys typically prevent using unlicensed modules, but this can blur in highly customized systems. Keep an inventory of which Siebel modules (by module SKU or name) you have purchased and cross-check with what’s configured in Siebel. If you have a module enabled that’s not on your purchase list, that’s a problem to resolve immediately.
• Integrations and API Usage: Count any external systems or integrations that access Siebel. Each such integration might use a dedicated Siebel user account (which counts as a user license). Also, if an external system is pulling a lot of data (like a data warehouse connector), check if there are any special metrics (e.g., Oracle might consider some integrations under a “connector” license). Auditing integrations ensures you didn’t miss a licensing component.
• Track License Entitlements: Maintain a centralized spreadsheet or database of all Siebel licenses owned, including the type (module), metric, quantity, and Oracle contract details. When performing an internal audit, refer to this to determine your entitlement limits.
• Regular Reconciliation: Compare the current usage vs entitlements quarterly or at least annually. If you are close to the limit in any area (say you have 95 of 100 licensed users consumed), you should either stop adding users or budget for more licenses.
• Engage Oracle LMS for a Health Check: Outside of formal audits, you can sometimes ask Oracle to do a review (though only do this if you are fairly confident in compliance because if they find issues, you’ll be expected to address them). Alternatively, hire a third-party Oracle licensing specialist to do a mock-audit. They will check your Siebel environment similarly to Oracle and report any gaps, letting you fix them before Oracle proper comes knocking.

By implementing these tracking methods, you establish a continuous internal audit mechanism. The goal is no surprise. If Oracle comes in, you should already know what they will find. Many SAM professionals aim to have a dashboard: at any time, you can see “we have X Siebel Sales users active vs Y purchased” and so on. Compliance becomes routine rather than a fire drill when that is under control.

How can I optimize or reduce our Siebel licensing costs?

Optimizing Siebel licensing costs involves ensuring you’re not over-licensed (paying for more than you need) and choosing the most cost-effective licensing model for your usage.

Here are the strategies:

• Right-size User Licenses: Regularly remove or reassign licenses from users without access. As mentioned, companies often find they have some inactive users still counted. By end-dating those users, you might be able to reduce the number of licenses you maintain (for example, if you originally purchased licenses for 300 users but now only 250 actively use Siebel, you might consider reducing your support renewal count accordingly at the next opportunity or reallocating those to new users instead of buying more).
• Module Usage Review: Check if you’re paying for modules that are not heavily used. For instance, if you bought Siebel Marketing but only ran one campaign a year, maybe you could retire that module and use a simpler approach, saving on support costs. Or, if you have a module like Siebel Contracts licensed but your business no longer uses that functionality, consider dropping its support or migrating off it.
• Consolidate Environments: Licensing cost often scales with several environments, especially if they are processor-based. If you have multiple production instances of Siebel (maybe due to regional setups or different business units), see if they can be consolidated to require fewer server licenses. However, be mindful of performance vs. licensing trade-offs.
• Leverage Volume & Negotiation: If you anticipate growth or need additional licenses, try to purchase in bulk during a single negotiation to get better discounts rather than piecemeal. Oracle’s sales teams are often willing to give a discount if you commit to a larger purchase (especially at the end of the quarter/year). If you know you’ll add 50 users over the next year, it might be cheaper to buy them all now in one go at a discount rather than 10 each quarter at lesser discounts.
• Evaluate Metrics: Consider if Named User vs Processor is cheaper for your situation. A Named User (Application User) is usually cheaper for internal users because you have a finite number of employees. But for external, do the math: e.g., if you have 1,000 external users, and a processor license costs the equivalent of 500 users, it might be cheaper to buy the 1000 named external users rather than a processor. Conversely, if you have 50,000 external users, processor licensing will likely be far more cost-effective. Revisiting your metric choice as the user count changes can save money. You can migrate from one metric to another by purchasing the new and terminating the old (with Oracle’s agreement).
• Terminating Unused Support: If you have licenses you are sure you will never use again, you might consider terminating those licenses to stop paying annual support. Oracle’s support is ~22% of the yearly license cost, so unused licenses incur ongoing costs. Be careful: if there’s any chance of needing them, you’d have to buy new licenses at full price if you drop them. For example, if you once licensed an industry base you no longer need, you could drop it to save support dollars.
• Check for Bundles or Promotions: Oracle occasionally offers promotions or new bundles (especially when transitioning to newer versions or cloud offerings). Even if you plan to stay on-premises, Oracle might offer a deal like “if you upgrade to Siebel 21 and also have Oracle cloud something, we bundle at lower cost.” Stay informed on Oracle’s licensing programs; sometimes, aligning with their sales initiatives can lead to a favorable deal.
• ULAs or Enterprise Licenses: If you foresee a large expansion, a ULA (Unlimited License Agreement), as discussed, can sometimes save cost versus incremental purchases, especially when factoring in discounts and simplification. Just be cautious to size it right.
• Third-Party Support: This is a more drastic cost-saving measure. After stabilizing on a Siebel version, some companies opt to drop Oracle support and use third-party support providers (like Rimini Street) to save the 22% annual maintenance fee. This can cut costs significantly, but you won’t get official Oracle updates or support. It’s only viable if you don’t plan to upgrade (Siebel is in continuous innovation now, so upgrades are mostly cumulative patches). It won’t reduce license count cost (that’s sunk), but it reduces yearly spending.
• License Reassignment: Oracle’s user licenses are typically fixed to individuals (not floating), but you can reassign them when someone leaves (after a certain time gap to avoid abuse, usually 30 days). So, always reuse licenses – if 10 people leave, those 10 licenses can be allocated to 10 new hires without buying more. Manage this like a pool: if you have turnover, you might not need to buy new licenses for replacements if you already have them.
• Monitor Oracle’s Licensing Policy Changes: Oracle occasionally adjusts licensing rules (for example, core factors, minimums, etc.). Staying up to date can reveal new ways to optimize. For instance, if Oracle reduced the core factor for certain processors, the cost of processor licenses might drop, making that route more attractive.

Good governance is the foundation of cost optimization in all cases. Knowing what you have and use allows you to make informed decisions to save money. Many of the best practices for compliance (user tracking, etc.) also aid in cost optimization because they highlight unused licenses or over-provisioning.

As one licensing expert says, “Only pay for what you use, but ensure you pay for all that you use.” Optimize what you need and stay compliant with that amount—that’s the sweet spot.

How should I manage Siebel licenses when employees leave or change roles?

Managing the joiners, movers, and leavers is crucial to compliance and cost optimization. When an employee’s status changes:

• When an employee leaves, end-date or disable their Siebel user account immediately or as soon as possible. In Siebel, you can set an end date on the user record or mark them inactive. This ensures they no longer count as a current “authorized user” requiring a license. Oracle’s Application User definition counts anyone authorized, even if not actively using, so it’s important to remove that authorization promptly when it’s no longer needed. Additionally, document the date of deactivation. In an audit, if Oracle sees 500 user records and claims only 450 need licenses, you can show that 50 are end-dated (and thus not authorized currently) as evidence.
  • You should also reassign any licenses in your internal records. Essentially, you now have a free license to be given to someone else.
• When an employee changes roles: If they move to a role that no longer needs Siebel, treat it like a departure from the Siebel perspective – remove their access. If they move into a role that uses Siebel differently, adjust their access and ensure sufficient licensing. For instance, a sales rep (with a Sales module license) becomes a customer service agent. You should revoke their Sales responsibility (you could potentially reduce one Sales user license if total sales users drop) and give them Service responsibilities (and ensure you have a Service license). As long as you have equal swap, you’re fine, but track it.
• License Reallocation: Oracle licenses (perpetual) are tied to your organization, and you can reassign them to new individuals as needed. Oracle’s only rule is generally that you cannot frequently rotate a single license among multiple people to avoid buying licenses (they frown on monthly rotation – typically a user license can be reassigned when someone leaves permanently or no longer needs it, not back-and-forth). So, as people leave, you assign their “slot” to a new hire who needs Siebel. This was why you didn’t buy a new license for the new person.
• Keep records of changes: Maintain a log or spreadsheet of user account changes—when a user is deactivated and which license type is freed up. Also record when a new user is added and which license is consumed. This helps in audits and also helps internally to justify the number of licenses you maintain.
• Regular HR reconciliation: At intervals, reconcile the list of active Siebel users with an HR roster of current employees. This will catch if someone left but their Siebel account wasn’t closed. It’s a good double-check against mistakes. Also, sometimes contractors or temp staff might have Siebel access – ensure those are turned off when their contract ends.
• External users management: Similarly, for partners or customers who had access and no longer should (partner no longer with program, etc.), revoke those to free up those external user licenses for others. Have your channel team inform IT when a partner user should be removed.
• Enforcement via Identity Management: If possible, integrate Siebel user management with an identity/access management system or corporate SSO. Then, when you disable a user in the central directory upon leaving, it automatically disables access to Siebel. This reduces the manual oversight needed. However, still verify in Siebel that the account is end-dated since auditors will look at Siebel’s user records.
• Forecast license needs: If a department is expanding and hiring 20 new Siebel users next quarter, plan that into your license count. You might reallocate from leaving employees, but you might need to purchase more if a net new is expected. Early planning avoids rush purchases at possibly higher prices.

Effectively, treat Siebel licenses as seats: when someone leaves, their seat becomes available to fill. Don’t let seats sit occupied by ghosts – clear them so new folks can use them or so you’re not paying for idle capacity.

This housekeeping can save a lot of money (by not overbuying) and keeps you compliant by aligning the active user list with the licensed count. Oracle auditors often specifically look for evidence of a process around end-dating users because it indicates good license hygiene.

Is there a minimum number of licenses I must purchase for Siebel modules or metrics?

Yes, Oracle often has minimum license requirements for certain products or metrics. These minimums ensure that even a small deployment meets Oracle’s base revenue threshold.

Here are some instances:

• Per-Processor Minimums: If you choose Named User Plus licensing in an environment that processors can license, Oracle requires a minimum number of users per processor. For example, if Siebel were hypothetically treated like their database, they might say 25 Named Users per processor core. We saw an example in the Siebel price list: Oracle Application Management Suite for Siebel had a minimum of 200 Named User Plus if using that metric. This means that even if you only had 10 admins, Oracle would sell you at least 200 NUP licenses for that product.
• Module-Specific Minimums: Certain Siebel modules have a minimum number of user licenses you must buy. For instance, the price list snippet shows Siebel Sales Approvals Connector for Sales Managers had “Minimum 25” in the user count (implying you need to buy at least 25 licenses of that connector if you buy it). Siebel

Is there a minimum number of licenses I must purchase for certain Siebel modules or metrics?

Yes. Oracle often enforces minimum license quantities for specific Siebel modules or licensing metrics. This means that even if your usage is small, you must buy a minimum number of licenses to meet Oracle’s policy.

Some examples include:

• Siebel CRM Base: At least one base license is required (practically, one per user, but obviously, you can’t have zero). In general, every Siebel deployment needs at least the base for each user. There isn’t a fixed number like “minimum 100” for the base; it’s just tied to your number of users (each user = 1 base).
• Industry Base Modules: If you opt for an industry-specific base (like Siebel Financial Services Base), typically all users must have it, which inherently sets a “minimum equal to your user count”—not a fixed numeric minimum but a structural requirement (you can’t have only some users with an industry base if you choose that route—either all or none as per Oracle rules).
• Named User Plus per Processor Minimum: As noted, if licensing by Named User Plus, Oracle requires a certain minimum number of NUP licenses per processor for many products. For Oracle databases, it’s 25 NUP per core; for Siebel-related software, it could vary. However, Oracle’s price list shows Oracle Application Management Suite for Siebel requires a minimum of 200 Named User Plus licenses if you choose that metric. That implies that even if you had only 5 admins, you’d still have to buy 200 NUP licenses for that tool. Always check Oracle’s “minimums table” in the contract or price list for any product you license via NUP.
• Module Purchase Minimums: Some Siebel modules are sold in minimum bundle sizes. For instance:
  • Siebel Loyalty Engine Standard Edition might be sold in blocks of 100k members and require a minimum purchase of 5 blocks (meaning a minimum of 500k members licensed).
  • Siebel Warranty Claims or Loyalty Manager modules might have a minimum of, say, 2 or 10 users, depending on Oracle’s price list.
  • In the sales modules, Oracle Business Approvals Connector for Sales Managers noted “Minimum 25” licenses in some price listings (meaning you must buy at least 25 user licenses of that connector even if you have fewer managers).
  • The Siebel Web Channel (customer/partner web API) documentation suggests that you must have at least one Siebel Tools license and 100 Siebel Base users to use it—effectively a minimum prerequisite.
  • If a Field Service scheduling engine requires Field Resource licenses, Oracle might set a minimum number of field resources, like 40, for the scheduling engine product (a common minimum number seen for some field scheduling solutions).
• Processor License Minimum: Some Siebel components might have a minimum number of processor licenses. For example, if a module is priced per Processor, Oracle may say you must buy at least two or 4 processors. In the price list snippet, Oracle Application Management Suite for Siebel had a minimum of 4 processors if using the processor metric.
• Partner/User Portal Minimum: Partner or customer portals often require at least the same number of base licenses or some baseline to enable them. For example, Oracle might not sell you a partner portal for just one partner user; typically, you’d start with some reasonable minimum count.

When getting a quote, it’s important to check the “Licensing Metric Minimum” column or footnotes in Oracle’s price list or ask Oracle directly. They will usually ensure that any order meets those minimums. If you try to buy under the minimum, Oracle will bump it up.

In summary, yes, minimums apply. They can be:

• A fixed count (like minimum X users or Y processors for that product),
• Or proportional (like NUP per processor minimums).
• Or based on prerequisites (needing a base or a certain prior license count).

Always factor these into your budget. For instance, if you only have 3 partner users, but Oracle’s minimum for the partner portal is 10, you’ll pay for 10. Plan your licensing with these floors in mind to avoid surprises. Oracle’s documentation and the price list are your friends here—review the fine print for any module you plan to license so you know the minimum purchase requirement.

Do yo u want to know more about our Oracle Advisory Services?