Guia tematica

Sales y Service Cloud basics para Administrator.

Actualizada el 30 de agosto de 2026.

El examen de Salesforce Administrator no espera que seas consultor experto en Sales Cloud o Service Cloud, pero si espera que entiendas los procesos base: como entra un prospecto, como se convierte en oportunidad, como se modelan productos y precios, como llega un caso, como se asigna, cuando escala y que herramientas ayudan a resolverlo.

El modelo mental: dos ciclos de vida

Sales Cloud y Service Cloud se entienden mejor como ciclos de vida. En ventas, una persona o empresa muestra interes, se registra como lead, se califica, se convierte y termina relacionada con Account, Contact y, si hay una venta potencial, Opportunity. En servicio, un cliente pide ayuda, se crea un case, se asigna a una persona o queue, puede recibir respuesta automatica, puede escalar por tiempo o prioridad y puede resolverse con articulos, historial y acuerdos de servicio.

La clave de examen es reconocer la etapa del proceso. Si el escenario habla de capturar prospectos, deduplicar leads, asignar nuevos interesados o convertir un prospecto calificado, estas en Sales Cloud inicial. Si habla de pipeline, etapa de venta, monto, cierre previsto, productos o price books, estas en oportunidad. Si habla de tickets, origen email/web, owner de caso, queue, respuesta automatica, escalacion o SLA, estas en Service Cloud.

Regla practica: no memorices nombres sueltos. Pregunta que esta pasando con el registro: llega, se califica, se convierte, se vende, se atiende, se enruta, escala o se resuelve.

Sales Cloud: del interes al pipeline

Sales Cloud organiza la relacion comercial desde el primer interes hasta el cierre. Un lead representa un prospecto que todavia no esta completamente calificado. Una account representa una empresa u organizacion con la que existe una relacion. Un contact representa una persona asociada normalmente a una account. Una opportunity representa una venta potencial, con etapa, monto, fecha de cierre, probabilidad y relacion con account.

Para Administrator, lo importante no es aprender tecnicas de venta, sino saber que objeto corresponde a cada pregunta. Si una empresa quiere evitar que los vendedores creen oportunidades demasiado temprano, revisa lead process, qualification y conversion. Si quiere medir pipeline por etapa y forecast, revisa opportunities. Si quiere mantener precios consistentes por region o segmento, revisa products y price books. Si quiere medir que acciones de marketing generaron respuestas, revisa campaigns y campaign members.

Tambien debes conectar Sales Cloud con configuracion. Record types pueden separar procesos de oportunidad. Page layouts y Lightning pages pueden adaptar la experiencia por equipo. Validation rules pueden exigir datos antes de avanzar etapa. Flow puede automatizar tareas o actualizaciones relacionadas. Reports y dashboards miden conversion, pipeline, actividades, forecast y desempeno por vendedor o equipo.

Leads, assignment rules y conversion

Un lead sirve para registrar interes antes de saber si debe convertirse en cliente, contacto u oportunidad real. Puede venir de un formulario, una importacion, una feria, una campana o una carga manual. La pregunta tipica no es "que es un lead", sino que debe pasar cuando llega: asignarlo a un vendedor, responder al prospecto, evitar duplicados, capturar fuente, o convertirlo cuando ya esta calificado.

Lead assignment rules asignan leads automaticamente a usuarios o queues segun criterios. Esto aparece cuando el escenario dice que los leads deben ir al representante correcto por territorio, producto, region, idioma o tipo de interesado. No confundas asignacion con respuesta automatica. La asignacion cambia owner o destino de trabajo; la respuesta automatica envia un correo al prospecto o cliente.

La conversion de lead crea o relaciona registros finales. Dependiendo de la situacion, puede crear Account, Contact y Opportunity, o relacionarse con registros existentes. Si el lead no representa una venta inmediata, puede convertirse sin crear opportunity. En preguntas de examen, palabras como qualified prospect, convert, existing account, create contact, create opportunity y avoid duplicate records suelen indicar que debes pensar en conversion y mapeo de campos.

Opportunities, products y price books

Opportunity es el objeto central del pipeline. Representa una venta potencial o en progreso, no simplemente una persona interesada. Por eso incluye Stage, Close Date, Amount y otros campos que ayudan a medir probabilidad y avance. Si un escenario pregunta como saber que deals estan por cerrar, como medir ingresos esperados o como guiar a vendedores por etapas, normalmente apunta a opportunities, sales process, Path, reports o dashboards.

Products y price books agregan estructura a lo que se vende. Product es el articulo o servicio. Price book es la lista de precios disponible para cierto contexto. Price book entry conecta producto y precio dentro de un price book. Opportunity products, tambien conocidos como opportunity line items, representan los productos agregados a una oportunidad. Esto importa porque una oportunidad puede tener un monto manual, pero cuando se usan productos, el monto puede venir de line items, cantidades y precios.

La trampa frecuente es confundir producto con oportunidad. Si el requerimiento es "queremos vender tres servicios dentro del mismo deal y calcular revenue por cada uno", piensa en products y opportunity products. Si el requerimiento es "queremos etapas diferentes para venta nueva y renovacion", piensa sales process y record types. Si el requerimiento es "queremos precios distintos por region", piensa price books.

Campaigns y campaign members

Campaigns conectan marketing con ventas. Sirven para organizar iniciativas, medir respuestas y relacionar leads, contacts, person accounts o accounts como campaign members. El detalle importante para Administrator es que campaign member no es una oportunidad: representa la participacion de una persona o cuenta en una campana y puede tener status como sent, responded, registered o attended.

