Service Desk가 서비스 회사를 어떻게 구했습니까? 또는 비즈니스가 성장하는 경우 어떻게 해야 합니까?

제 이름은 Daria이고 제품 분석가입니다. 우리 회사의 주요 제품은 수리 작업, 다양한 개체의 유지 관리 등 비즈니스 프로세스를 자동화하는 클라우드 플랫폼인 서비스 데스크입니다. 내 업무 중 하나는 우리 플랫폼을 고객의 비즈니스에 도입하는 과정에 참여하는 동시에 특정 회사의 세부 사항을 최대한 깊이 파고드는 것입니다.

우리 고객 중 하나인 Brant 서비스 회사가 어떻게 노동 집약적인 비즈니스 프로세스를 자동화했는지 말씀드리고 싶습니다. 회사는 고객 수와 이에 따른 서비스 요청이 급격히 증가하기 시작하자 우리 플랫폼을 선택했습니다. 사업이 활발히 발전하고 있습니다. 훌륭합니다. 문제점은 무엇입니까? 사실 유사한 일상적인 프로세스의 수가 급격히 증가하고 있으며 이러한 위험은 과소평가될 수 없습니다. 게다가 애플리케이션 수가 적었을 때 작동했던 것과 동일한 도구를 사용할 수 없다는 것이 분명해졌습니다.

친숙한가요?

그래서 구원의 이야기입니다.

그것은 서비스 회사 여러 당사자 간의 즉각적인 커뮤니케이션이 필요하기 때문에 플랫폼의 기능을 최대한 완벽하게 사용하십시오. 이 측면은 무엇입니까?

• 고객뭔가 고장난 사람
• 서비스 매니저, 신청서를 수락하고 집행자를 임명하고 그 구현을 제어합니다.
• 리드 엔지니어, 수행된 작업의 품질을 제어하고 복잡한 요청을 완료할 때 기술 지원을 제공합니다.
• 서비스 전문가, 누가 요점을 지적하고 문제를 해결할 것인가

회사 "브랜트"에 대한 정보

• 제공되는 서비스: 장비 수리 및 보증 서비스, 건설 및 설치 작업; 청소;
• 모스크바와 모스크바 지역에는 1000개 이상의 서비스 시설이 있습니다.
• 직원 수는 60명이 넘는 서비스 전문가입니다.
• 이 회사는 매달 4500개 이상의 지원서를 처리합니다.
• 이 텍스트에서는 Brant의 고객을 식별하기 위해 가명을 사용합니다. 이들은 다음과 같습니다: 연방 식료품점 체인 - "Polyanka"라고 부르겠습니다. 두 개의 약국 체인 - "닥터 A"와 "닥터 B" 통신 사업자 "Op Mobile"의 서비스 센터; 뿐만 아니라 여러 생산 시설;

각 주요 체인에서는 모든 애플리케이션 지원 작업이 회계 프로그램에서 수행되어야 한다고 주장했습니다. 상호작용의 자동화는 고객과 서비스 회사 모두에게 효과적이며, 종합 서비스 분야에서 정당화됩니다. 그러나 고객이 XNUMX명 이상인 경우 서비스 회사가 여러 프로그램을 동시에 수행하는 것은 어려움을 야기합니다.

Service Desk 도입 전의 모습

Polyanka 네트워크는 1C: MRO 프로그램을 사용합니다. "의사 A" - Intraservice 시스템을 통해 신청서를 제출합니다. "Doctor B" 및 "Op Mobile" - 자체 서비스 데스크를 통해. 오프라인 고객은 이메일, 전화 통화, WhatsApp 및 Viber를 통해 요청을 제출합니다.

접수된 모든 지원서는 엑셀 파일로 수집되었습니다. 한 번에 신청할 수 있는 수는 4개 이상일 수 있습니다. 이는 활성 신청일 뿐이지만 완료된 신청 기록도 저장해야 합니다.

요약 파일은 언제든 죽을 위기에 처해 있었고, 우리는 애플리케이션 데이터베이스를 잃지 않기 위해 끊임없이 복사본을 만들어야 했습니다. 모든 소스에서 애플리케이션을 수집하고 이를 Excel 파일로 전송하는 데는 엄청나게 오랜 시간이 걸렸습니다. 그리고 SMS 메시지, 이메일, Viber 및 WhatsApp을 통해 공연자에게 애플리케이션을 수동으로 보내야 했습니다.

