Đã đăng vào khoảng 5 giờ trước 20 phút đọc

[Salesforce Agentforce Sales Consultant 2026] Phần 3 — Consulting & Implementation Strategies (25%): Từ Business Requirement Đến Salesforce Solution

Ở Phần 2, chúng ta đã đi qua Sales Lifecycle và hiểu cách một doanh nghiệp vận hành từ Marketing, Lead, Opportunity cho đến Closed Won / Closed Lost, Forecast và Analytics.

Nhưng hiểu Sales Process mới chỉ là bước đầu.

Khi tham gia một dự án Salesforce thực tế, khách hàng hiếm khi nói:

“Hãy tạo cho tôi một Record-Triggered Flow trên Opportunity.”

Thứ chúng ta thường nhận được sẽ giống như:

“Sales Rep đang mất quá nhiều thời gian follow-up khách hàng.”

“Management không tin số liệu Forecast.”

“Salesforce đã triển khai nhưng Sales Team không chịu sử dụng.”

“Mỗi Region đang có một Sales Process khác nhau.”

Đây đều là Business Problems, chưa phải Salesforce Solutions.

Nhiệm vụ của Consultant là biến những Business Problems đó thành một Solution có thể triển khai.

Mental Model của Phần 3:

Đây cũng chính là bước chuyển lớn nhất từ tư duy Administrator sang Consultant:

Administrator thường được hỏi “How do we configure it?”

Consultant phải tìm ra “What should we build, why should we build it, and how do we know it succeeded?”

1. Discovery — Đừng thiết kế Solution quá sớm

Giả sử Sales Director nói:

“Tôi muốn Salesforce tự động Follow-up Lead.”

Phản xạ đầu tiên có thể là:

Flow.

Nhưng đó là một sai lầm phổ biến.

Chúng ta chưa biết:

Lead nào cần Follow-up?
Follow-up sau bao lâu?
Email hay Call?
Sales Rep hay hệ thống thực hiện?
Nếu Lead phản hồi thì sao?
Nếu Lead không phản hồi thì sao?
Có nhiều Sales Teams với quy trình khác nhau không?
Business Outcome mong muốn là gì?

Consultant cần thực hiện Discovery trước khi thiết kế Solution.

Discovery có thể bắt đầu bằng những câu hỏi:

Business

Business Problem hiện tại là gì?
Tại sao vấn đề này quan trọng?
Business Outcome mong muốn là gì?
KPI nào được sử dụng để đo thành công?

Process

Quy trình hiện tại diễn ra như thế nào?
Ai tham gia?
Có những exception nào?
Bottleneck nằm ở đâu?

Users

Ai sẽ sử dụng Solution?
User Groups nào có nhu cầu khác nhau?
Người dùng hiện đang gặp khó khăn ở đâu?

Data

Data hiện nằm ở đâu?
Data Quality như thế nào?
Có duplicate hoặc missing data không?
Có External Systems nào liên quan không?

Technology

Salesforce hiện đang được cấu hình như thế nào?
Có Automation nào đang tồn tại?
Có Integration hoặc AppExchange Solution nào không?
Có Technical Constraint nào cần xem xét?

Điểm quan trọng:

Discovery không phải là hỏi khách hàng muốn Salesforce Feature nào.

Discovery nhằm hiểu:

Business thực sự đang cố gắng giải quyết vấn đề gì?

2. Stakeholders — Hỏi đúng người quan trọng không kém hỏi đúng câu

Một dự án Sales Cloud có thể liên quan đến nhiều Stakeholders.

Ví dụ:

Stakeholder	Điều họ quan tâm
VP Sales	Revenue, Forecast, Pipeline
Sales Manager	Team Performance, Pipeline Review
Sales Rep	Productivity, Ease of Use
Marketing	Lead Quality, Campaign Performance
Sales Operations	Process, Data Quality, Reporting
IT	Security, Integration, Architecture
Executive Sponsor	ROI, Adoption, Business Outcome

Một lỗi phổ biến là chỉ Discovery với Management.

Ví dụ VP Sales nói:

“Salesforce đang hoạt động tốt, chỉ cần cải thiện Forecast.”

