Service Names and Descriptions

Product Specifics / SAP BTP Services

Introduction

Service names need to follow branding guidelines and need to be approved by Brand Voice to guarantee brand conformity. This is regardless of the commercialization status of the service.

The BV approval process can take several weeks. To avoid longer waiting times (because of rejected proposals, clarifications, etc.), it is best to be prepared before approaching BV.

Getting Started

Process:

(Steps towards service name approval)

1. Check out the guidelines for service names (below) and decide on a service name with your Service Owner / User Assistance Developer. If you’d like a first review of your name, contact Anja Nicole Kretz.
2. Create a Brand Voice Naming Request. Add Hanna Salamon from OnePM and Anja Nicole Kretz from SAP BTP as (additional) reviewers. This way, we will be involved in the naming discussion with Brand Voice and marketing.
   
   (Steps after Brand Voice approval)
3. You will need a data sheet topic in the CMS for your newly branded service. For this you will need a short- and long description that complies with the guidelines for service names.
4. If applicable, update your marketplace tile and your service guide.

Guidelines

Branding for new service names:

• SAP solutions or applications that are available as a service, take on the SAP branding plus “service”. Where necessary, “for SAP BTP” can be added for clarity.
  Example: SAP Application Logging service for SAP BTP
• Third-party services that run on the platform, use “on SAP BTP”.
  Example: Apache Cassandra on SAP BTP
• Third-party services that provide functionality for our platform use “for SAP BTP.”
  Example: Dynatrace Agent Activation for SAP BTP
• Environment or runtime names are tied to SAP BTP as these are related to the platform technology.
  Example: SAP BTP, Kyma environment; SAP BTP Cloud Foundry runtime
• Platform-related tools and add-ons take the SAP BTP brand. (Please note that not all tools and add-ons require branding. If you are unsure about it, please contact us.)
  Example: SAP BTP SDK for the Neo environment

Service long- and short names:

• The service long name is the official entry in the Approved Names list. It is used at first mention in any external document and where context is not clear, e.g., official documentation on the help portal, the sap.com product page and the service long descriptions.
  Example: SAP Application Logging service for SAP BTP
  Example: SAP Automation Pilot
• After first mention, the long name can be shortened by dropping the “for SAP BTP” part. Do not remove the “SAP” branding and the “service” descriptor (if they’re part of the long name)!
  Example: SAP Application Logging service
  Example: SAP Automation Pilot
• The service short name is only used on service tiles, e.g., in the SAP BTP cockpit and the capabilities catalog in the SAP Discovery Center and in rare cases where space is limited (e.g., on graphics). Do not use this short name in documentation. Max. 40 characters are recommended; max. 50 are characters allowed.
  Example: Application Logging Service (all uppercase for tiles).
• Please note: There are some rare services that should never drop their "SAP" branding (e.g. "SAP HANA Service"). This will be noted in the BV entry of your service name. There, your tile name is mentioned as "short name".

Important for long- and short names:

• Do not add "trial", "beta", "free tier model", or any additional terms to your service name. The same applies for the technical name of the service. If you want to express any special offerings or versions / capabilities, then do that through service plans and not by adding anything to your (approved) name. See guidelines for service plan names.
• The BV approved name should match the official name in PPMS. Service Owners need to maintain the PPMS product ID in Git and CIS will determine the correct name to display in the SAP BTP cockpit automatically. This means PPMS is the official source. If the official name in PPMS changes, the new name needs to be changed in the service metadata (Git) as well.
• If you are releasing your service in a regulated market (for example on Alibaba Cloud) and there is no difference between that offering and the service on public multi-cloud (AWS, Azure, GCP), do not request a different branded name. If the service is the same, the name is the same. Only if the product changes one or more components, then they need to have a separate PPMS entry and a new official Brand Voice approved name. The new name should be the old name, but with ", partner-managed edition" added. This name is only used for the PPMS entry, don't use it in the documentation!

“Service” descriptor information:

A lot of service names have "service" as a descriptor. Does your new name contain "service" in the official long name? Then "service" next to your service name can’t be dropped after first mention nor on tiles.

Example 1:
Service long name: SAP Application Logging service for SAP BTP
Service long name after first mention: SAP Application Logging service
Service short name for tiles: Application Logging Service
Example 2:
Service long name: SAP Feature Flags service
Service long name after first mention: SAP Feature Flags service
Service short name for tiles: Feature Flags Service

Service long- and short descriptions

• Max. 500 characters are allowed.
• Describe what the customer can achieve with the service in a few sentences and in one paragraph only.
• Start with the long service title and provide additional details.
• Keep it short and simple, don't use "...allows customers and partners to do this and that".
• Directly address the customer.
• Avoid using terms like "quickly" or "simply" - remember that we also want to use the terms in the documentation, so the tone shouldn't be too advertising.
• Do not use bulleted lists.
• Do not use any of the following dashes: "–" (minus "-" is ok)
• Do not use quotation marks.
• Do not use hyperlinks - those can be added to the dedicated link sections in the cockpit and in the marketplace.
• Do not use HTML tags like <br>, etc.
• Do not start with "XXX is a service/reuse service". State what the service does.
• Example: The SAP Performance Statistics service for SAP BTP lets you monitor the resources and investigate the causes of performance issues in your Java applications. It provides a report with the breakdown of the time and resources used by the different services of the platform for each HTTP request to your application as well as for your requests.

Service short description:

• Max. 80 characters are allowed.
• Summarize what the customer can achieve with the service in one sentence.
• Start the sentence with an imperative (such as "Create..", "Build...").
• Keep it short and simple, briefly convey the essence of the service, do not repeat what the service title already says.
• Avoid words like “enables”, “helps”, and “provides”. Everything we deliver at SAP is aimed at helping our customers – tell them how.
• Do not state the name of the service or use phrases like "on SAP BTP".
• Avoid using terms like "quickly" or "simply".
• Do not use the word “cloud” if possible.
• End descriptions with a period.
• Do not use a bulleted list.
• Do not use any of the following dashes: "–" (minus "-" is ok)
• Do not use quotation marks.
• Do not use hyperlinks - those can be added to the dedicated link sections in the cockpit and in the marketplace.
• Do not use HTML tags like <br>, etc.
• Example: “Troubleshoot performance of Java apps.”; “Translate UI texts and get suggestions during development.”

coDoc Repo Names - Guidelines

The open documentation initiative (internal project name coDoc) enables you to collect external feedback from developers through a collaboration repository in https://github.com/SAP-docs. Choosing a name for your external-facing collaboration repository is part of an outbound open-source process and must comply to the guidelines below. Although the used names correspond to the already approved name for your product area or your documentation deliverable, the guidelines ensure consistency across all repositories.

• Use prefix btp- for documentation of the BTP area (including Integration Suite and Extension Suite). For other areas, see prefixes below. Example: btp-private-link-service
• For cross deliverables, do not concatenate different area prefixes, but omit the prefix. Example: api-style-guide
• User lower case, and connect all words with hyphens (no underscores, no dashes).
• Do not use any abbreviations for your service name but aim for not more than 60 characters in total, otherwise there will be a line break. Example: s4hana-cloud-advanced-financial-closing
• Follow the same rules for service short names on tiles, see guidelines for Service long- and service short names. If your service doesn't have a OneBrand approved short name, you can still apply the rules for short names.
• If your service is still in beta, do not use beta in the repository name. Example: btp-private-link-service
• Do not add "-docs" as this is already part of the org name ("sap-docs").
• If you're creating a doc name for a guide instead of a service, add "-guide" to the name. Example: btp-best-practices-guide

Contact: Jens Haley