Antennas on a telecom mast, in Arcsen colours

SitecoreAI for telecom websites: weekly offers, Arabic and self-care

A Gulf operator’s website changes every week: new prepaid and postpaid plans, device launches with pre-orders, Ramadan and National Day offers, business bundles, and every page in Arabic and English. On many sites those changes are still made page by page, and an offer that ended on Thursday can stay live until someone spots it.

The website is also only one part of the sale. Price, eligibility, stock and the order sit in the commerce and billing platforms, and signed-in customers manage their lines in self-care. On SitecoreAI (formerly XM Cloud, whose customers moved across automatically in November 2025), a telecom site works when two things are settled early: which system owns each piece of data, and how cleanly the site hands the customer on.

Decide which system owns what

Start with an ownership map that marketing, legal, IT and the owners of the shop and self-care all sign. This is the version we start from:

Content or data Owner and system of record What SitecoreAI holds How it reaches the page
Plan and device pages Marketing, in SitecoreAI Copy, images, comparison tables and FAQs, in Arabic and English Published to Experience Edge, rendered by the front end
Price, allowances, eligibility, stock The product catalogue in the commerce or billing platform The plan or device code Fetched by the front end when the page is built or requested, with a short cache
Offer terms and dates Marketing and legal, through workflow Versioned terms with start and end dates Published when each date starts
Stores Retail operations A page per store: address, hours, services From Experience Edge, with live status from the store system
Coverage The network team Page copy, disclaimers and the message shown when a check fails A finder that calls the coverage service
A customer’s lines, usage and bills Self-care Nothing Deep links into the app or portal after sign-in
Segments for offers CRM or billing Audience rules Evaluated when the page is requested

The second row settles most arguments. If prices are typed into the CMS, the page and the shop disagree the day a price changes. Keep the code in SitecoreAI and let the front end ask the catalogue for the live figures.

Plan and device pages that change every week

Model each plan and device as an item that carries its code. In Sitecore, a Shared field holds one value for every version in every language, and workflow and publishing restrictions do not apply to it. That suits a plan code. For a price or an offer line it would mean an edit that skips legal review and goes live in both languages at the next publish, so keep anything legal approves in versioned fields.

Page builder lets an editor schedule each version’s availability, with a start and an end date. Sitecore’s documentation adds the catch: you still have to publish the page or the site when each date starts for the right version to go live, and only one version of a page sits on Experience Edge at a time. Put the Thursday-midnight publish in the release calendar with a named owner, and check the live page after it runs.

Device launches have an easier tool. Since July 2026, embargo dates on assets in the legacy media library make published images available automatically at the scheduled time, wherever they are used. Upload and publish the launch photography early, and let the embargo release it.

Then agree how fast a change must appear. Experience Edge serves a static snapshot taken at publish time and its delivery API allows 80 requests per second, so the front end should serve cached pages and regenerate them after a publish, and Sitecore notes the site may update with a delay. Write that delay into the offer sign-off.

Rule of thumb: codes in Shared fields, words and terms in versioned fields, prices from the catalogue, and a named owner for every scheduled publish.

Offers by segment, and signed-in customers

Page variants are the native tool for segment offers. Each variant has an audience built from Sitecore’s condition types: time, date, device, geography (country, region or state), visit history, user interaction (the referrer or UTM that brought the visitor) and point of sale. A business campaign can land on a variant that leads with business bundles, and a visitor on a phone can see the eSIM offer first.

Plan within the limits. Each audience takes at most five conditions, a variant goes live only when it is published, and inline edits made in a variant also change the default page, so editors should assign content items to variants. The Page builder dashboard compares each variant with the original.

Signed-in customers need more care. Experience Edge does not vary its output by user or query string, so anything personal, such as a balance, a bill or a contract end date, belongs to self-care and its APIs. For offers to known segments, such as an upgrade for postpaid customers near the end of a contract, pass a segment flag from the CRM or billing system into Sitecore CDP and Personalize, and build the rule there: custom conditions built in Personalize appear in Page builder. Sitecore said XM Cloud customers moving to SitecoreAI would receive baseline entitlements for CDP and Personalize, with features rolling out in phases, so check what your tenant has. A segment flag tied to a signed-in customer is personal data, so legal decides which flags marketing may use.

Store finders, coverage checks and search

Store and coverage finders are front-end features with content around them. A store finder needs a page for each store in both languages, with address, opening hours and services, plus live status from the store system. A coverage checker calls the network team’s coverage service, and SitecoreAI holds the page copy, the legal disclaimer and the message shown when the service does not answer. Cache the store list in the front end: a finder that queries the delivery API on every keystroke can reach the 80 requests per second limit on a launch day, and a single request returns at most 1,000 entities.

For search, the same Sitecore announcement included baseline entitlements for Sitecore Search, and Content SDK 2.0, released in March 2026, added a search package for the front end. Index plan, device, store and help pages, and send account questions such as “my bill” to self-care. Then test Arabic: spelling variants, transliterations and English brand names typed in Arabic script. Our guide to Arabic-first Sitecore lists the checks.

Arabic, English and the handoff to the shop

Plan names are where bilingual sites drift. Add them to the Glossary and Localization section of the brand kit, which tells SitecoreAI how terms should be handled across languages when pages are translated, including terms that must stay unchanged. Give Arabic its own review step in workflow, and publish both languages together so an offer never goes live in one language only.

Every buy, upgrade and pay button is a handoff. The shop should receive the plan or device code, the campaign parameters and the language, and show the price the page showed. Self-care links should open the right screen after sign-in, in the same language. The app can share the content too: Experience Edge serves it through a GraphQL API, so the site and the app use one set of plan descriptions. Test the handoff as one path, from page to shop to payment to confirmation, in both languages and on a phone.

Where to start

  1. Count last quarter’s changes: how many plan, device and offer pages changed, who approved them, and how long each took in each language.
  2. Sign the ownership map with marketing, legal, IT and the owners of the shop and self-care, and settle where prices come from.
  3. Rebuild one plan family, such as postpaid, with codes in Shared fields, terms in versioned fields, scheduled versions and a publish calendar.
  4. Add one segment variant with a clear goal, and compare it with the default page over a full offer cycle.
  5. Run the Arabic parity checks before launch, on real phones.

Still on Sitecore XP? Build these patterns into the move: Arcsen Ascend is our migration route to SitecoreAI, and SitecoreAI vs XM Cloud explains what changes.

Running a telecom website on Sitecore? Start with our free Sitecore Health Check, which reviews your current estate. See how our Sitecore practice works with telecom and technology companies, or talk to our telecom team.

Frequently asked questions

Can SitecoreAI publish and expire offers on a schedule?

Partly. Editors can schedule when each page version is available, and Sitecore says you must still publish the page or site when each date starts. Media embargo dates, added in July 2026, release published images automatically at the scheduled time.

Should telecom prices live in SitecoreAI?

We advise against it. Keep the plan or device code in SitecoreAI and let the front end fetch price, allowances and stock from the catalogue, so the page and the shop show the same figures.

Can SitecoreAI personalize pages for signed-in customers?

Page variants use time, date, device, geography, visit, referrer or UTM, and point of sale. For customer segments, use Sitecore CDP and Personalize, whose custom conditions appear in Page builder. Balances, bills and other personal details stay in self-care.

How should a telecom site handle Arabic search?

Index plan, device, store and help pages in both languages, test real Arabic queries, spelling variants and transliterations before launch, and send account questions to self-care.

Sources