Nhưng khi nói chuyện với Sales Reps, Consultant phát hiện:

Sales Rep phải nhập cùng một thông tin vào 15 Fields.

Kết quả:

Poor User Experience → Low Adoption → Incomplete Opportunity Data → Unreliable Forecast

Vấn đề Forecast thực chất bắt nguồn từ User Experience và Adoption.

Đây là lý do Discovery phải có nhiều góc nhìn.

3. Current State và Future State

Một technique rất hữu ích trong Discovery là phân biệt:

Current State — AS-IS

Business đang hoạt động như thế nào hôm nay?

và:

Future State — TO-BE

Business muốn hoạt động như thế nào sau khi triển khai Salesforce?

Ví dụ:

AS-IS

Lead từ Website
      ↓
Marketing export CSV
      ↓
Gửi Email cho Sales Manager
      ↓
Manager phân Lead bằng Excel
      ↓
Sales Rep nhập Lead vào CRM
      ↓
Follow-up thủ công

Problems:

Duplicate Data.
Manual Work.
Slow Lead Assignment.
Không đo được Response Time.
Không có Single Source of Truth.

TO-BE

Lead Capture
      ↓
Salesforce
      ↓
Qualification / Routing
      ↓
Assigned Sales Rep
      ↓
Structured Follow-up
      ↓
Opportunity
      ↓
Analytics

Nhưng hãy chú ý:

Future State không có nghĩa automate mọi thứ.

Consultant phải xác định bước nào:

cần Automation;
cần Human Decision;
cần Approval;
cần AI;
hoặc không cần thay đổi.

4. Business Requirement ≠ Solution Requirement

Đây là distinction rất quan trọng.

Khách hàng nói:

“Chúng tôi cần một Flow để tự động assign Lead.”

Đây thực ra đã chứa một Solution.

Consultant nên quay lại Business Requirement:

New Leads cần được phân phối nhanh chóng đến Sales Rep phù hợp dựa trên Region.

Sau đó mới đánh giá Solution.

Có thể Solution là:

Lead Assignment Rules.
Flow.
Territory-related logic.
Custom Development.
Hoặc combination của nhiều capability.

Mental Model:

Business Requirement

Lead phải được assign nhanh và chính xác.

↓

Functional Requirement

System xác định Sales Rep dựa trên Lead Region.

↓

Solution

Salesforce capability phù hợp.

Đừng để Solution xuất hiện quá sớm trong Requirement.

5. Functional và Non-Functional Requirements

Không phải Requirement nào cũng mô tả một chức năng.

Functional Requirement

Mô tả:

System phải làm gì?

Ví dụ:

Khi Opportunity lớn hơn $100,000 chuyển sang Proposal, hệ thống phải yêu cầu Sales Manager Approval.

Hoặc:

Lead phải được Routing dựa trên Country.

Non-Functional Requirement

Mô tả những quality hoặc constraint mà Solution phải đáp ứng.

Ví dụ:

Security.
Performance.
Scalability.
Maintainability.
Availability.
Compliance.
User Experience.

Ví dụ Business nói:

“Sales Rep chỉ được xem khách hàng thuộc Region của mình.”

Đây không chỉ là một UI Requirement.

Nó liên quan trực tiếp tới:

Security Architecture

Một Solution có thể đáp ứng Functional Requirement nhưng vẫn là Solution tệ nếu:

khó maintain;
không scale;
security yếu;
user experience kém.

6. User Story — Biến Requirement thành thứ Project Team có thể xây dựng

Một cách phổ biến để mô tả Requirement là User Story.

Format:

As a [user], I want [capability], so that [business value].

Ví dụ:

As a Sales Manager, I want to see Opportunities expected to close this quarter so that I can identify Pipeline Risk before the Forecast Review.

Ba thành phần:

Who?

Sales Manager

What?

See Opportunities expected to close this quarter.

Why?

Identify Pipeline Risk before Forecast Review.

Phần Why rất quan trọng.

Một User Story chỉ nói:

“As a Sales Manager, I want a Dashboard.”

là chưa tốt.