이 경우 서비스 전문가에게 보낸 요청에는 구현에 필요한 최대 정보가 포함되어야 합니다. 신청서 작성 후 구현 및 사진 보고서에 대한 정보 수집이 필요했습니다. 그리고 그것을 저장할 다른 곳도 있습니다.

이러한 다중 채널 수신, 녹음 및 응용 프로그램 배포가 얼마나 어려웠는지 상상할 수 있습니다. 회사가 서비스를 제공하기 위해 새로운 고객을 확보하고 더 많은 전문가를 고용하고 있다는 점을 고려할 때 프로세스에는 자동화와 투명성 향상이 절실히 필요했습니다. 그러나 계약 조건에 따라 제공되기 때문에 클라이언트에게 편리한 방식으로 애플리케이션 작업을 거부하는 것은 불가능합니다.

이는 다음을 허용하는 별도의 시스템이 필요함을 의미합니다.

1. 모든 고객 시스템의 작업을 한곳에 수집합니다.
2. 다양한 형식으로 접수된 신청서를 표준화합니다.
3. 필요한 모든 정보와 함께 서비스 전문가에게 요청서를 제출합니다.
4. 신청서 실행에 대한 보고서를 받습니다.
5. 완료된 주문 내역을 저장합니다.

동시에 의사 소통 수단으로 전화 만 가지고있는 현장 직원 인 공연자에게도 편리해야합니다.

Service Desk 도입 이후의 상황

소프트웨어 제품 시장을 조사한 후 Brant는 HubEx 플랫폼이라는 시스템을 선택했습니다.

1단계: Excel 가져오기를 사용하여 모든 서비스 개체에 대한 데이터가 플랫폼으로 전송되었습니다(출시 당시에는 900개 이상이었음). 이제 각 개체에 대해 필요한 모든 정보가 개체의 웹 여권에 저장됩니다. 주소, 지도상의 위치 정보, 기술 문서, 연락처, 서비스 내역. 신청서를 즉시 완료하는 데 필요할 수 있는 모든 것.

2단계: - 공통 시스템에 애플리케이션 로딩이 빠르게 완료되었습니다. HubEx 시스템으로 가져오기는 두 번의 클릭만으로 이루어지며 이제 각 개체에 대한 모든 요청이 한 곳에 수집됩니다. 고객 시스템에서 애플리케이션을 수집하는 또 다른 방법은 이메일로 직접 애플리케이션을 수신하는 메커니즘을 설정하는 것입니다. 이 옵션은 플랫폼에서도 사용할 수 있습니다.

결과: Brant 파견 담당자는 하나의 프로그램에서 모든 요청을 확인하고 이를 현장 직원에게 배포합니다.

각 직원의 주머니에는 새로운 할당된 요청에 대해 알리는 모바일 애플리케이션이 포함된 전화기가 있습니다. 그리고 응용 프로그램 자체에서 전문가는 자신의 응용 프로그램의 현재 목록을 볼 수 있습니다.

중요한 점은 이제 응용 프로그램과 관련된 모든 통신이 전화 대화나 인스턴트 메신저를 통하지 않고 엄격하게 응용 프로그램 자체에서 이루어집니다.

이를 통해 요청 기록을 저장하고 각 요청에 대한 통신을 명확하게 분할하며 중요한 내용이 손실되지 않도록 할 수 있습니다. 계약자는 작업에 대한 추가 정보를 요청하거나, 지연을 보고하거나, 이전에 이 객체를 서비스한 적이 있는 다른 전문가와 같은 필요한 참가자를 토론에 초대할 수 있습니다.

이제 지원서를 다른 전문가에게 양도할 때 이전 조치에 필요한 모든 정보를 신입 직원이 사용할 수 있습니다.

따라서 서비스 데스크의 도입으로 Brant는 모든 프로젝트를 단일 시스템으로 통합할 수 있었습니다. 또한 회사를 망칠 위험이 있는 일상적인 프로세스가 크게 줄었습니다. 서비스 대상 수가 증가했음에도 불구하고 유사한 작업 수의 증가를 충당하기 위해 직원을 신규 직원으로 부풀릴 필요가 없었습니다.

출처 : habr.com