2025년 12월 16일·7분
SAP Concur와 임베디드 워크플로우: 유지 엔진
SAP Concur가 여행·비용을 일상 프로세스에 어떻게 임베드해 도입률과 갱신을 높이는지, 그리고 SaaS 팀이 유지율을 높이기 위해 무엇을 모방할 수 있는지 확인해보세요.
SAP Concur가 여행·비용을 일상 프로세스에 어떻게 임베드해 도입률과 갱신을 높이는지, 그리고 SaaS 팀이 유지율을 높이기 위해 무엇을 모방할 수 있는지 확인해보세요.
“프로세스 임베딩”은 SaaS 제품이 단순히 가끔 로그인하는 도구가 아니라 반복되는 비즈니스 프로세스가 실질적으로 끝까지 실행되는 장소가 되는 상황을 말합니다. 소프트웨어는 더 이상 ‘앱’ 같지 않고 ‘우리가 일을 처리하는 방식’처럼 느껴집니다.
실무적으로 프로세스 임베딩은 제품이 다음을 수행한다는 뜻입니다:
이 단계들이 여러 직원에게 매주 반복되면 소프트웨어는 회사의 운영 리듬의 일부가 됩니다.
T&E는 높은 빈도로 반복되는 워크플로우입니다: 직원은 출장하고, 돈을 쓰고, 비용을 제출하고, 환급을 받습니다—이 과정이 계속 반복됩니다. 관리자는 승인하고, 재무는 감사하고 장부를 마감합니다. 경영진은 지출과 정책 준수를 가시적으로 원합니다.
이 반복성은 유지에 중요합니다. 시스템이 부서 전반에서 지속적으로 사용되면 갱신 결정은 단지 누군가가 UI를 좋아하는지 여부가 아니라 비즈니스가 중단 없이 돌아갈 수 있는지에 따라 좌우됩니다.
이것은 SAP Concur의 숨은 비밀을 폭로하는 글이 아닙니다. 대신 전달 가능한 교훈들을 제공합니다: 왜 임베디드 워크플로우가 더 잘 유지되는지, 진짜 교체 비용을 만드는 것은 무엇인지, 그리고 기업 채택이 시간이 지나면서 어떻게 누적되는지.
우리는 임베딩이 유지에 기여하는 네 가지 요소에 초점을 맞출 것입니다:
여행 및 비용은 단일 작업이 아니라 전체 출장에 걸친 작은 결정과 인계의 연쇄입니다. 제품이 각 지점에 존재하면 ‘비용 도구’가 아니라 우리 회사의 여행 방식처럼 느껴집니다.
대부분 조직은 보통 다음 경로를 따릅니다:
각 단계는 사람들을 같은 시스템으로 다시 끌어들이는 터치포인트입니다. 예약은 출장 전 참여를 유도하고, 모바일 캡처는 출장 중 지속적으로 사용하게 하며, 제출과 승인은 출장 후 리듬을 만들고, 환급 및 조정은 재무가 여행자보다 훨씬 이후까지 관련되게 합니다.
이 워크플로우는 인터페이스 선호도와 무관한 여러 ‘되돌아올 이유’를 만듭니다. 직원은 보고서를 완료하고 환급을 받기 위해 돌아오고, 관리자는 승인 대기 항목이 쌓이기 때문에 돌아오며, 재무는 정확한 코딩과 감사 추적, 깔끔한 내보내기가 월말 업무에 미치는 영향을 이유로 시스템을 사용합니다.
시간이 지나면 이전 출장 기록, 빈번한 경로, 선호 호텔, 비용 센터, 프로젝트 코드, 과거 예외들이 쌓입니다. 이러한 문맥은 제품을 더 빠르고 친숙하게 만들어서 교체 비용을 은근히 높입니다.
다음 순간들이 조직 전반에서 흔히 문제를 일으킵니다:
워크플로우 도구는 이러한 지연을 줄일 때 신뢰를 얻습니다. 단계를 늘릴 때가 아니라 줄일 때 신뢰가 생깁니다.
T&E는 서로 다른 인센티브를 가진 여러 이해관계자에게 영향을 줍니다:
단일 워크플로우가 이들 모두를 연결할 때 갱신은 개별 사용자뿐 아니라 조직 전체의 영향을 받습니다.
SAP Concur가 ‘붙는’ 이유 중 하나는 규정을 별도의 작업으로 취급하지 않는다는 점입니다. 대신 여행 및 비용 정책이 직원이 이미 거치는 단계—예약, 제출, 승인, 환급—속에 코드화되어 있습니다.
정책 규칙이 워크플로우에 내장되면 시스템은 문제가 커지기 전에 방지하거나 플래그를 세울 수 있습니다: 지출 한도, 영수증 요구, 마일리지 규칙, 일당 상한, 승인 체인, 프로젝트 또는 비용 센터 규칙 등. 이는 “이게 허용되나요?”라는 수동 판단의 필요성을 줄이고 직원·관리자·재무 간 이메일 스레드를 줄입니다.
영향은 단지 규정 위반 건수 감소뿐만 아니라 지연 감소입니다. 규칙이 명확하고 일관되게 집행되면 사람들은 ‘운에 맡기기’를 멈추고 바로 진행되는 보고서를 제출합니다.
선호 항공사/호텔, 협상 요금, 허용되는 예약 등급, 식대 한도 같은 안내는 사용자를 정책에 맞는 옵션으로 유도합니다. 직원이 여행 정책의 전문가가 될 필요 없이 제시된 선택을 따르면 됩니다.
시간이 지나면 이러한 안내는 팀과 지역 전반의 지출 행동을 표준화합니다. 재무는 이상값을 덜 보고, 결재자는 난처한 결정을 덜 내리며, 직원은 환급을 받는 가장 빠른 경로를 학습합니다.
재무가 시스템이 정책을 일관되게 적용할 수 있다고 신뢰하면 그 도구는 잃고 싶지 않은 통제 지점이 됩니다. 이는 갱신에 중요합니다: 최종 사용자가 워크플로의 일부에 불만이 있더라도 재무는 예측 가능한 감사, 깔끔한 데이터, 적은 예외를 높게 평가합니다.
대부분 직원은 기본 경로를 따릅니다. 기본 경로가 규정을 준수하고 가장 쉽다면 준수는 습관이 됩니다. 그 습관은 미묘한 스위칭 비용을 만듭니다: 도구를 바꾸면 조직에 '정상'이 무엇인지 다시 가르쳐야 하고 일시적인 예외, 분쟁, 감사 업무 증가를 감수해야 합니다.
여행 및 비용 관리는 비용을 제출하는 사람들만으로 갱신이 결정되지 않습니다. 워크플로우가 일상 업무에 임베드되어 있으면 그로 인해 일이 쉬워지거나 어려워지는 모든 이들이 영향을 미칩니다.
갱신 압박을 이해하는 유용한 방법은 각 그룹이 무엇을 이루려 하는지, 그리고 그들에게 성공이 무엇인지 매핑하는 것입니다:
시스템이 이 작업들을 동시에 해결하면 갱신은 'UI가 마음에 드는가'가 아니라 '이 없이는 비즈니스 운영이 가능한가'라는 질문이 됩니다.
직원은 출장 후에만 비용을 제출할 수 있지만 관리자는 팀이 지출할 때마다 지속적으로 개입합니다. 승인 대기열은 드문 이벤트가 아니라 일상 루틴이 됩니다.
시간이 지나면 관리자들은 워크플로우를 내부화하고(위임 규칙, 알림, 에스컬레이션, 모바일 승인), 조직은 응답 시간과 책임에 대한 기대를 구축합니다.
재무 팀은 다운스트림 영향 때문에 가장 강력한 갱신 지지자가 되는 경향이 있습니다:
이 통제가 일상화되면 다른 시스템으로 바꾸는 것은 불확실성과 추가 월말 작업을 다시 도입하는 것처럼 느껴집니다.
IT는 제품을 매일 쓰지 않을 수 있지만 리스크를 관리합니다. SAP Concur가 기존 아이덴티티 및 접근 패턴(SSO, 역할 기반 권한, 자동 프로비저닝)에 맞으면 IT는 비정기 요청과 자격 증명 관리를 덜 하게 됩니다.
지원 부하와 보안 노출의 감소는 갱신의 강력한 배후 요인입니다—IT는 종종 엔터프라이즈 시스템 교체의 게이트키퍼이기 때문입니다.
T&E 도구는 독립형 앱이 아니라 재무 운영의 연결된 일부가 될 때 훨씬 더 '붙습니다'. 통합은 T&E 활동을 회계 준비된 거래로 바꾸고, 직원 데이터를 동기화하며 수작업 조정을 줄입니다—이점은 사용자가 빠르게 체감하고 재무 팀은 시간이 흐르며 의존하게 됩니다.
대부분의 임베디드 T&E 워크플로우는 몇 가지 핵심 시스템에 연결됩니다:
각 통합은 이중 입력을 줄이고 과제가 아닌 하나의 연속 흐름처럼 느껴지게 합니다.
가치는 명확합니다: 오류 감소, 빠른 마감, 정보 추적 시간 단축. 유지 효과는 덜 명백하지만 강력합니다.
T&E가 재무 게시 규칙, 승인 계층, 카드 피드, 환급 프로세스와 연결되면 시스템 교체는 단순 UI 변경이 아니라 의존성의 그물을 재작업하는 것이 됩니다.
이것은 계약적 비용이 아니라 운영적 스위칭 비용을 만듭니다: GL 매핑 테스트, 결재자 재교육, 환급 타이밍 검증, 감사 추적의 무결성 보장 등.
임베디드 워크플로우는 시스템 간의 ‘공유된 진실’을 필요로 합니다. 통합은 다음과 같은 마스터 데이터를 일관되게 유지하는데 도움을 줍니다:
이들이 동기화되면 승인은 원활해지고 정책 집행은 예측 가능해지며 재무 리포팅은 더 신뢰를 받습니다.
어떤 단일 통합이 ‘무조건 필요’하진 않습니다. 일부 조직은 카드 피드로 시작하고, 다른 조직은 HR 데이터 동기화로 시작해 이후 ERP로 확장합니다. 일반적으로 통합이 늘어날수록 유지 엔진은 강해지지만, 적절한 초기 설정만으로도 가치를 제공할 수 있습니다.
T&E에서의 ‘붙음성’은 사람들이 앱을 사랑해서 생기는 것이 아닙니다. 시스템이 회사 운영의 일부가 되어 바꾸는 것이 팀 전체의 실무를 다시 해야 한다는 의미가 되면 유지력이 생깁니다.
시간이 지나면 SAP Concur는 조직 방식에 맞게 튜닝됩니다. 이 튜닝은 단일 설정이 아니라 정책과 구조를 반영한 선택의 망입니다:
이 결정들이 자리잡으면 시스템은 ‘도구’가 아니라 ‘우리의 프로세스’처럼 동작합니다. 이전하면 규칙을 다시 매핑하고 승인 체인을 재구성하며 엣지 케이스를 재검증해야 합니다. 재무가 출력물을 다시 신뢰할 때까지 시간이 필요합니다.
새 제품이 비슷해 보여도 변경 작업은 구체적입니다:
이 작업 때문에 많은 회사가 갱신을 선택합니다: 변화가 불가능해서가 아니라 변화가 다른 우선순위보다 시간을 더 많이 소비하기 때문입니다.
비용 데이터는 결정의 기록입니다. 수년간의 제출, 승인, 수정, 정책 예외는 다음에 중요합니다:
기록을 접근 가능하고 일관되게 유지하면 리스크를 줄일 수 있고, 리스크는 비용이 많이 듭니다.
직원이 무엇이 승인될지 알면 결재자가 무엇이 ‘정상’인지 알고 재무가 무엇을 기대할지 알 때 워크플로우는 습관이 됩니다. 그 습관이 유지 엔진입니다.
스마트한 붙음성은 성과로 얻어집니다: 더 빠른 환급, 명확한 정책, 적은 놀라움. 그것은 함정이 되어선 안 됩니다.
T&E에서의 유지율은 단순히 기능의 유무가 아니라 직원과 재무 팀이 시스템이 매번 ‘올바른 일을 할 것’이라고 믿는지에 달려 있습니다. 신뢰는 워크플로우가 오류를 줄이고 환급이 빠르며 승인이 임의적이지 않고 예측 가능할 때 쌓입니다.
원활한 경험은 직원들이 이메일로 영수증을 보내거나 섀도우 스프레드시트를 유지하거나 예외를 요청하는 쪽으로 가지 않게 합니다. 비용이 올바르게 분류되고 정책 검사가 초기에 이루어지며 승인 경로가 예측 가능하면 직원은 재작업을 대비하지 않게 됩니다.
재무도 이득을 봅니다: 질문과 에스컬레이션이 줄고 감사 추적이 깔끔해집니다. 이 신뢰성은 갱신과 직접 연결됩니다.
명확한 상태 업데이트는 불투명한 프로세스를 예측 가능한 과정으로 바꿉니다. 신뢰를 주는 UX 순간은 단순합니다:
사용자가 어디가 막혔고 다음 단계 소유자가 누구인지 볼 수 있으면 승인 추적이나 지원 요청을 덜 하게 됩니다.
완료율과 만족도를 꾸준히 개선하는 몇 가지 패턴:
공통된 스레드는: ‘올바른’ 행동을 가장 쉽게 만들어 워크플로우가 요구적이지 않고 믿을만하게 느껴지도록 하는 것입니다.
대부분 회사는 여행 및 비용 관리를 한 번 사서 끝내지 않습니다—점진적으로 확장됩니다. 첫 롤아웃은 대개 좁게 시작합니다(한 국가, 한 법인, 한 사용자 집단) — 재무는 워크플로우가 작동한다는 빠른 증거를 원하기 때문입니다.
임베디드 워크플로우는 사이클이 반복될수록 강해지는 루프를 만듭니다:
관리자가 ‘수상한 비용’이 줄어들고 직원이 빠른 환급을 체감하면 참여는 선택적이 아니라 표준처럼 됩니다.
유지(renewal)는 고객이 구독을 갱신하기로 결정하는 것이고, 확장(expansion)은 사용을 늘리기로 결정하는 것입니다. 확장은 보통 다음과 같이 나타납니다:
성공적으로 확장하는 기업은 보통 표준 템플릿(정책 규칙, 승인 단계, 코딩 구조)을 마련하고 지역별 세금 규칙, 단체 협약, 국가별 수당 같은 통제된 지역 변형을 허용합니다. 이 균형은 혼란을 막고 ‘한 번 더 롤아웃’이 반복 가능한 프로젝트처럼 느껴지게 합니다.
임베디드 제품이 고객을 유지하는 이유는 사람들이 UI를 좋아해서만이 아닙니다. 프로세스가 계속 움직이고 있으며 팀이 그 움직임을 증명할 수 있기 때문입니다. 가장 좋은 지표는 이 움직임을 일찍 가시화합니다.
후행 지표는 이미 일어난 일을 말해줍니다:
선행 지표는 워크플로우가 ‘업무 방식’이 되어 가고 있는지를 예측합니다:
이 선행 지표들이 잘못 방향으로 가면 이후 갱신이 어려워집니다—사용자는 마찰을 느끼고 재무는 리스크를 보게 됩니다.
전체 평균은 문제를 숨깁니다. 다음 코호트를 활용해 임베딩 실패 지점을 찾아보세요:
코호트는 평균으로 숨겨진 채택 문제를 찾아냅니다.
명확한 레이아웃이 복잡한 하나보다 낫습니다:
SAP Concur가 진정으로 임베디드되면 갱신 이메일이 오기 훨씬 전에 안정적인 채택, 줄어드는 사이클 타임, 적은 예외, 예측 가능한 환급이 보입니다.
여행 및 비용 워크플로우가 실제로 유지로 이어지려면 채택이 필요하고, 채택은 대부분 구현 및 변경관리 작업입니다. 목표는 간단합니다: 규정 준수 경로를 가장 쉬운 경로로 만드는 것입니다.
성공적인 롤아웃은 보통 다음 순서를 따릅니다:
역할, 일정, 일반적 함정에 대한 단계별 뷰가 필요하면 /blog/implementation-playbook을 참조하세요.
교육은 일회성 웨비나가 아닙니다. 정착되는 기본 요소는:
사람들은 추가 단계를 싫어합니다, 규정 자체를 싫어하는 것이 아닙니다. 마찰을 줄이려면:
팀이 더 빠른 환급, 거부 보고서 감소, 적은 이메일 왕복을 체감하면 워크플로우는 기본이 되고 갱신 및 확장은 정당화하기 쉬워집니다. 가격 질문이 뒤따르는 경우가 많으니 패키징과 롤아웃 단계를 초기에 정렬해 두면 도움이 됩니다(/pricing).
SAP Concur가 '붙는' 이유는 단순히 비용을 추적하기 때문이 아닙니다. 반복 가능한 회사 프로세스 안에 자리잡고 여러 팀(직원, 관리자, 재무, HR, 감사자)을 정렬시키기 때문입니다.
1) 사람들이 반복해야 하는 워크플로우를 임베드하라. 유지율은 월별 마감, 온보딩, 승인, 조정처럼 반복되는 사이클에 제품을 묶을 때 커진다.
2) 최종 사용자 이상의 가치를 만들어라. Concur는 직원(불편 감소), 관리자(빠른 승인), 재무(정리된 장부), 컴플라이언스(정책 집행) 모두에게 가치를 제공한다. 여러 역할이 동일한 시스템에 의존하면 갱신은 공동의 인센티브가 된다.
3) 데이터 통합을 제품의 일부로 만들어라. ID, 비용 센터, 카드, ERP 게시 동기화는 예외를 줄인다. ‘재무에 다시 입력’하는 순간이 적을수록 대체하기 어렵다.
4) 규정을 흐름 안에 구워 넣어라. 자격 규칙, 영수증 요구, 임계값, 감사 추적이 자동화되면 사용자는 ‘추가 규정 작업’을 하고 있다는 느낌을 받지 않는다.
제품의 임베딩을 설계할 때 다음을 물어보세요:
임베디드 워크플로우 제품을 구축(또는 재구축)한다면 속도가 중요합니다: 역할, 승인, 감사 기록을 포함한 end-to-end 흐름을 빠르게 프로토타입할수록 프로세스가 진정으로 ‘정착’하는지 빨리 테스트할 수 있습니다. Koder.ai 같은 플랫폼은 채팅에서 작동하는 웹 앱을 빠르게 코드화하고 계획 모드에서 반복하며 스냅샷/롤백으로 복잡한 워크플로우 로직을 안전하게 다듬을 수 있어 유용합니다.
가장 빈도가 높은 워크플로를 선택해 이메일, 스프레드시트, ‘재무에게 문의’ 같은 모든 수동 인계를 맵핑하세요. 그런 다음 결정(정책)을 하나의 인계 지점에서 임베드하고 라우팅(워크플로)을 자동화해 한 손off를 제거하세요. 이 과정을 반복해 제품에서 프로세스가 end-to-end로 돌아가도록 만드세요.
프로세스 임베딩은 SaaS가 반복되는 비즈니스 프로세스(트리거 → 단계 → 의사결정 → 출력)를 끝까지 실행하는 기본 장소가 되는 것을 말합니다. 사용자는 이것을 단순한 ‘앱’이 아니라 ‘우리가 여기서 이렇게 한다’고 받아들이게 됩니다. 반복적으로 업무가 흐르기 때문에 그렇게 인식되는 것입니다.
여행 및 비용(T&E)은 계속 반복됩니다(여행 → 지출 → 제출 → 승인 → 환급 → 회계 조정). 동시에 여러 팀을 관통하기 때문에 한 도구가 각 단계에 자리하면 갱신 결정은 단순한 UI 선호도가 아니라 운영 연속성(직원 지급, 장부 마감, 감사 가능성 등)에 달려 있습니다.
실제 교체 비용은 계약 조건보다 운영적 작업에서 옵니다. 다음을 다시 설계하고 재검증해야 합니다:
위 작업들은 교체 시 일시적으로 예외와 월말 부담을 증폭시킬 위험이 있습니다.
높은 영향의 일반적 통합 지점은:
먼저 중복 입력을 줄이고 ‘어느 시스템이 정답인가’ 논쟁을 제거하는 통합을 우선하세요.
워크플로우가 실제로 작동하고 있다는 것을 보여주는 선행 지표에 집중하세요:
이 항목들이 악화되면 이후 갱신 위험이 따라옵니다.
평균만 보면 문제를 숨길 수 있습니다. 코호트로 조기에 리스크를 찾아보세요:
코호트 분석은 평균이 감추는 비채택 구간을 드러냅니다.
성공적인 구현 순서는 보통 다음과 같습니다:
구조화된 롤아웃 뷰가 필요하면 /blog/implementation-playbook을 참조하세요.
‘올바른’ 경로를 가장 쉬운 경로로 만드세요:
목표는 거부된 보고서 감소와 빠른 환급으로 자연스럽게 습관이 형성되게 하는 것입니다.
예상 실패 지점을 중심으로 설계하세요:
또한 상태를 가시화해 사용자들이 ‘지금 누가 담당인지’ 알 수 있게 하면 지원 티켓을 줄일 수 있습니다.
복제해볼 만한 패턴은 다음과 같습니다:
사람들이 반복해야 하는 워크플로우를 임베드하세요. 유지율은 월말 마감, 온보딩, 승인, 조정처럼 주기적으로 돌아오는 사이클에 묶일 때 커집니다.
최종 사용자뿐 아니라 여러 역할에 가치를 만들어 주세요. 직원(불편 감소), 관리자(빠른 승인), 재무(정리된 장부), 컴플라이언스(정책 집행)를 동시에 만족시키면 갱신은 조직적 동기로 바뀝니다.
데이터 통합을 제품의 일부로 취급하세요. ID, 비용 센터, 카드, ERP 게시 동기화는 예외를 줄입니다.
규정 준수를 흐름 속에 녹이세요. 자격 규칙, 영수증 요구, 한도, 감사 기록이 자동으로 적용되면 사용자는 ‘추가 규정 작업’을 하고 있다는 느낌을 갖지 않습니다.