Core components: Case Management (track and resolve customer issues), Knowledge (article-based self-service), Entitlements & SLAs (service level agreements), Omni-Channel (intelligent case routing), Live Agent/Messaging (real-time chat), Einstein AI (automation and predictions), Service Console (unified agent desktop), CTI (computer telephony integration), Communities/Experience Cloud (customer self-service portal) | Platform: built on Salesforce core — shares data with Sales Cloud, Field Service | Integration: connects to phone systems, chat platforms, social media, email

Case object key fields: CaseNumber (auto-generated), Subject, Description, Status (New/Open/Escalated/Closed), Priority (Low/Medium/High/Critical), Origin (Email/Phone/Web/Chat), AccountId, ContactId, OwnerId, Type, Reason | Case lifecycle: Open → In Progress → Escalated → Closed | Related records: Case Comments, Emails, Activities, Attachments, Case Team | Case sharing: controlled by role hierarchy + sharing rules | Web-to-Case: automatically creates Cases from website form submissions

Service Console features: split-view panel (case list + detail), multiple tabs open simultaneously, Lightning Component side panels, keyboard shortcuts, macros for repetitive actions, push notifications for new cases | Setup: Lightning App Builder → create/customize Service Console app | Components: case detail, contact timeline, knowledge sidebar, email thread, chat panel | Console vs Standard: Console keeps context across navigation; Standard loses context | Utility bar: persistent tools (softphone, notes, recent items)

Email-to-Case setup: Setup → Email-to-Case → enable → create routing addresses | Routing Address: maps email address to Case queue + default priority/origin/status | Email headers: From → Contact lookup, Subject → Case Subject, Body → Case Description | Routing: multiple email addresses (support@, billing@, enterprise-support@) → different queues | On-Demand: handles emails >25MB or special encoding | Email threading: Case Number in subject line keeps email replies on the same Case | HTML email: preserved in Case comments

Web-to-Case setup: Setup → Web-to-Case → generate HTML → embed on website | Fields: choose which Case fields to include in form | Limit: 5,000 cases/24 hours per org | Response email template: auto-acknowledgment sent to customer on submission | Anti-spam: CAPTCHA available | Custom redirect: after form submit → redirect to custom thank you page | Limitations: no file attachment support in standard Web-to-Case | Alternative: Experience Cloud case creation form (more flexible)

Setup: Case Assignment Rules → rule entries (criteria + assignee) | Order: evaluated top to bottom, first match wins | Triggers: new case, or new+edited | Assignee: User or Queue | Email notification: template to new owner | One active rule per object | Assignment checkbox: on layout to control re-assignment on edit

Queue features: cases visible to all queue members, agent picks (accepts) case from queue view | List View: agents work from queue-filtered list views | Queue ownership: Case.OwnerId = Queue Id | Acceptance: agent clicks Accept → OwnerId changes to agent | Email notification: when case added to queue → notify queue members | Queue membership: Users, Roles, Public Groups, Territories | Multiple queues: organize by product, region, language, tier | Omni-Channel: replaces manual queue picking with automatic push routing

Setup: Setup → Escalation Rules → rule entries (criteria + time trigger) | Escalation criteria: case age, response time, business hours | Actions on escalation: reassign to user/queue, change priority, send email notification | Time triggers: hours/days since case created, modified, or opened | Business Hours: escalation clock uses configured business hours | Age vs Business hours: can calculate age in business hours only | Multiple rules: different escalation for different case types | Difference from Entitlements: Entitlements are per-account SLAs; Escalation Rules are global time-based rules

Case Comments: CaseComment object, Internal (agents only) or Published (customer-visible in portal), no email sent | Case Emails: EmailMessage object, actual emails in/out, stored with From/To/Subject/Body, reply creates new email on same Case | Email threading: Case Number in subject → replies linked automatically | Case Feed: shows both comments and emails in unified timeline | Templates: email templates for consistent agent responses | Attachments: both support attachments | Public vs Private: Comments can be toggled; Emails are always visible to customer

Macro components: Instructions (steps to execute), Trigger (button click or shortcut) | Actions available: send email, update field, add comment, run Flow, attach Knowledge article | Bulk macros: run on multiple cases at once | Macro builder: drag-and-drop instruction builder in Setup | Access: macros available in Service Console via utility bar | Permissions: Manage Macros + Run Macros | Irreversible macros: macros that send emails cannot be tested in preview mode | Sharing: macros can be public (all agents) or private

Setup: Setup → Auto-Response Rules → Case rule entries | Criteria: any Case field conditions | Email template: Salesforce email template selected per rule entry | From email: configured reply-to address | One active rule, multiple rule entries, first match sends | Use cases: acknowledgment emails for web form submissions, different responses for different products | Difference from Case Assignment: Assignment routes case; Auto-Response sends customer confirmation | Order: evaluated top-to-bottom, first match wins