Tại sao cần Dashboard?

Business Value là gì?

Nếu không biết Why, rất khó đánh giá Solution có thực sự giải quyết Problem hay không.

7. Acceptance Criteria — Khi nào Requirement được xem là hoàn thành?

User Story nói chúng ta muốn gì.

Acceptance Criteria xác định:

Điều kiện nào chứng minh Solution hoạt động đúng?

Ví dụ User Story:

As a Sales Manager, I want high-value Opportunities to require approval before a large discount is offered.

Acceptance Criteria có thể là:

Opportunity có Discount vượt threshold phải yêu cầu Approval.
Sales Rep không thể hoàn tất bước được kiểm soát trước khi Approval hoàn thành.
Sales Manager nhận được Approval Request.
Approval Result được lưu lại.
User phù hợp vẫn có thể xử lý exception theo Business Policy.

Acceptance Criteria giúp:

Business Requirement → Build → Test → Validation

có cùng một Definition of Done.

8. Requirement Traceability

Trong dự án lớn, chúng ta cần biết:

Requirement này đến từ đâu?

Solution nào đang giải quyết nó?

Test Case nào validate nó?

Một mental model đơn giản:

Business Objective
        ↓
Business Requirement
        ↓
User Story
        ↓
Salesforce Solution
        ↓
Test Case
        ↓
Business Outcome

Ví dụ:

Increase Lead Conversion
        ↓
Reduce Lead Response Time
        ↓
Automatically route Leads
        ↓
Lead Assignment Solution
        ↓
Test routing scenarios
        ↓
Measure Lead Response Time

Đây là Requirement Traceability.

Nó đặc biệt hữu ích khi:

Scope thay đổi.
Requirement bị loại bỏ.
UAT phát hiện vấn đề.
Stakeholder hỏi tại sao một Feature tồn tại.

9. Prioritization — Không phải Requirement nào cũng cần làm ngay

Một Project luôn có giới hạn:

Budget.
Time.
Resources.
Technical Complexity.
Business Readiness.

Do đó Consultant phải biết Prioritize Requirements.

Một framework phổ biến là:

MoSCoW

Must Have

Không có thì Solution không đáp ứng Business Need.

Should Have

Quan trọng nhưng Project vẫn có thể Go-Live nếu chưa có.

Could Have

Có giá trị nhưng không critical.

Won't Have — For Now

Không nằm trong Scope hiện tại.

Ví dụ:

Requirement	Priority
Lead Routing	Must
Opportunity Approval	Must
Executive Dashboard	Should
AI Email Generation	Could
Advanced Territory Optimization	Future Phase

Điểm quan trọng:

Priority phải dựa trên Business Value, Risk, Dependency và Effort — không phải Feature nào trông thú vị nhất.

10. Scope — Một trong những thứ Consultant phải bảo vệ

Một Project bắt đầu với:

Lead Management
Opportunity Management
Forecasting

Sau vài Workshop:

Lead Management
Opportunity Management
Forecasting
CPQ
Marketing Automation
Customer Service
Partner Portal
Agentforce
Data Warehouse
Mobile App

Đây là dấu hiệu của:

Scope Creep

Scope Creep có thể dẫn đến:

More Requirements → More Complexity → More Cost → More Testing → Longer Timeline → Higher Project Risk

Consultant không có nhiệm vụ nói “Yes” với mọi Requirement.

Consultant cần xác định:

In Scope.
Out of Scope.
Future Phase.
Dependency.
Change Request.

11. Solution Design — Từ Requirement đến Salesforce Capability

Sau Discovery và Requirement Analysis, chúng ta mới bắt đầu Solution Design.

Framework của series:

Business Requirement → Salesforce Concept → Solution → Why → Alternative → Trade-off

Ví dụ:

Requirement

Sales Manager muốn mọi Deal > $500K được Review trước khi Proposal được gửi.

Salesforce Concept

Approval / Process Control.

Possible Solution

Approval-related automation hoặc Flow-based process phù hợp với Requirement cụ thể.

Why?

High-value Deals cần Management Review.

Alternative

Custom Development.

Trade-off

