최근 같이 일했던 고객이 내가 플젝에서 없어선 안될 중요한 기여를 해줬고, 만들어준 시스템도 잘 돌아가서 모두 흡족해한다면서 칭찬 메일을 보내왔다. 그러면서 내 프랙티스 리드를 참조하는 걸 잊지 않았다(센스장이). 내 매니져는 그걸 다시 칭찬하면서 프랙티스 리드를 참조하고.. 이건 결국 다음번 퍼포먼스 리뷰시 반영될 것이다.

기분은 좋으나 사실을 고백하면 이번 고객에게 내가 투자한 노력은 그닥 크지 않았다. 집에서 쉬엄쉬엄하면서 끝냈기 때문에 나로서도 굉장히 편안하게 진행했고, 오히려 부업을 겸할 여유까지 있었다. 대신 일의 경과에 대한 리포트를 고객의 눈높이에서 하는데 좀 더 신경 썼다.

아직 이슈는 없지만 버그가 아예 없진 않을거다. 조만간 뭐가 안되니 지원해 달라고 요청이 올거라 본다. 그래도 중요한건 고객이 내게 가진 호감과 신뢰다.

그래서 또다시 느낀다. 고객의 만족도는 서비스의 질 그 자체가 아니라, 서비스 제공자를 보는 고객의 관점, 인상 등에 따라 최종 결과물에 대한 평가도 달라진다는 거. 아니, 최종 결과물로 평가받는게 아니라 과정까지 포함한 ‘서비스’가 중요하다는 것이다.

개발자가 개발만 잘하면 되지, 라고 생각하면 커뮤니케이션이나 프리젠테이션에 소홀해진다. 이건 죽도록 고생해서 아무도 안알아주는 기술적으로 완벽한 솔루션을 만들어놓고 좋은 소리 못듣는 길이다.

아래는 ITIL 트레이닝을 받으면서 배운건데 꽤 도움이 된다.

Satisfaction is about PERCEPTION. So, it is not about real objective quality of service, it is about how customer sees that quality. There are cases when a customer sees the service much better than it is, and also, sometimes the service is perceived much worse than it is in reality, usually due to bad communication, or a few isolated cases that gained higher visibility.

ITIL Foundation v3 시험치느라 벼락치기한 결과 다른건 다 잊어먹었어도 이거 하나는 남았다. ITIL 을 도입하는 주요 의의중 하나가 고객 만족도 관리이고 보면 이거 하나만 기억해도 나쁘지 않을 것 같다.

기억하자. 잘 만드는것만큼 중요한게 고객의 만족도 관리다.