SLA components: Entitlement (customer's right to support), Entitlement Process (sequence of milestones), Milestone (specific target — First Response within 1hr), Case Milestone (SLA status per case) | SLA tracking: Violation = milestone not met within time, Warning = approaching deadline | Business Hours: SLA clocks use business hours | SLA metrics: First Response Time, Full Resolution Time, Pending Time | Reporting: SLA compliance by queue, agent, account | Breach: notification sent, escalation triggered

Case Feed features: unified timeline (all case activity in one view), Quick Actions (email, call log, change status, knowledge), Publisher (compose email/comment directly in feed), Filter feed (show only emails, only comments, etc.) | Case Feed vs Standard Layout: Feed shows activity chronologically; Standard shows in separate related lists | Enable: Setup → Support Settings → Enable Case Feed | Compact feed: condensed view for high-activity cases | Feed items: EmailMessage, CaseComment, Task, FeedPost (Chatter), field changes

Setup: Setup → Support Processes → create → select Status values → assign to Record Type | Fields controlled: Status picklist values available | One Support Process per Record Type | Example: Hardware Support Process (New, In Progress, Parts Ordered, Resolved, Closed) vs Software Process (New, Investigating, Fix Deployed, Closed) | Why needed: different product lines have different resolution workflows | Case Status: can also drive Escalation Rules and Entitlement Milestones

Case Team object: CaseTeamMember (user + role + access), CaseTeamRole (role definition + access level), CaseTeamTemplate (predefined team for quick setup) | Access: Read Only or Read/Write per role | Notification: team members notified when added | Predefined Teams: templates applied to Cases automatically by rule | Use case: complex enterprise cases requiring cross-team collaboration | Case Sharing: Case Team members get case access regardless of org-wide default

Case Merge: merge up to 3 Cases at once | Master Case: chosen record — keeps its Case Number | Merged records: become read-only, marked as Merged status | History: all comments, emails, attachments from non-master Cases added to master | Related records: child records associated with master Case | Access: Merge Cases button (requires permission) | Duplicate detection: Duplicate Rules on Case can flag potential duplicates at creation | Limitation: cannot merge Cases from different Accounts in some configurations

Close Case Quick Action: custom Quick Action configured on Case | Pre-fills fields: Status=Closed, can require Resolution field, prompts for survey | Validation: can enforce required fields before close (Resolution must be filled) | Layout: separate close layout showing only relevant fields | Difference: Quick Action shows close-specific layout; Status dropdown bypasses it | Survey: CSAT survey trigger can be tied to Quick Action close | Reports: close via Quick Action captures closure reason consistently

Resolved: solution provided, case not yet confirmed closed by customer | Pending Customer: waiting for customer input/information (SLA clock typically paused) | Closed: fully completed, no further action, counted in resolution metrics | Pending Internal: waiting for internal action (engineering fix, third-party vendor) | Best practice: separate Resolved and Closed to track customer confirmation | SLA impact: Pending Customer status can pause SLA milestone clock | CSAT: survey typically sent when Status changes to Resolved or Closed

Routing methods: Assignment Rules (criteria → queue/agent), Omni-Channel (push to available agent based on capacity/skills), Email-to-Case (routing address → queue), Web-to-Case (Assignment Rule triggers), Apex (custom routing logic) | Modern architecture: Assignment Rule → Queue → Omni-Channel pushes to agent | Skills-based routing: Omni-Channel routes to agent with matching skills | Priority routing: Critical cases prioritized over Low in Omni-Channel queue | Fallback: if no agent available → case stays in queue

Service Cloud Voice features: telephony embedded in console, automatic screen pop (customer record appears when call connects), live call transcription (Einstein), real-time Einstein recommendations (knowledge articles, next best actions during call), call recording, post-call summary | Partners: Amazon Connect (native), other telephony partners via AppExchange | Benefits: no separate phone system window, complete call history on Case, supervisor monitoring | CTI vs Voice: CTI = third-party integration; Voice = native Salesforce telephony

CaseMilestone object: Case (parent), Milestone (target type), StartDate, TargetDate, CompletionDate, IsCompleted, IsViolated | Milestone types: First Response, Resolution, and custom milestones | Status: Completed (met on time), Violated (missed deadline), In Progress (not yet due) | Milestone Actions: warnings (approaching deadline), violations (missed), completion (met) — each triggers email/field update | Time calculation: uses Business Hours from Entitlement or case | Milestone completion: manual or automatic (when Status changes)

Creation methods: (1) Email-to-Case (automated from email), (2) Web-to-Case (website form), (3) Manual (agent or customer in console), (4) Experience Cloud portal (customer self-service), (5) Chat/Messaging (agent creates during chat), (6) Social Customer Service (Twitter/Facebook post creates Case), (7) CTI Screen Pop (phone call → Case), (8) API (external system integration), (9) Einstein Bot escalation (bot can't resolve → creates Case), (10) Field Service (work order escalation) | Channel tracking: Origin field tracks how Case was created

Deflection methods: (1) Knowledge article suggestions on Web-to-Case form (did you find your answer? → case not submitted), (2) Einstein Bot resolves issue before escalating to agent, (3) Self-service portal with search, (4) Help & Training links in product | Deflection rate: % of customers who found answer without creating a case | Measurement: web form visits vs cases submitted | Revenue impact: each deflected case saves agent time (avg $15-25 per case industry benchmark) | Challenge: measuring true deflection (customer may have not submitted anyway)

Case Flags: visual list view enhancement in Service Console | Colors: Green (within time), Yellow (approaching threshold), Red (exceeded threshold) | Configuration: Admin sets time thresholds per flag color | Purpose: at-a-glance urgency without opening each case | SLA vs Flags: Flags are visual; Milestones are tracked SLA records | Custom: Flags are based on Case age from creation or last modification | Use with Omni-Channel: less needed when cases are pushed to agents | Alternative: custom formula fields or Lightning components for custom indicators

Standard Case: no Case Age field OOTB (must create) | Formula: NOW() - CreatedDate (gives decimal days) | Business hours version: uses BusinessHours.diff() in Apex for accurate business-hour age | Bucket fields: in Reports use bucket field to group age ranges (0-1 day, 1-3 days, 3-7 days, 7+ days) | Use in escalation: Case Age drives Escalation Rules | Reporting: Average Case Age by Queue/Agent/Priority is key metric | Open Case Age: age only while Status != Closed | Total Case Age: time from creation to closure

Metric categories: Volume (cases created/closed/backlog), Speed (first response, resolution time), Quality (CSAT, reopen rate, FCR), SLA (compliance %, breach count) | Standard reports: Case Age, Cases by Status, Open Cases by Queue | Custom reports: FRT by Priority, Resolution by Agent, CSAT trend | Dashboards: Real-time (agent view), Daily ops (manager view), Weekly/Monthly (director/C-level) | CSAT: external survey result field on Case | FCR: cases closed on first response without reopen

Native Salesforce Surveys: Flow triggers on Case Close → sends survey via email | Survey response: stored in SurveyResponse object | Score field: CSAT__c custom field on Case populated from survey response | Flow/Process Builder: monitors for Status=Closed → 24-hour wait → send survey | CSAT scoring: 1-5 (1=Very Dissatisfied, 5=Very Satisfied) or NPS (0-10) | Reporting: avg CSAT by agent, product, case type | Third-party: SurveyMonkey integration via AppExchange | Prevent spam: only send if case not reopened

Lifecycle stages: (1) Creation (Email/Web/Phone/Chat), (2) Auto-acknowledgment (Case Auto-Response), (3) Assignment (Assignment Rules → Queue), (4) Agent Accept (Omni-Channel push or manual), (5) First Response (SLA milestone 1), (6) Investigation + Updates (SLA milestone 2), (7) Resolution (solution sent), (8) Pending Customer (awaiting confirmation), (9) Closure (required fields, Close Quick Action), (10) Survey (CSAT, 24hr delay), (11) Auto-close (if no reopen in 5 days) | Automation at each stage: Flow, Escalation Rules, Assignment Rules, Entitlement Milestones

Record Types: Technical, Billing, General, Enterprise, Partner | Each has: Page Layout (different fields visible), Support Process (different Status values), Business Process (different picklist values) | Assignment: set by agent at creation or auto-set by Flow/Trigger based on Case origin or subject | Benefits: focus agent on relevant fields only, drive correct workflow per type | Limitation: one Layout per Record Type per Profile | Record Type determines: Support Process (Status values), Page Layout (fields shown), Quick Actions available

Einstein Case Classification: ML model trained on closed Case data | Predictions: populates picklist and checkbox fields automatically | Confidence threshold: only applies prediction if confidence above configured % | Fields: Case Type, Priority, Reason, custom picklist fields | Setup: Setup → Einstein Case Classification → train model (requires 400+ closed cases) | Agent review: agent sees prediction with confidence %, can override | Training: model retrains periodically on new data | Benefit: consistent case categorization, faster agent handling

Split View features: persistent left panel with list view, click case in list to open in detail, filter list by queue/status/priority | vs Pinned Lists: similar concept but Split View is more integrated | Benefits: agents see all open cases in queue while working on one, quick switching, priority visibility | Configuration: enabled by default in Service Console apps | Column configuration: customize which fields show in split view list | Collapse: agents can hide split view when deep focus needed

Service Cloud Flow use cases: Auto-response on case create (Record-triggered), Set Record Type based on subject keywords (Record-triggered), Escalation notification when Case age>threshold (Scheduled), CSAT survey on close (Record-triggered + Wait), Assign to queue based on contact language (Record-triggered), Screen Flow: guided troubleshooting script for agent in console, Close cases with no response in 5 days (Scheduled), Knowledge article auto-attach based on Case type (Record-triggered)

Wrap-Up: post-interaction documentation time | Omni-Channel: After Conversation Work (ACW) status — agent status between calls for wrap-up | Timer: configurable maximum wrap-up time | Too long: reduces agent availability; Too short: incomplete documentation | Best practices: macros for standard case close actions, required fields enforced before close, templates for standard responses | Measurement: ACW time in Omni-Channel reports | Screen Flow: guided close process ensures documentation completed efficiently

Apex routing patterns: Trigger on Case → custom Apex → assign to agent/queue | Round-robin: maintain assignment counter in custom object or custom setting | Skill matching: custom Skill__c records on User → query available agent with matching skill | Timezone routing: User.TimeZoneSidKey → route to agent in customer's timezone | Capacity check: query Omni-Channel AgentWork for current capacity | Queueable: heavy routing logic in Queueable to avoid trigger limits | Testing: mock current user availability in tests

Case History: automatic (no setup needed beyond field history tracking), tracks field changes | Enable: Setup → Object Manager → Case → Fields & Relationships → Set History Tracking | Fields tracked: up to 20 fields | Retention: 18 months standard, longer with History Data add-on | Fields commonly tracked: Status, Priority, Owner, Type, Reason | CaseHistory object: queryable via SOQL | Who changed: tracked to specific user (or automation)

CaseContactRole object: Case (parent), Contact, Role (Primary, Technical, Billing, etc.) | Default: Contact on Case is primary | Multiple contacts: enterprise cases often involve multiple stakeholders | Roles defined: customizable picklist (Primary, CC, Technical, Executive, Billing) | Email CC: Case emails can be sent to all Case Contact Role members | Use case: IT ticket for enterprise — Primary (IT admin), CC (business user), Executive (VP informed of outage)

Entitlement: ENTL object — customer's right to support (Warranty, Support Plan, Web, Phone) | Entitlement Process: sequence of Milestones with time targets | Milestone: specific target (First Response 1hr, Resolution 4hr) | Case Milestone: per-case tracking of each milestone | Entitlement vs SLA: Entitlement = customer-level right; SLA = time targets within entitlement | Account vs Asset: Entitlement can be on Account (all cases) or Asset (specific product) | Service Contract: parent of Entitlement, tracks contract terms

Reopen scenarios: customer emails on closed case (Email-to-Case creates new Case) → duplicate | Auto-reopen: Flow detects reply to closed Case email → reopen Case | Reopen counter: Case.TimesOpened standard field tracks reopens | Policy: define reopen window (7 days) vs new case | CSAT impact: case reopen = quality failure, tracked as reopen rate metric | Agent notification: when Case reopened → original agent notified | Email threading: reply to closed case email → Flow reopens rather than creating duplicate

Knowledge: Knowledge Article object, Article Types, Article lifecycle (Draft→Review→Published→Archived) | Linking to Cases: Knowledge Sidebar in Console, search while working case, attach solution to case | Case Deflection: Web-to-Case suggests articles, portal search | Agent Assist: Einstein recommends articles during case handling | Article feedback: thumbs up/down on article | Reporting: most-used articles, articles linked to most cases | Search: keyword and federated search | Data categories: organize articles by product/audience

Top practices: (1) All channels → single Case object (unified view), (2) Omni-Channel > manual queue picking, (3) Required fields on Close Quick Action (Resolution, Root Cause), (4) Knowledge → attach to every Case (builds knowledge base organically), (5) CSAT → measure and act on, (6) SLA → Entitlements not just Escalation Rules, (7) Flows → automate acknowledgment, escalation, auto-close, (8) Macros → reduce handle time, (9) Dashboard → real-time ops view for manager, (10) Reports → act on data (coaching, process improvement)

Articles: content units with structured fields | Article Types: define the structure/template (FAQ, How-to, Solution, Reference) | Data Categories: hierarchical taxonomy (Product > Platform > Analytics) | Channels: Internal (agents), Customer (portal), Partner (partner portal), Public (website) | Lifecycle: Draft → Validation Status → Published → Archived | Knowledge User license: agents need Knowledge User checkbox on User | Versioning: articles versioned when updated | Translation: multilingual article support

Lifecycle statuses: Draft, Ready for Review, In Review, Published, Archived | Approval: article can require approval before publishing (Approval Process or manual review) | Versioning: when published article updated → new Draft version created → old version stays Published until new version published | Archival: article removed from channels but preserved for history | Restore: archived article can be republished | Article ID: stays same across versions | Review dates: scheduled review reminders for freshness

Data Category Groups: top-level groupings (Products, Geography, Topics) | Data Categories: hierarchical values within groups (Products > Software > Analytics) | Assignment: articles assigned to categories during creation | Visibility: Data Category Visibility settings control which roles/profiles see which categories | Search filtering: portal users can filter search results by category | Multiple groups: article can be in multiple Data Category Groups | Default: articles without category visible to all | Role-based: Enterprise support staff see all articles; external customers see subset

Knowledge Sidebar: panel in Service Console showing recommended articles | Search: agent can also manually search | Article actions in sidebar: attach to case, email to customer, view article | Relevance: keyword matching from Case subject/description | Einstein Search: AI-powered relevance ranking | Configuration: Lightning App Builder → add Knowledge component to console layout | Article feedback: agent can mark article as helpful or not | Link to Case: attached articles create KnowledgeArticleCase junction record

Deflection methods: (1) Portal search (customer searches, finds answer → no case), (2) Web-to-Case article suggestions (subject entered → articles suggested → "Did this solve it?" Yes=no case, No=case submitted), (3) Home page featured articles, (4) Einstein Bot suggests articles before transferring to agent | Deflection measurement: portal visits / articles viewed / cases submitted | True deflection: hard to measure (customer may not have submitted anyway) | Tracking: custom tracking on "Did this solve it?" click | Optimization: analyze which articles deflect most → feature prominently

Lightning Knowledge: one Knowledge object (Knowledge__kav), record types per article type, standard Salesforce page layout, Lightning compatible | Classic Knowledge: separate objects per article type (FAQ__kav, HowTo__kav), not fully Lightning, deprecated | Migration: Classic → Lightning via Knowledge Migration Tool | Difference: Lightning uses standard Salesforce CRUD; Classic used article-specific actions | API: Lightning Knowledge queryable via standard SOQL on Knowledge__kav | Lightning only: Einstein Article Recommendations, Knowledge Sidebar enhancement

Implementation: Experience Cloud site → Knowledge component → configure channels (Customer Portal), Data Category visibility | Search types: keyword search, category browsing, featured articles | Search results: sorted by relevance (Einstein) or date | Article view: full article with attachments, related articles | Case creation: "Create a Case" button if article doesn't resolve | Feedback: thumbs up/down on article | Search analytics: Knowledge article views, searches with no results (gap analysis) | Federated search: search Knowledge + Cases + Products in one query

Version behavior: Published article updated → new Draft created (same Article ID) | Old version: remains Published until new version published | Version number: KnowledgeArticleVersion tracks each version | Archival: old version archived automatically when new published | History: full version history maintained | Rollback: can republish a previous version | Why: ensures customers always see Published content while updates go through review | Translation: each language version tracked separately

Einstein Article Recommendations: ML model trained on Case-Article associations | Input: Case Subject, Description, fields | Output: ranked list of relevant articles | Learning: when agent attaches article to resolved case → positive signal → improves future recommendations | Threshold: only shows if confidence above minimum | Requirements: Lightning Knowledge, sufficient article attachments (400+ recommended), Einstein license | Configuration: enable in Setup → Einstein → Article Recommendations → train model

Key metrics: Article Views (portal + console), Attachments per Case (goal: >1), Deflection Rate (cases not submitted after viewing article), Feedback Score (positive/negative ratings), Resolution Time with article vs without, Top Articles (by views and case attachments), Article Gap (no-result searches), Stale Articles (not viewed in 90 days) | Reports: Knowledge Base Report (OOTB), custom reports on KnowledgeArticleCase junction

Solutions: deprecated feature, simple text/HTML answers linked to Cases | Knowledge: rich content, versioning, approval workflows, data categories, multiple channels, Einstein | Migration: Salesforce provides Solutions to Knowledge migration tool | Key difference: Solutions = basic, single channel; Knowledge = enterprise content management | Why deprecated: Solutions had no versioning, limited formatting, no approval workflow | Current: Knowledge is the only supported content management system in modern Salesforce orgs

Knowledge User checkbox: enables create/edit articles, search Knowledge, attach to cases | Knowledge Manager: Knowledge User + Manage Articles permission + Publish Articles permission | Typical roles: agents = Knowledge Users (suggest articles), Content Team/Senior Agents = Knowledge Managers (review and publish) | Permission Set: common to assign Knowledge Manager permissions via Permission Set | Lightning Knowledge: permissions more granular — Read/Create/Edit/Delete/Archive/Publish/Manage per profile

Setup: Enable Translation Workbench → add languages → assign translators | Translation workflow: English article published → auto-flagged for translation → assigned to translator → Draft translation created → reviewed → published | Language selector: portal users choose language → see translated articles | Fallback: if no translation → show default language | Translation status: fields track translation status per language | Import/Export: export articles for external translation, re-import | Quality: bilingual reviewer approves before publishing

Featured Articles: promoted position in search results or portal | Promotion types: promoted search terms (specific keywords → article always appears first), featured article component (portal home page widget) | Use case: known widespread issues → feature article so customers self-serve before creating case | Promoted Search Terms: admin adds keywords → article shows first for those keywords | Portal home: Knowledge component configured to show featured | Review: update featured articles when product releases

Standard Knowledge reports: Knowledge Article Usage (views by article, date range, channel), Article Vote Statistics (feedback scores), Linked Articles to Cases (which articles resolve which case types) | Custom reports: KnowledgeArticleCase object (case-article junction for custom reports), Knowledge Search report (searches, results, no-result queries) | Gap analysis: searches with 0 results = content gaps | Performance: articles by views, attachments, feedback score | Reporting types: Article, Article Version, Article Vote

Knowledge One: Lightning global search includes Knowledge | Unified search: searches Articles + Cases + Contacts + Accounts together | Filter: search results filterable by object type | Article preview: hover to see article summary before opening | In console: Knowledge Sidebar still the primary article discovery; global search for broader context | Permission: Knowledge User required to see articles in search | Mobile: Knowledge searchable in Salesforce mobile app

Setup: Experience Cloud site (Partner Community template), Knowledge component, Data Category Visibility for partner profile | Article assignment: Channel = Partner (checkbox on article), Data Category = Partner category | Partner profile: Knowledge User checkbox, Read access to Knowledge articles | Sharing: partners see only Partner-channel articles in their category | Separate from customer: Partners may see different articles than customers | Content: partner-specific articles (integration guides, reseller pricing, implementation guides)

Einstein Search features: NLP (understand meaning not just keywords), personalization (learns individual agent preferences), context awareness (uses open Case fields to improve results), spell correction, synonym handling | Relevance factors: article quality signals, usage frequency, recency, feedback scores | Setup: Einstein Search license required, enable in Setup | vs Standard search: keyword only, no NLP, no personalization | Impact: higher first-result accuracy, faster article discovery

Gap sources: No-result searches in portal (most direct), Case Subject analysis (what are cases being created about?), Chat transcript analysis (common questions), Agent observation (questions frequently asked), Product release notes (new features need articles) | Process: weekly no-result search report → triage → assign to Knowledge Owner → create within SLA | Priority: high-volume gaps first | Measurement: track if new article deflects cases in same topic

Migration steps: (1) Content audit (inventory all documentation), (2) Rationalization (remove outdated, merge duplicates), (3) Format conversion (HTML/markdown to Knowledge rich text), (4) Import (API or Data Loader to Knowledge__kav), (5) Category assignment, (6) Review and publish | Tools: Data Loader (basic import), API (metadata migration), third-party tools (Steer, Tectonic) | Common issues: formatting loss during conversion, broken links, image handling | Post-migration: search validation, agent adoption

Entitlement object: Status (Active/Inactive/Expired), Account/Asset, EntitlementProcessId, StartDate, EndDate, Type (Web/Phone/Email) | Case-Entitlement: Cases linked to Entitlement (CaseNumber of interactions tracked) | Entitlement name: typically support tier (Gold, Silver, Basic, Warranty) | Lookup on Case: when creating Case, agent selects Entitlement → determines which SLA process applies | Auto-assign: Flow triggers Entitlement lookup on Case create | Entitlement Contact: specific contacts authorized to receive support

Entitlement Process: sequence of Milestones with time calculations | Milestones: specific targets (name + time limit) | Milestone Actions: Warning (approaching), Violation (missed), Complete (met) — each can send email/update field | Business Hours: process uses assigned Business Hours for time calculation | Start: process starts on Case creation | Stop: optional — process can stop during Pending Customer status | Multiple processes: different processes for Enterprise/Standard/Basic

Milestone fields: Name, MilestoneName, StartDate, TargetDate, CompletionDate, IsCompleted, IsViolated | Milestone types: time-based (First Response, Resolution, Interim Response) | Auto-complete: trigger milestone completion on specific Case Status change (e.g., First email sent = First Response complete) | Manual complete: agent marks complete | Milestone Actions: Warning email (approaching), Violation email (missed), Completion email | Status color: green (on track), yellow (warning), red (violated)

ServiceContract object: AccountId, Status (Active/Cancelled/Expired), StartDate, EndDate, Total Price, Line Items (ContractLineItem) | ContractLineItem: specific products/services covered | Entitlement: child of ServiceContract | Automatic creation: when Opportunity closed won or Order activated | Renewal: Service Contract renewal drives new Entitlements | Revenue: Service Contract tracks support revenue separately from product revenue | Relationship: Account → Service Contract → Entitlement → Case

Entitlement Process: per Account/Entitlement, milestone-based, Business Hours aware, tracks compliance per milestone | Escalation Rules: global, time-from-creation based, any case meeting criteria, simpler | When to use each: Entitlement Process for tiered customer SLAs (Enterprise gets different SLA than Standard), Escalation Rules for operational safety net (all Critical cases get manager after 4 hours regardless of customer) | Can use both: Entitlements for SLA commitment, Escalation Rules as backup | Compliance reporting: Entitlements track; Escalation Rules only act

SLA compliance metrics: Compliance Rate (milestones completed on time / total milestones), MTTR (Mean Time to Resolution), FRT (First Response Time), Violation Rate by Milestone type | Reports: CaseMilestone report (built-in), custom reports on IsViolated/IsCompleted | Dashboard: real-time SLA status (green=on track, yellow=warning, red=violated), by queue and priority | Root cause: analyze violations by queue/agent/time of day/day of week | Action: SLA breach = coaching, process review, staffing adjustment

Business Hours setup: Setup → Business Hours → create → set days/hours/timezone | Default Business Hours: used if no specific hours assigned | Multiple Business Hours: different hours for different regions (US East, US West, EU, APAC) | Holiday schedule: closed dates defined, excluded from SLA calculation | Assignment: Entitlement Process → Business Hours, Escalation Rule → Business Hours | Impact: 4-hour SLA during 8am-6pm M-F → case at 5pm → 3 hours left today + 1 hour next morning | 24/7: critical customers can have 24-hour Business Hours definition

Entitlement Contact: junction object (Entitlement__c + Contact__c) | Authorization: only listed contacts can submit cases (if enforcement enabled) | Tracking: number of cases per contact tracked against entitlement limits | Use case: "Support Pack" — customer bought 100 support hours, track hours used per contact | Enforcement: optional — if enabled, unlisted contacts get error creating case | Seat-based support: track which individuals in the account are authorized users | VIP contacts: some contacts always prioritized

Implementation: (1) Create Entitlement Process per tier (Enterprise/Standard/Basic), (2) Set milestone time targets per tier, (3) Create Entitlements on Accounts per tier, (4) Auto-assign Entitlement on Case create (Flow), (5) Entitlement Process starts automatically, (6) Milestones tracked per case, (7) Report by tier | Account tier field: Account.Support_Tier__c drives which Entitlement applies | Auto-create Entitlements: when Account tier set → Flow creates Entitlement + links to correct process | Upgrade path: Account tier upgrade → new Entitlement created

Entitlement Process Stop Conditions: define when process pauses | Common stop: Status = Pending Customer | Common restart: Status changes back to In Progress/Open | SLA impact: hours waiting for customer excluded from SLA time | Business value: fair — support team not penalized for waiting on customer | Configuration: Entitlement Process → Stop the entitlement process when → Pending Customer | Restart: manually or via Status change trigger | Reporting: distinguish paused vs active SLA time

Integration: CPQ Order activated (support product) → Flow → Service Contract created → Entitlement created → linked to Entitlement Process | CPQ product fields: drives Service Contract Type, StartDate, EndDate, Price | Subscription sync: CPQ Subscription renewal → Service Contract renewal → new Entitlement | Field mapping: CPQ OrderItem fields → Service Contract fields (via Twin Fields or Flow) | Reporting: support revenue (Service Contract) linked to product revenue (CPQ Order)

Asset object: Product2 (product type), AccountId, ContactId, SerialNumber, Status (Purchased/Shipped/Installed/Active/Discontinued) | Asset-based Entitlement: Entitlement.AssetId = specific product instance | Use case: hardware manufacturer — warranty covers specific serial number, not all products from account | vs Account Entitlement: Account entitlement covers all cases from account; Asset entitlement covers only cases for that specific product | Field Service: Assets central to work order management

After-hours approaches: (1) Business Hours → SLA pauses outside hours, (2) Emergency on-call queue for Critical-only after hours, (3) Auto-response: "received, will respond in X hours", (4) Einstein Bot: handles common after-hours requests, (5) Emergency contact: VIP customers have direct emergency line | Routing: Omni-Channel → outside business hours → on-call agent or queue | Critical escalation: even after hours, Critical cases trigger page to on-call | Self-service: portal/Knowledge available 24/7

Report types: Milestone Compliance (% milestones completed on time), Violation Analysis (which milestones violated most, by queue/agent), FRT Report (time from case create to first response), MTTR Report (case create to close), Account SLA Report (compliance per customer for QBRs) | Data: CaseMilestone object, Case object (with calculated age fields) | Executive: monthly SLA scorecard, customer compliance for account health | Renewal: SLA compliance history provided during contract renewal | Penalty: some contracts have SLA penalties — compliance tracking critical

Breach response process: (1) Automated violation notification → manager, (2) Agent notified immediately, (3) If still open → escalate to senior/Tier 2, (4) Customer proactive outreach (don't wait for complaint), (5) Resolution with explanation, (6) Root cause documentation | Contractual: if SLA penalty clause → calculate credit, issue in Billing | Prevention: identify root cause pattern → process change | Tracking: SLA breach tracker (custom object or report) | Customer retention: proactive SLA breach communication = 40% less churn than reactive

Omni-Channel components: Routing Configuration (how work is distributed), Queue (work container), Presence Configuration (agent status options), Service Channel (work item type — Case, Chat, Call), Agent Capacity (max items at once) | Routing types: Queue-based (first available in queue), Skills-based (agent with matching skill), External Routing (custom logic via API) | Agent Statuses: Available, Busy, Away, On Break, Offline | Presence: agent sets status → Omni-Channel routes accordingly | Supervisor: Omni-Channel Supervisor tool shows real-time agent workload

Queue-based: work assigned to first available agent in queue, simplest setup | Skills-based: each work item has required skills, agent must have matching skills, overflow if no skilled agent | External Routing: third-party or custom routing via messaging API | Routing Model within Queue-based: Least Active (fewest open items), Most Available (highest remaining capacity), First In First Out (queue order) | Skills-based overflow: if no agent with skill → wait or route to general queue after X minutes | Priority: within same routing type, higher priority items pushed first

Presence Status: Available (ready for work), Busy (not accepting new), Away (short absence), On Break (break), Offline (end of shift) | Busy by Work: automatically set to Busy when at full capacity | Channel-specific: agent can be Available for Cases but Busy for Chat | Configuration: Presence Configuration → define available statuses | Supervisor: Omni-Channel Supervisor shows all agents, their status, current work | Reporting: presence data in Omni-Channel reports (availability by agent, status distribution)

Setup: (1) Create Skills, (2) Assign Skills to Agents (AgentWork.Skills or SkillsBasedRouting), (3) Tag work items with required skills, (4) Configure Routing Configuration to Skills-based, (5) Overflow configuration | Skill proficiency: skill level (0-10) can further refine routing | Priority + Skills: Critical cases requiring Network skill → agent with Network skill + highest availability | Fallback: if no skilled agent available in X minutes → route to backup queue | Einstein: Einstein Case Classification can auto-tag required skill

Live Chat components: Chat Button (embedded on website), Visitor (customer), Chat Session (interaction), Chat Transcript (record of chat), Chat Deployment (configuration) | Agent side: Chat window in console with Case panel, Knowledge sidebar | Customer side: web widget | Features: queue display, estimated wait time, proactive chat invitation, cobrowsing, file transfer | Routing: Omni-Channel routes chats to available agents | Transcripts: saved as LiveChatTranscript, can create Case | Chat-to-Case: button to create Case from chat context

Messaging types: SMS (text), WhatsApp Business, Facebook Messenger, Apple Messages, Google Business Messages | Asynchronous: conversation can pause and resume (vs real-time chat) | Messaging Session: record of the messaging conversation | Routing: Omni-Channel routes messaging sessions to agents | Customer identity: recognized via phone number or social account | Case creation: messaging session can create Case or be linked | Consent: opt-in required for outbound SMS | Einstein: bot handles initial messaging before agent

CTI components: Softphone adapter (CTI toolkit), Open CTI API (Salesforce standard), Phone system (Avaya, Genesys, Five9, Cisco) | Features: screen pop (caller ID → lookup → display record), click-to-dial (call number directly from Salesforce), call logging (auto-log to Case/Contact), call recording, whisper coaching | Open CTI: JavaScript API connecting phone system to Salesforce | CTI vs Service Cloud Voice: CTI = third-party integration; Voice = native Amazon Connect integration

Live Chat: synchronous, web widget, real-time session, customer must stay on page | Messaging (SMS/WhatsApp): asynchronous, customer can leave and return, conversation history preserved, mobile-native | Service Cloud Voice: phone calls, native Amazon Connect or partner telephony, transcription, Einstein recommendations | When to use: Chat = web self-service portal (immediate help), Messaging = mobile customers who prefer text, Voice = complex issues needing verbal explanation | All three: route via Omni-Channel, create Cases, appear in same console

Supervisor features: real-time agent status (Available/Busy/Away), current work items per agent, queue backlogs with wait times, capacity utilization, ability to reassign work items | Views: Agent tab (agent status), Queue tab (queue backlog and wait times) | Actions: manually assign item to specific agent, change agent capacity | Alerts: agents away too long, queue building up | Wallboard: display in operations center | Reports: Omni-Channel historical reports (handle time, wait time, utilization)

Service Channel: separate config for Case and Chat | Capacity model: Cases (3-5 capacity units), Chat (1-2 capacity units — more intensive) | Work Item Priority: Chat often higher priority (customer waiting) than Cases | Agent experience: during chat, new cases not pushed (at capacity) | Blended agents: handle both Cases and Chats depending on current load | Transition: when chat ends → capacity frees → case can be pushed | Chat timeout: idle chat auto-closed after X minutes | Multi-chat: agents can handle 2-3 chats simultaneously (skill-dependent)

Omni-Channel Flow: Flow triggered by Omni-Channel routing decision | Can query: agent availability, skills, current workload, case history | Dynamic routing: route based on customer history with agent (reconnect with same agent), language preference, account tier real-time check | Components: Route To Agent, Route To Queue, Check Queue Wait Time | Benefits: more complex logic than static routing | Use cases: VIP reconnect (route to agent who handled the last case), language routing, capacity-aware premium routing

Social Customer Service: Starter Pack (free, basic) or full Social Studio integration | Social channels: Twitter, Facebook, Instagram, LinkedIn | Case creation: keywords/mentions → auto-create Case | Agent response: reply from Salesforce → posts to social channel | Case source: Origin=Twitter/Facebook | Social persona: customer's social profile linked to Contact | Sentiment: positive/negative/neutral classification | Priority: social mentions by influencers can auto-set High priority | Monitoring: keyword listening

Einstein Bot components: Dialog (conversation branches), Action (what bot does — query data, update record), Variable (capture customer input), Intent (understand what customer wants), Transfer to Agent (escalation trigger) | NLU: Natural Language Understanding classifies customer intent | Integration: can query Salesforce data (Account status, Case status, Order status) | Fallback: if bot can't resolve → transfer to Omni-Channel queue with context | Transcripts: bot conversation saved for agent context on transfer

Agentforce Service Agent: autonomous AI for service | Capabilities: understand customer query (NLU), query Salesforce data (Account, Case, Order), execute actions (create Case, update record, send email, initiate refund), multi-turn conversation | Escalation: hands off to human agent with full context when: complex issue, customer requests human, confidence threshold not met | Channels: chat, messaging, email | Grounding: uses Knowledge Articles, order data, Case history to formulate responses | 2026: generally available

Key Omni-Channel reports: Agent Work (time spent per item, handle time), Routing (wait time, assignment time), Channel (volume by channel, containment), Presence (availability time, status distribution) | Standard objects: AgentWork, UserServicePresence, ConversationEntry | Metrics: Average Handle Time (AHT), Average Wait Time (AWT), Transfer Rate, Agent Utilization %, Abandonment Rate (chat) | CRMA: Omni-Channel Supervisor Analytics app | Benchmark: AHT (industry 6-8 minutes for chat, 4-5 days for cases)

Omni-Channel Voice: phone call = Omni-Channel work item | Amazon Connect: telephony provider (Salesforce native partnership) | Routing: IVR → Amazon Connect → Omni-Channel → agent skills/capacity | Screen pop: caller ID → Customer record shows in console | Recording: call recorded, transcript generated | Einstein: real-time recommendations during call | Supervisor: same Supervisor view includes voice alongside Cases/Chats | Reporting: unified channel reporting across Case/Chat/Voice

Capacity model: Routing Config → Work Item Size (capacity units per item) | Agent total capacity: defined in Presence Configuration | Example: Agent capacity=6, Case=2 units (3 cases max), Chat=3 units (2 chats max) | Mixed: 1 Chat (3 units) + 2 Cases (2×2=4 units) = 7 units → exceeded → no more work pushed | Capacity by channel: can set different capacities per channel | Tab-based: alternative model counts open tabs instead of units | Real-time: capacity updates as work items opened and closed

Follow-the-sun setup: Regional queues (US East, EU, APAC), Business Hours per region, Routing: morning US hours → US queue, afternoon EU hours → EU queue | Overflow: if US queue empty → route to EU if overlap hours | Skills: regional agents may have language skills | Omni-Channel Flow: dynamic region selection based on customer timezone or language | Business Hours: associated with queues for routing windows | Escalation: Critical cases → follow-the-sun always (24/7)

Einstein Routing: ML model trained on Case-Agent-Resolution patterns | Predictions: which agent/queue most likely to resolve quickly | Input: case subject, description, category, account history | Output: routing score per agent → Omni-Channel routes to highest-scoring available | Continuous learning: learns from outcomes (faster resolution = positive signal) | Requirements: sufficient historical data (1,000+ closed cases recommended) | Integration: works within Omni-Channel framework | Benefits: reduces transfer rate, improves FCR, leverages agent expertise

Cobrowsing: real-time browser sharing during chat session | Agent capabilities: view customer screen, click/highlight elements (with customer permission) | Customer consent: customer must approve cobrowse request | Privacy: sensitive fields (password, credit card) automatically masked | Integration: cobrowse launched from within chat session | Use cases: help complete form, demonstrate feature, diagnose UI error | Vendors: Salesforce has native basic cobrowse; advanced requires AppExchange (Glance, Surfly) | Recording: cobrowse session can be recorded for review

Einstein Service features: Einstein Case Classification (auto-populate Type/Priority/Reason), Einstein Article Recommendations (suggest Knowledge), Einstein Case Routing (smart queue assignment), Einstein Bots (automate common inquiries), Einstein Next Best Action (prescriptive agent guidance), Service Cloud Voice Einstein (live transcription + real-time recommendations) | License: Einstein for Service license | Data requirements: each feature needs sufficient training data | ROI: each feature saves 1-5 minutes per case × case volume

Einstein NBA: AI + rule-based recommendations | Recommendation: displayed in Service Console as a card with action | Action types: offer discount, send template, create order, schedule callback, flag for retention | Rules: Strategy Builder defines when to show which recommendation | Input: Case fields, Account fields, customer history | Action outcome: agent accepts → action executed automatically | Feedback: accepted/rejected actions improve model | Integration: works in console via Lightning component

FSL components: Work Order (field service job), Service Appointment (scheduled time), Service Resource (field technician), Service Territory (geographic area), Skills (technician expertise) | Service Console integration: Case → Create Work Order → Schedule → Dispatch → Mobile completion | Mobile: Salesforce Field Service mobile app for technicians | Return: RMA process linked to Cases | Asset maintenance: preventive maintenance plans linked to Asset records | Integration: Cases escalate to Work Orders when on-site visit needed

Sentiment analysis: Einstein NLU classifies email/chat text sentiment | Negative detection: escalation trigger when high negative sentiment | Agent UI: sentiment indicator shown on Case/Chat | Supervisor: real-time sentiment alerts for high-negative chats | Use cases: detect escalating customer frustration, identify at-risk accounts, quality review of negative interactions | Platform: Einstein Language API, Service Cloud Voice transcription sentiment | Historical: sentiment trends by agent, product, time period | Third-party: Calabrio, Qualtrics for deeper sentiment

Service Analytics dashboards: Case Volume (trends by channel, type, priority), Resolution Analysis (FRT, MTTR, resolution by agent/queue), SLA Compliance (milestone completion rates), CSAT (trends, by agent/type), Agent Performance (AHT, caseload, CSAT), Backlog (aging cases, queue health) | Data: from Case, CaseMilestone, AgentWork, LiveChatTranscript | Refresh: daily scheduled | Custom: add company-specific KPIs | License: CRM Analytics license | Install: AppExchange → configure data sources → 1-2 days

Implementation: Einstein Bot → Knowledge action (Search Knowledge), present article title + summary, "Did this solve your issue?" | Flow: Customer asks question → Bot intent matches → Bot searches Knowledge with keywords → top article returned → Bot presents summary → customer responds Yes (no agent) or No (escalate to agent with context) | Requirements: Knowledge articles published in appropriate channel | Quality: bot answer quality = knowledge article quality | Escalation context: article searched + customer query passed to agent on transfer

Automation toolkit: Record-triggered Flows (on Case field change), Scheduled Flows (daily auto-close, aging alerts), Screen Flows (guided agent troubleshooting), Einstein (auto-classify, recommend), Macros (agent-initiated multi-step), Apex Triggers (complex logic), Platform Events (event-driven) | Prioritization: automate high-volume repetitive tasks first | ROI: time saved per automation × case volume × agent cost | Examples: auto-categorize email cases by subject, auto-assign entitlement, send CSAT on close, auto-close stale cases

Case Summarization: generative AI (Einstein GPT) synthesizes conversation history | Input: all EmailMessage, CaseComment, LiveChatTranscript records | Output: 2-3 paragraph summary of issue, actions taken, current status | Use cases: agent picking up a case mid-conversation, supervisor reviewing case, after-hours handoff | Configuration: Einstein GPT license, Service Cloud | Agent experience: "Summarize Case" button → instant summary in sidebar | Customer data: summary based on actual case data, not hallucinated | 2026: GA in most regions

360 view components: Account details (tier, ARR, renewal date), Contact info (role, communication history), Case history (recent + open), Orders/Subscriptions, Entitlement (current SLA status), CSAT history (last 3 scores), Notes (Account Manager notes), Einstein Next Best Action | Implementation: Lightning App Builder → Console Layout → add components | Standard components: Related Lists, Timeline | Custom components: LWC embedded in console | Data sources: multiple related objects | Design: right-hand sidebar for contextual info (doesn't replace Case detail)

Macros: single case, agent-initiated, sequence of actions | Bulk Macros: select multiple cases in list view → run macro on all | Actions available: send email, update field, add comment, attach article, run Flow | Macro access: Utility Bar in Console, Quick Action | Bulk Macro use cases: close a batch of duplicate cases, send standard notification to group of cases, update status on resolved cases from same issue | Permissions: Run Macros permission, Manage Macros (create/edit) | Irreversible: macros sending emails cannot be previewed

CRM Analytics: native Salesforce, pre-built Service dashboards, no data extract required, real-time Salesforce data | Tableau: standalone platform, connects to Salesforce + other data sources (SQL, ERP, marketing tools), more advanced visualizations, better for cross-system analytics | When CRM Analytics: Salesforce-only metrics, operational dashboards, agent-facing views | When Tableau: enterprise executive dashboards, cross-system metrics (support + finance + sales), advanced analytics, predictive models | Cost: CRM Analytics included with some licenses; Tableau separate cost

FCR definition: case closed without: (1) status being Opened again, (2) customer contacting again on same topic within 7 days | Measurement: custom formula or report counting Cases where TimesOpened=1 AND no related Case created within 7 days | Industry benchmark: 70-75% FCR for phone, 85-90% for chat | Improvement: Knowledge attachment (FCR 67% → 82% with article attached), agent training, escalation authority | Report: FCR trend by agent, channel, case type | Leading indicator: high FCR = lower customer effort, higher CSAT

Proactive service methods: IoT/product telemetry (error logs → create Case before customer notices), Health scoring (low adoption → CSM outreach), Predictive maintenance (asset nearing failure → schedule service), Expiry alerts (subscription nearing expiry → renewal contact), Einstein prediction (churn risk → proactive engagement) | Platform: Salesforce IoT + Service Cloud, Gainsight integration | Case type: Proactive (agent-created) vs Reactive (customer-initiated) | Measurement: proactive case rate, issue prevented vs issue reported

KPI categories: Speed (FRT, MTTR, AHT), Quality (CSAT, FCR, Reopen Rate, Agent Quality Score), Volume (Cases by Channel, Backlog, Deflection Rate), Cost (Cost per Case, Cost per Channel, Agent Utilization) | Benchmarks: CSAT>85%, FRT<4hr High/1hr Critical, FCR>75%, Reopen<8%, SLA>90%, Handle Time<6min chat/2days case | Dashboard: different KPIs for different audiences (ops/manager/director/executive) | Leading vs lagging: FRT (leading — indicates future CSAT); CSAT (lagging — reflects past performance)

2026 Einstein features: Agentforce Service Agent (autonomous multi-turn, GA), Einstein Case Summarization (GA, generative AI for case context), Einstein Copilot for Service (agent assistant in console — suggests responses, next steps), Data Cloud integration (real-time 360 view of customer during service), Voice AI enhancements (sentiment in real time, auto-script compliance) | Shift: from point AI features → unified Einstein copilot for all service tasks | Platform: Einstein 1 Platform underpins all features

Architecture decisions: Case origin (Email primary, Chat secondary, Portal self-service), Entitlements (contract-based tiers), Routing (Skills-based by product module), Knowledge (technical documentation + release notes), Bot (common API questions, status checks), Escalation (Tier 2 for deep technical) | Integration: Jira (engineering escalations), Slack (internal team coordination), Zoom (enterprise technical calls), Customer success (Gainsight/Salesforce Success Plans) | Metrics: CSAT, FCR, SLA compliance, case volume trends

High-volume considerations: agent efficiency (every second matters at scale), supervisor monitoring (real-time queues), WFM integration (Verint, Nice, Genesys WFM), reporting granularity (15-minute interval data), QA sampling (call/chat recording review), training program (new agent ramp time) | Scale: 100+ agents, 50,000+ cases/month | Infrastructure: Salesforce org performance at scale, SOQL governor limits, bulk data operations | Einstein: at scale, classification error rate matters (1% error = 500 wrong cases/month)

Top 10 mistakes: (1) All channels on day 1 (start with email + phone), (2) No baseline metrics (measure before to show improvement), (3) Skipping agent training (50%+ adoption failure without training), (4) Complex approval process for Knowledge (kills article creation), (5) No CSAT measurement (blind to quality), (6) Case assignment to individual not queue (bottleneck), (7) No escalation rules (Critical cases sit), (8) Ignoring mobile agents (Field Service cases), (9) No Entitlements for SLA (cannot track compliance), (10) Big bang go-live vs phased

Migration steps: (1) Audit legacy data (case history, KB articles, contacts), (2) Data mapping (legacy fields → Salesforce objects), (3) Sandbox build + configuration, (4) Data migration to sandbox (test), (5) Agent training, (6) Parallel operations (run both systems), (7) Production migration (historical data), (8) Cutover (single channel go-live), (9) Phased channel addition | Common legacy systems: Zendesk, Freshdesk, ServiceNow, Jira Service Desk | Tools: Data Loader, third-party migration tools (Apsona)

Agentforce service vision: autonomous handling of routine inquiries (status checks, password resets, billing questions, appointment scheduling), seamless escalation to human for complex/emotional cases, continuous learning from human agent resolutions | Impact: case volume handled per human agent increases 3-5×, cost per case decreases 60-70%, 24/7 coverage without additional staffing | Human role evolution: complex problem solving, relationship management, exception handling, AI training/correction | 2026: early adopters seeing 50-60% containment

Healthcare specifics: HIPAA Shield (encrypt PHI fields, audit all access), BAA with Salesforce, FSC or Health Cloud add-on for clinical data, Case types (clinical inquiry, appointment, billing, insurance), Integration (Epic/Cerner for patient records, insurance APIs), Agent training (HIPAA, sensitive communication), No PHI in email subjects (encrypt or use secure messaging) | Case channels: phone (primary), secure patient portal, no SMS (PHI risk) | Entitlements: insurance-based coverage determines support level

Financial Services specifics: Communication archival (all emails/chats archived for regulatory requirement), Sensitive data fields (SSN, account numbers encrypted), Compliance Case Types (complaint, dispute, fraud), Audit trail (who accessed what when), Core banking integration (balance, transaction history), Regulatory reporting (complaint volume and resolution), Financial Cloud add-on (client-specific features) | Complaint management: regulatory requirement for formal complaint Cases | Integration: core banking, trading systems, credit bureaus

ROI components: Cost savings (handle time reduction × cases × agent cost), Deflection savings (deflected cases × cost/case), Churn prevention (retained customers × ARR × churn reduction %), License cost (annual Salesforce subscription), Implementation cost (one-time) | Typical ROI: break-even 12-18 months, 3-year ROI 200-400% | Measurement: before/after comparison on: FRT, resolution time, CSAT, agent count for same volume | Intangibles: brand reputation, employee satisfaction (agents prefer Service Cloud vs legacy)

Key limits: Cases per org: no limit (but list view/report performance degrades above 1M), Email message size: 25MB limit, Knowledge article size: 131KB HTML limit, Case attachment: 2GB per file, Omni-Channel agent pool: performance degrades above 1,000 agents | Performance tips: archive closed cases (Archive Cases feature), index custom case fields used in list views, avoid SOQL in Email-to-Case triggers (use @future), optimize Knowledge search indexes | Email-to-Case: 1,000 emails/day per routing address

E-commerce Service specifics: Order status integration (Shopify/Magento/Commerce Cloud → Cases), Return Merchandise Authorization (RMA) workflow, Chat for pre-purchase questions (conversion impact), Bot for order tracking (common inquiry), Case Types (Order Issue, Return, Shipping, Product Question, Billing), High volume (BFCM spikes), Integration: order management, shipping carriers, payment processors | BFCM prep: surge capacity, macros for common holiday issues, pre-built KB articles

Integration: Salesforce-Jira connector (AppExchange or Zapier/MuleSoft) | Fields mapped: Case Subject → Jira Summary, Case Description → Jira Description, Priority → Jira Priority, Product → Jira Component | Bidirectional: Jira status → Case Status, Jira comment → Case Comment | Escalation flow: Agent confirms bug → creates Jira ticket from Case → Engineering receives → investigates → fixes → deploys → Jira closed → Case updated → Customer notified | Aggregation: multiple cases linked to one Jira ticket (same bug)

KCS principles: (1) Create knowledge in the workflow (when solving case, not after), (2) Evolve content based on demand and usage, (3) Develop a knowledge base of collective experience, (4) Reward learning and collaboration, not just case closure | KCS practices: Capture (draft article from case), Structure (follow article template), Reuse (link existing article to case), Improve (update outdated article when encountered), Retire (flag outdated content) | Metrics: Article creation rate, Reuse rate, Quality score, Contribution by agent

Portal components: Knowledge search, Case submission form (Web-to-Case or Record Create), Case list (customer sees own cases), Account/profile management, Community forums (Peer-to-peer support), Einstein Bot, Live Chat widget | Experience Cloud: Lightning template for portal | Authentication: customer login (Salesforce login, SSO, social auth) | Branding: custom theme matching company brand | Licensing: Customer Community or Customer Community+ license per user or per login | Case deflection: primary goal of portal

CoE structure: SC Architect (technology strategy, integrations, architecture decisions), SC Admin (day-to-day configuration, user management, reports), SC Developer (Apex triggers, custom LWC, integrations), Business Analyst (requirements, UAT, agent liaison), Knowledge Manager (article lifecycle, quality, gaps), Data Analyst (dashboards, KPI tracking, insights) | Governance: change request → sandbox → UAT → production | Roadmap: quarterly roadmap aligned with business goals | Budget: annual Service Cloud investment plan

(1) Case lifecycle: status values, support process, record types | (2) Channel setup: Email-to-Case, Web-to-Case, Routing Addresses | (3) Omni-Channel: routing config, presence, capacity, skills-based | (4) Entitlements: process, milestones, business hours, compliance | (5) Knowledge: article lifecycle, data categories, KCS methodology | (6) Console: split view, macros, sidebar, 360 view | (7) Einstein: what each feature does, data requirements | (8) Reporting: key KPIs, CRM Analytics, CSAT measurement | (9) Rules: Assignment Rules, Escalation Rules, Auto-Response | (10) Automation: Flows, Macros, Bulk Macros