Declarative Solution thường dễ maintain hơn, nhưng Complex Approval Logic có thể yêu cầu Design khác.

Điểm quan trọng:

Consultant không chỉ cần biết Solution nào hoạt động.

Consultant cần biết:

Tại sao Solution đó phù hợp hơn Alternative.

12. Declarative First — Nhưng không phải Declarative Only

Salesforce cung cấp rất nhiều Declarative Capabilities:

Flow.
Validation Rules.
Approval capabilities.
Assignment Rules.
Sharing Rules.
Record Types.
Lightning App Builder.
Reports & Dashboards.

Vì vậy Consultant thường nên xem xét Declarative Solution trước.

Nhưng:

Declarative First ≠ Declarative Only

Một Requirement có thể cần:

Apex.
Lightning Web Components.
External Integration.
Third-party Application.
Additional Salesforce Product.

Decision nên dựa trên:

Complexity.
Scalability.
Maintainability.
User Experience.
Security.
Cost.
Technical Debt.

Không phải:

“Flow làm được nên tất cả phải dùng Flow.”

13. Build vs Buy vs Extend

Một Consultant thường phải cân nhắc ba hướng.

Build

Tự xây bằng Salesforce Platform.

Ví dụ:

Flow.
Apex.
LWC.

Buy

Sử dụng Third-party Application từ AppExchange hoặc Vendor.

Extend

Sử dụng thêm Salesforce Product hoặc Integration.

Ví dụ:

Business Requirement

Sales Team cần Electronic Signature.

Các hướng có thể là:

Custom Build
      VS
AppExchange / E-signature Product
      VS
External Integration

Consultant phải cân nhắc:

Factor	Question
Cost	License hay Development cost?
Time	Bao lâu để triển khai?
Maintenance	Ai maintain?
Scalability	Có scale được không?
Security	Data được xử lý ở đâu?
UX	User phải làm bao nhiêu bước?
Integration	Có tương thích architecture hiện tại?

Exam thường không chỉ hỏi:

“Feature nào làm được?”

mà có thể hỏi:

Solution nào phù hợp nhất với Requirement và Constraint?

14. Project Management Lifecycle

Một Salesforce Implementation không chỉ có Build.

Mental Model:

Initiation
    ↓
Discovery
    ↓
Planning
    ↓
Design
    ↓
Build
    ↓
Test
    ↓
Deploy
    ↓
Adoption
    ↓
Measure
    ↓
Improve

Ở từng Phase, Consultant có trách nhiệm khác nhau.

Initiation

Xác định:

Business Goals.
Stakeholders.
High-level Scope.
Success Criteria.

Discovery

Hiểu:

Business Process.
Pain Points.
Requirements.
Current Systems.

Planning

Xác định:

Scope.
Timeline.
Resources.
Risks.
Dependencies.

Design

Chuyển Requirements thành Salesforce Solution.

Build

Configure / Develop Solution.

Test

Validate rằng Solution đáp ứng Requirements.

Deploy

Đưa Solution đến Production.

Adoption

Training và hỗ trợ Users sử dụng Solution.

Measure

Đo Success Metrics.

Improve

Tiếp tục cải tiến Solution.

Project thành công không phải khi:

Deployment succeeded.

Project thành công khi:

Business Outcome được cải thiện.

15. Testing — “It Works” chưa đủ

Consultant cần hiểu nhiều lớp Testing.

Ví dụ:

Functional Testing

Feature có hoạt động đúng Requirement không?

Integration Testing

Các Systems có hoạt động đúng với nhau không?

Regression Testing

Change mới có làm hỏng Functionality cũ không?

User Acceptance Testing — UAT

Business Users xác nhận Solution có đáp ứng Business Requirements không?

UAT đặc biệt quan trọng.

Developer có thể nói:

“Flow chạy đúng.”

Nhưng Sales Manager có thể nói:

“Process này không phù hợp với cách Team tôi bán hàng.”

Technical Success ≠ Business Success.

16. Deployment — Không phải chỉ bấm Deploy

Exam Guide yêu cầu Consultant hiểu Deployment Considerations.

Trước Deployment cần cân nhắc:

Data Migration.
Configuration Dependencies.
Integration.
User Access.
Testing.
Training.
Communication.
Deployment Sequence.
Rollback / Recovery Plan.
Production Readiness.

Một Change có thể Technical rất nhỏ nhưng Business Impact rất lớn.

Ví dụ:

Thay Opportunity Stages.

Có thể ảnh hưởng:

Sales Process.
Probability.
Forecasting.
Reports.
Dashboards.
Automation.
Training.
Historical interpretation.

Vì vậy:

Technical Change Size ≠ Business Change Size

17. Change Management — Salesforce không tự tạo Adoption

Đây là một phần cực kỳ quan trọng của domain này.

Giả sử Project hoàn thành:

Data Model tốt.
Automation tốt.
Dashboard tốt.
Security tốt.

Nhưng Sales Reps không sử dụng Salesforce.

Project có thành công không?

Không.

Adoption phải được xem xét trước Implementation, không phải sau Go-Live mới bắt đầu nghĩ tới. Exam Guide hiện tại cũng yêu cầu candidate đánh giá User Experience, Communication Plan, Training, Change Management và Success Metrics trước implementation.

Một Change Management Plan có thể bao gồm:

Stakeholder Alignment
        ↓
Communication
        ↓
Training
        ↓
Go-Live Support
        ↓
Adoption Monitoring
        ↓
Feedback
        ↓
Continuous Improvement

18. Training — Không phải tất cả User đều cần học giống nhau

Một lỗi phổ biến:

Tạo một buổi Training 3 tiếng cho toàn bộ công ty.

Nhưng nhu cầu của từng User Group khác nhau.

Sales Rep

Cần biết:

Manage Leads.
Update Opportunities.
Activities.
Products / Quotes.
Daily workflow.

Sales Manager

Cần biết:

Pipeline.
Forecast.
Reports.
Dashboards.
Team Performance.

System Administrator

Cần biết:

Configuration.
User Management.
Troubleshooting.
Maintenance.

Training nên:

Role-based + Process-based

thay vì:

Feature-based

Đừng dạy:

“Đây là Opportunity Tab.”

Hãy dạy:

“Đây là cách chúng ta quản lý một Deal từ Qualification đến Close.”

19. User Adoption — Go-Live không phải Finish Line

Sau Deployment, Consultant phải quan sát:

Users có thực sự sử dụng Solution không?

Một số Adoption Metrics có thể là:

Login Frequency.
Records Created.
Opportunities Updated.
Activities Logged.
Required Field Completion.
Dashboard Usage.
Data Quality.
Process Compliance.

Nhưng phải cẩn thận:

Login Count cao không tự động nghĩa là Adoption tốt.

Một User có thể Login mỗi ngày nhưng vẫn quản lý Pipeline bằng Excel.

Adoption phải liên kết với Business Process.

Ví dụ:

Bad Metric

95% Sales Reps logged in this month.

Better Question

Bao nhiêu Opportunities đang được cập nhật Stage, Amount và Close Date đúng theo Sales Process?

20. Khi Adoption thấp, đừng mặc định vấn đề là Training

Đây là một Exam Mindset rất quan trọng.

Low Adoption có thể đến từ:

User Experience

Quá nhiều Fields hoặc Clicks.

Process

Salesforce Process không phù hợp Business Process.

Performance

System chậm.

Data Quality

Users không tin Data.

Training

Users không biết cách sử dụng.

Change Management

Users không hiểu tại sao Process thay đổi.

Leadership

Managers không sử dụng Salesforce trong Pipeline Review.

Duplicate Work

Users phải nhập Data vào nhiều Systems.

Mental Model:

Low Adoption
     ↓
WHY?
     │
     ├── UX Problem?
     ├── Process Problem?
     ├── Training Problem?
     ├── Data Problem?
     ├── Performance Problem?
     ├── Leadership Problem?
     └── Duplicate Work?

Do đó:

Low Adoption ≠ Automatically More Training

Phải tìm Root Cause.

21. Success Metrics — Làm sao biết Project thành công?

Trước Implementation, Consultant cần xác định:

Chúng ta sẽ đo thành công bằng gì?

Ví dụ Project Objective:

Improve Lead Management.

Success Metrics có thể là:

Lead Response Time.
Lead Conversion Rate.
Percentage of Leads Followed Up.
Qualified Lead Volume.

Project Objective:

Improve Forecast Accuracy.

Metrics có thể liên quan đến:

Opportunity Data Completeness.
Close Date Accuracy.
Pipeline Hygiene.
Forecast Variance.
Forecast Review Compliance.

Mental Model:

Business Objective
        ↓
Success Metric
        ↓
Baseline
        ↓
Implementation
        ↓
Measure Again
        ↓
Compare

Nếu không có Baseline, rất khó chứng minh Solution đã tạo ra Improvement.

22. Continuous Improvement

Salesforce Implementation không phải:

Project
  ↓
Go-Live
  ↓
Finished

Thực tế nên là:

Discover
   ↓
Design
   ↓
Implement
   ↓
Measure
   ↓
Feedback
   ↓
Improve
   │
   └────────► Discover

Sau Go-Live:

Business Requirements thay đổi.
Users đưa Feedback.
Salesforce Releases Features mới.
Sales Process thay đổi.
Company mở rộng.
Data Volume tăng.
AI Use Cases xuất hiện.

Solution phải tiếp tục evolve.

Đây là lý do Exam Guide đề cập trực tiếp tới:

changing business requirements

và:

continuous improvement

trong Post-Implementation.

23. Exam Mindset — Business Problem trước, Technology sau

Hãy xem một Scenario.

Sales Reps phàn nàn rằng Opportunity Page có quá nhiều Fields và mất nhiều thời gian cập nhật. Vì vậy nhiều Rep không cập nhật Opportunity thường xuyên, khiến Forecast không chính xác.

Một cách suy nghĩ tệ:

Forecast không chính xác → Configure Forecasting.

Nhưng hãy trace Root Cause:

Bad Forecast
      ↑
Incomplete Opportunity Data
      ↑
Sales Reps don't update records
      ↑
Poor User Experience
      ↑
Too many unnecessary fields

Problem thực sự nằm ở:

User Experience / Process Design / Adoption

không nhất thiết nằm ở Forecast Configuration.

Đây chính là kiểu reasoning Consultant Exam muốn kiểm tra.

24. Một Scenario hoàn chỉnh

Hãy ghép toàn bộ Phần 3 vào một Case.

Business Problem

VP Sales nói:

“Forecast của chúng tôi thường sai và Sales Managers không tin Salesforce.”

Discovery

Consultant phỏng vấn:

VP Sales.
Sales Managers.
Sales Reps.
Sales Operations.

Phát hiện:

Reps update Opportunity một lần mỗi tuần.
Close Date thường không chính xác.
Stage Definitions không rõ ràng.
Managers sử dụng Excel để Review Pipeline.
Salesforce có quá nhiều Required Fields.

Root Cause

Không phải đơn giản:

Forecast Feature chưa tốt.

Mà là:

Poor Sales Process
       +
Poor User Experience
       +
Low Adoption
       ↓
Poor Opportunity Data
       ↓
Unreliable Forecast

Requirements

Define clear Opportunity Stages.
Reduce unnecessary Fields.
Establish Pipeline Review Process.
Improve Opportunity Data Quality.
Configure Forecasting phù hợp Business Process.
Train Managers và Sales Reps.
Define Forecast Success Metrics.

Solution

Có thể bao gồm:

Sales Process.
Page Layout / Lightning Record Page.
Validation / Automation khi phù hợp.
Forecast Configuration.
Reports & Dashboards.
Training.
Adoption Monitoring.

Success Metrics

Sau Go-Live:

Opportunity Update Frequency tăng.
Close Date Accuracy cải thiện.
Data Completeness tăng.
Managers chuyển Pipeline Review từ Excel sang Salesforce.
Forecast Variance giảm.

Đây mới là một:

Salesforce Consulting Solution

chứ không đơn thuần là một Configuration.

25. Các Exam Trap cần nhớ

Trap 1 — Requirement ≠ Solution

