Salesforce를 경험해 볼 기회가 있어서 Trailhead를 따라 이것저것 만져보고 있다.
내가 DBA가 되어 제공해주는 예제 수준의 DB를 다양하게 시험해 봤다. DBMS 인것 같으면서 더존의 ERP 느낌도 물씬 났던 녀석이다. 무엇보다 DB 관점에서 본다면 기본적으로 제공을 해주는 기능들이 워낙 강력하여 별도 SQL이나 코딩 없이도 왠만하 기능을 구현 할 수 있었다. 무엇보다 이미 타겟 client가 기업이기 때문에 기업전용 기능을 제공을 하여 편하게 사용 할 수 있었다. 지금부터 이러한 Salesforce가 가지는 몇가지 특징을 살펴 보겠다.
Standard Object
부트캠프 과정에서 처음 인터넷 쇼핑몰을 만들때 작성했다 릴레이션 스키마이다. 당시 우리는 패션관련 쇼핑몰을 만들었고 다른 조들은 캠핑, 도서대여, 농산물 공동구매 등의 Identity를 살려서 프로젝트를 진행을 했지만 다른 조와 우리조의 ERD 또는 릴레이션 스키마를 봤을 때 그렇게 차이가 나는건 없었다. 왜일까?
프로젝트의 주제는 달랐지만 결국에는 모두가 하나의 쇼핑몰이기 때문에 회원, 주문, 상품 등 의 관계가 크게 달라지지 않는 것이다. 당시 우리 과정에서 이러한 DB 설계에 주어진 시간은 약 일주일 이었다. 짧으면 짧고 길면 긴 시간이었지만 만일 실무에서 하나의 서비스를 처음부터 끝까지 만든다고 했을 때 DB 설계 비용도 만만치 않을것이다.
그렇다면 우리는 여기서 한가지 생각을 할 수가 있다. 만일 공통적으로 사용하는 Entity를 미리 만들어 놓고 제공을 한다면 어떨까?
세일즈포스는 이러한 점을 착안하여 기업에서 많이 사용하는 Entity(Salesforce에서는 Object라고 부른다) 제공한다. 그리고 이것이 Standard Object이다.
위는 Salesforce에서 기본적으로 제공하는 Standard Object의 관계도를 그린것이다. 복잡한 관계의 오브젝트를 미리 제공을 해줌으로써 개발자는 보다 쉽게 서비스를 구축 할 수 있게 됐다.
Standard Objects | Object Reference for the Salesforce Platform | Salesforce Developers
developer.salesforce.com
위의 링크는 salesforce에서 기본적으로 제공해주는 Standard Object이다. 이 모든걸 다 알면 좋겠지만 일단은 자주 쓰는 object가 뭐고 특징이 뭔지 살펴보자
Account
비즈니스와 관련된 조직 또는 개인을 나타내는 object이다. 가장 기본이 되는 object로 다양한 object들과 관계를 맺고 있다.
쉽게 생각하면 company를 떠올렸을 때의 정보 filed 등이 있다. 인상 깊은 점은 모회사와 자회사 개념을 도입하기 위해 부모 Account가 자식 Account와 1:N 관계를 맺어 질 수도 있다라는 점이다.
Contact
Account와 부모 자식의 계층적 Object이다. 해석하면 연락처지만, Account에서 일하는 사람이라고 기억하는게 더 쉽다. CRM 플랫폼 답게 LastActivityDate, LastReferencedDate, LastViewedDate, LeadSource 등의 필드가 인상싶다. Leadsource은 유입이 어떻게 됐는지이다.
Opportunity
한국말로 기회지만 단순 기회라고 생각하면 와닿지가 않는다. 일종의 계약 현황이라고 보면 이해가 훨씬 빠르다. StageName이라는 필드가 있어서 현재 잠재고객의 현황을 기록을 한다.
예를 들면
- 발견(Prospecting): XYZ Corp가 ABC IT 솔루션에 연락을 하여 클라우드 전환 프로젝트에 대해 논의하기 시작함. 이 단계에서는 잠재 고객이 아직 확실히 구매할 의향이 있는지 모르는 상태입니다.
- 요구사항 분석(Needs Analysis): XYZ Corp의 IT 인프라 현황과 요구 사항을 분석한 후, 클라우드로 전환하는 데 필요한 사항들을 파악함.
- 제안서 제출(Proposal/Price Quote): XYZ Corp에 클라우드 전환 솔루션에 대한 제안서와 견적서를 제출함. 현재 예시에서는 이 단계에 해당함.
- 협상 중(Negotiation/Review): 현재 고객과의 협상이 진행 중이며, 가격이나 서비스 범위에 대한 조율이 이루어지고 있음.
- Closed Won(계약 체결): XYZ Corp와 계약을 성공적으로 체결하여, 클라우드 전환 프로젝트가 시작됨.
- Closed Lost(계약 실패): 경쟁업체가 이겼거나 고객이 구매를 보류한 경우로, 기회를 잃었음.
보통 이렇게 단계를 두어 probability 필드에 계약 성공률을 채워나간다. 이 Opportunity Object를 봄으로써 현재 회사의 영업 진행 상황을 알 수가 있게 된다.
또한 Salesforce 칸반보드 기능을 제공을 하기 때문에 각 Stage 별 상황을 한눈에 볼 수 있다.
Lead
Lead object는 잠재고객을 관리하는 object로써 Opportunity의 전단계라고 생각하면 이해하기 쉽다. 앞서 Opportunity object는 일종의 계약 진행상황이라고 표현했다. 이러한 계약을 진행을 하려면 사전의 물밑 작업을 해야한다.
A라는 영업사원이 **회사의 구매담당자 B에게 제품을 소개를 하면서 계약을 유도 했다라고 가정해보자. B는 A의 영업이 마음에 들어 계약을 하겠다고 A한테 의사표현을 하게 되면 A는 해당 Lead를 Account, Contact, Opportunity로 convert하게 된다. B는 영업의 기회가 되는 것이다.
또한 Lead object에서 To do list처럼 Task를 추가하여 잠재고객을 보다 쉽게 관리할 수 있다.
Lead object는 Opportunity Object의 StageName처럼 단계를 표시하는 Status filed가 있다.
- New (신규): 리드가 처음 들어온 상태.
- Contacted (연락됨): 연락을 시도했거나 대화가 시작된 상태.
- Qualified (자격 확인): 고객으로 전환할 가능성이 있다고 판단된 상태.
- Closed (종료): 자격이 없거나 구매 의사가 없어 리드가 종료된 상태.
만일 다음과 같은 Status가 있고 현 Lead object의 record의 status가 Qualified(자격 확인)라 한다면 Account, Contact, Opportunity로 Convert하게 된다.
Contract
Opportunity object가 계약현황을 의미한다고 했으면 Contract는 어떤 Object일까? Contract Object는 실제로 법적 구속력을 갖는 필드를 가지고 있는 object이다.
- ActivatedDate : 계약서가 언제 활성화 됐는지,
- CompanySignedDate : 회사 사인 날짜
- ContractTerm : 계약서 유효기간
- CustomerSignedDate : 고객 사인 날짜
등 구체적인 term과 날짜를 명시하는 필드들로 구성이 되어 있다. 즉 Opportunity에서 성공적으로 stage가 done이 되면 그 이후에 Contract 단계를 진행해서 record에 기록을 한다.
Asset과 Case
여기서 Asset은 기업의 재무제표나오는 자산이 아닌 본 기업으로부터 구매한 소프트웨어나 자동차, PC 등의 물품을 의미한다.
만일 Account가 우리 회사로부터 A라는 소프트웨어를 구입을 했다라고 가정해보자. 가장 베스트는 문제가 없는거지만 이 A라는 소프트웨어에 다양한 문제가 발생 할 수가 있다. 이러한 문제 사례를 Case object에 기록하게 된다
하나의 Asset에 N개의 Case가 나올 수 있으며로 Asset과 Case는 1:N 관계이다.
Case 같은 경우 에스컬레이션 조건이라든지 대기열 생성 기능을 Salesforce에서 제공한다.
'Salesforce' 카테고리의 다른 글
| 보안과 접근 권한 설정 (0) | 2024.08.29 |
|---|