En el examen, campaign aparece cuando el escenario menciona medir ROI de marketing, registrar asistentes a un evento, identificar leads generados por una feria, reportar respuestas o mantener jerarquia de campanas. Si el equipo quiere saber "quien respondio a este webinar", piensa campaign members. Si quiere saber "que oportunidades se cerraron despues de una campana", puede aparecer Campaign Influence, pero para Administrator suele bastar con entender la relacion entre campana, miembros y reportes.

Service Cloud: del caso a la resolucion

Service Cloud organiza solicitudes de clientes mediante cases. Un case representa una pregunta, problema, solicitud o incidente que necesita seguimiento. Puede venir de Web-to-Case, Email-to-Case, canales manuales u otros procesos. Sus campos suelen incluir origin, status, priority, type, reason, owner, contact y account. Para estudiar, piensa en case como el registro operativo que concentra el trabajo de soporte.

Un administrador debe saber como hacer que los casos lleguen al equipo correcto, como reducir tiempos de respuesta, como informar al cliente, como medir cumplimiento y como facilitar respuestas consistentes. Por eso Service Cloud basics mezcla objetos, reglas, queues, Knowledge, entitlements, milestones, reports y, en implementaciones mas avanzadas, Omni-Channel. En preguntas base, casi siempre puedes resolver leyendo si el problema es routing, acknowledgement, escalation, SLA o knowledge reuse.

Queues, assignment rules, auto-response y escalation rules

Queues son listas de trabajo compartidas. Permiten que varios usuarios trabajen registros que llegan a un grupo. Para Administrator, las queues aparecen mucho con leads y cases. Si el escenario dice que un equipo comparte casos de soporte o que nuevos leads deben esperar a que alguien los tome, queue es una opcion fuerte. No la confundas con public group: un public group ayuda a compartir acceso, mientras que una queue puede ser owner de ciertos tipos de registros.

Assignment rules enrutan leads o cases a usuarios o queues segun criterios. Auto-response rules envian respuestas automaticas por correo basadas en atributos del lead o case. Escalation rules elevan casos cuando cumplen criterios y han pasado ciertos tiempos. Esas tres herramientas resuelven problemas distintos aunque todas vivan cerca del proceso de entrada de registros.

La forma mas facil de reconocerlas es preguntar quien recibe la accion. Si la accion cambia quien trabaja el registro, es assignment. Si la accion informa al cliente o prospecto que su solicitud fue recibida, es auto-response. Si la accion ocurre porque el caso no se resolvio a tiempo o cumple una condicion de prioridad, es escalation. Si la pregunta dice "right person, right team, based on criteria", piensa assignment. Si dice "send confirmation email", piensa auto-response. Si dice "not resolved within four hours", piensa escalation.

Knowledge, entitlements y milestones

Salesforce Knowledge permite crear y usar articulos para resolver problemas repetidos. Para el examen, Knowledge suele aparecer cuando el equipo de soporte necesita respuestas consistentes, una base de articulos aprobados, contenido visible para agentes o clientes, o una forma de reducir tiempo de resolucion. No reemplaza case management; lo complementa con contenido reutilizable.

Entitlements representan el nivel de soporte que un cliente tiene derecho a recibir. Milestones representan pasos medibles dentro de ese compromiso, como primera respuesta o resolucion antes de cierto tiempo. Si un escenario habla de SLA, soporte premium, tiempos comprometidos, clientes con contratos de servicio o alertas por incumplimiento, piensa en entitlement management y milestones. Si solo habla de mover casos al equipo correcto, probablemente es assignment o queue.

Knowledge y entitlements suelen combinarse con Service Console, reports y automation. Un agente puede trabajar un caso, consultar articulos, enviar una respuesta y cumplir milestones. Un manager puede revisar dashboards de backlog, aging, escalations y SLA compliance. La lectura de examen debe quedarse en el requerimiento mas especifico: contenido, routing, confirmacion, escalacion o compromiso de servicio.

Errores comunes al estudiar Sales y Service basics

El primer error es tratar lead, contact y opportunity como sinonimos. Lead es pre-calificacion. Contact es persona relacionada con una account. Opportunity es venta potencial. Si la pregunta habla de una persona interesada que todavia no se califico, no saltes a opportunity. Si habla de revenue esperado y close date, no saltes a lead.

El segundo error es confundir reglas de casos. Assignment no envia confirmacion al cliente; auto-response no decide quien trabaja el caso; escalation no es simplemente una asignacion inicial. El tercer error es usar permission sets para todo. Si el problema es que un equipo debe tomar casos de una lista compartida, no es permiso individual: suele ser queue y assignment.

El cuarto error es ignorar productos y price books. Muchas preguntas sobre oportunidades no se resuelven solo con Stage y Amount. Si el escenario menciona catalogo, precios, line items, cantidades, servicios vendidos o precios regionales, debes mirar products, price books y opportunity products. El quinto error es no separar marketing de ventas: campaign member mide participacion y respuesta; opportunity mide deal.

Checklist de decision rapida:

  • El registro esta antes o despues de la calificacion comercial?
  • La pregunta pide asignar owner, enviar confirmacion o escalar por tiempo?
  • El requerimiento trata de pipeline, productos, precios o revenue?
  • El caso requiere contenido reutilizable o cumplimiento de SLA?
  • La solucion debe ser una configuracion nativa y mantenible?

Recursos oficiales y practica

Para practicar este tema, dibuja dos procesos completos. Primero: un lead llega desde una campana, se asigna por region, recibe respuesta automatica, se convierte y crea una oportunidad con productos. Segundo: un case llega por email, se enruta a una queue, recibe respuesta al cliente, escala si no se atiende y se resuelve usando Knowledge. Si puedes explicar cada objeto y cada regla en esos dos procesos, ya tienes una base fuerte para preguntas de Administrator.

BlueForce no esta afiliado a Salesforce. Esta guia es contenido editorial original basado en experiencia de estudio, objetivos publicos y recursos oficiales.