Customer nói:

“We need a Flow.”

Đừng mặc định Flow là Requirement.

Hãy tìm Business Need phía sau.

Trap 2 — Discovery ≠ Feature Demo

Discovery không phải buổi trình diễn Salesforce Features.

Mục tiêu là hiểu:

Business Goals + Process + Pain Points + Users + Data + Constraints

Trap 3 — Go-Live ≠ Project Success

Deployment thành công chỉ chứng minh:

System đã được đưa lên Production.

Không chứng minh:

Business Outcome đã đạt được.

Trap 4 — Low Adoption ≠ Training Problem

Training chỉ là một trong nhiều nguyên nhân.

Hãy tìm Root Cause.

Trap 5 — Functional Requirement ≠ Toàn bộ Requirement

Security, Performance, Scalability, Maintainability và UX cũng cần được xem xét.

Trap 6 — Declarative First ≠ Never Code

Declarative thường nên được xem xét trước.

Nhưng Complex Requirements có thể cần Custom Development hoặc Integration.

Trap 7 — Build ≠ Luôn tốt hơn Buy

Một AppExchange Solution phù hợp có thể giảm Development và Maintenance.

Nhưng cần cân nhắc Cost, Security, Integration và Vendor Dependency.

Trap 8 — Automation ≠ Better Process

Automating một Process tệ chỉ có thể khiến:

Bad Process chạy nhanh hơn.

Trước Automation:

Fix / understand the Process.

26. Consultant Thinking Framework

Nếu chỉ nhớ một Diagram từ bài này, hãy nhớ Diagram sau:

BUSINESS PROBLEM
       ↓
DISCOVERY
       ↓
CURRENT STATE
       ↓
ROOT CAUSE
       ↓
BUSINESS REQUIREMENTS
       ↓
USER STORIES
       ↓
PRIORITIZATION
       ↓
SOLUTION DESIGN
       ↓
IMPLEMENTATION
       ↓
TESTING
       ↓
DEPLOYMENT
       ↓
ADOPTION
       ↓
SUCCESS METRICS
       ↓
CONTINUOUS IMPROVEMENT
       │
       └──────────────► DISCOVERY

Và trong mỗi Solution Decision:

Business Requirement
        ↓
Salesforce Concept
        ↓
Solution
        ↓
Why?
        ↓
Alternative?
        ↓
Trade-off?
        ↓
Risk?
        ↓
How do we measure success?

Đây chính là mindset xuyên suốt của một Salesforce Consultant.

Tổng kết

Consulting & Implementation Strategies không phải một domain để học thuộc Salesforce Features.

Nó kiểm tra khả năng biến:

Business Problem → Salesforce Solution

Một Consultant cần biết:

Conduct Discovery.
Identify Stakeholders.
Understand Current State và Future State.
Analyze Business Requirements.
Write User Stories và Acceptance Criteria.
Prioritize Requirements.
Manage Scope.
Design Solutions.
Evaluate Alternatives và Trade-offs.
Understand Project Lifecycle.
Plan Testing và Deployment.
Prepare Communication và Training.
Drive User Adoption.
Measure Business Success.
Continuously Improve the Solution.

Mental Model cuối cùng:

Discover → Understand → Prioritize → Design → Implement → Adopt → Measure → Improve

Nếu Phần 2 trả lời:

“Doanh nghiệp bán hàng như thế nào?”

thì Phần 3 trả lời:

“Consultant biến nhu cầu của doanh nghiệp thành Salesforce Solution như thế nào?”

Ở Phần 4, chúng ta sẽ chuyển từ Consulting Mindset sang phần Solution Design thực chiến hơn:

Practical Application of Agentforce Sales Expertise (24%) — Thiết kế Sales Solution từ Lead → Opportunity → Quote → Close và lựa chọn đúng Salesforce Capability cho từng Requirement.

Tài liệu tham khảo chính thức

Tip: Đối với domain này, đừng chỉ học Salesforce Configuration. Hãy tập thói quen đọc mỗi Scenario theo thứ tự Business Goal → Root Cause → Requirement → Solution → Adoption → Success Metric.