2024-03-09

Unified Customer View

Google翻訳で直訳すると、

統合された顧客ビュー

となりますが、要は「自社の顧客を総合的に評価する。」のようなことかと思いつつ、Descriptionを読んで行きます。

Get a 360° view of the customer with a cross-platform,unified system of record for each customer along with health scoring and critical status changes.

に対して、同じくGoogle翻訳を通すと、

クロスプラットフォームの統合された各顧客の記録システムと、健康スコアリングや重要なステータスの変更により、顧客の全方位を把握できます。

となります。

そこで、当ブログの大盛り作戦を実行して、

社内で利用している各システムに蓄積した顧客に関する情報に対して、顧客の当社への対応や何某かの状況の変化を参照しながら、あらゆる角度から顧客の状態を把握します。

のようにしてみました。

ここで気になるのは、“health scoring”です。

当然、顧客の病気を心配しているのではなく、

顧客が自社のプロダクト利用を継続するかどうかを測る指標

とGrowwwth Noteさんが上手く説明してくれています。

例えば、顧客が現在使っているシステムに対して思っていることは、

満足していて今後も利用を継続しようと思っている
やや不満があるので、利用を継続しようかどうか迷っている
使い勝手も含めて非常に不満なので他を探している

の3通りでしょう。

一番目は一応は安全だとしても、二番目と三番目は逃げて行くと考えるのが普通です。

そこで、

顧客の状況を数値化し、兆候をつかむことで解約の危険性を減らせること

の必要性が出てくるわけです。

5年リースで導入することが多かった昔とは違って、サブスクリプション時代の今日は厳しいですね。

次に、Typical Functionalityに行きます。

Mapping and syncing fields across relevant systems
（利用しているシステムの間で管理データを関連付けさせて相互に同期させる）
Centrally managing data work-flows
（顧客データの取り扱いを一元的に管理する）
Central view or profile of all relevant customer dat
（顧客に関連する全てのデータの客観的に或いは一側面も評価する）

と少し大盛気味ですが行き過ぎていたらゴメンナサイです。

以上を踏まえて、具合的なソリューションに話を進めると、

の1番目に挙げられている、DOMO社は日本に進出していて、当然日本語のwebsiteがあるので助かりますが、

全社データ活用でDXを推進 — BI、データ分析、ダッシュボード、データ基盤、すべてを備えたデータ活用プラットフォームです。

と自社製品のことを説明しています。

そんな製品/サービスに対して、本家の英語版websiteでは、

Data can help you understand how your business is performing, what customers are thinking and doing, and where your business needs improvement.

DOMOの製品によりデータを分析することで、単に売れ行きだけでなく、顧客が現在何を考えて、何をしているのか、更には何を改善しなければならないのかが分かります。

と説明していています。

つまり、“Unified Customer View”の目的は、自社に何が必要なのかを把握することなのでしょう。

2024-03-03

Configure,Price,Quote,Invoice

Windowsの前に、MS-DOSというオペレーティングシステムがあって、config.sysというファイルでドライバーを指定したりパラメーターを設定していたことを思い出しましたが、Configureとは、

構成する、設定する、作る

と英辞郎が説明していることを頭に入れてDescriptionを読んで行きます。

Quoting of complex solutions with multiple configuration options and the ability to price them according to each specific customer’s pricing schedule.

選択肢が複数に亘る複雑な構成のソリューションの見積もり機能や、特定の取引先ごとに設定した納入価格表に基づいて見積りを提示する機能を有する。

といったところですが、“pricing schedule”とは所謂「価格表」であって、「取引に連れて価格を下げて行く予定」といった意味ではありません。

続いて、Typical Functionalityでは、

Quotes that can include BoM, drawings, spec sheets
（BoM、図面、仕様書を含む見積書）
Accurate pricing data for each account across any
（個々の取引先後の正確な販売価格のデータ）
channel (sales, web, channel）
（一般の販売、ウェブ経由の販売、特定の販売ルートなど販売ルートごとに見積もりをを立てる）

の3つが挙げられています。

ここでBoMとは、Bill of Materialの略で、部品構成表を意味し、一般には機械や電気の図面内にも書かれます。

例えば、パソコンなら、本体、キーボード、マウス、ディスプレイという4つの「部品」で構成されますが、それぞれの「部品」は更に細かな部品で構成されます。

見積もりにあたっては、その必要な「部品」を正確に把握しておく必要がありますから、図面だけでなく、BoMや仕様書が必要となるわけです。

それに、通常は定価とは別に、

エンドユーザー向け：割引価格
流通/業者向け：仕切値＝仕切り＝仕切り価格＝ネット価格＝卸売り価格＝建（立）値

などがあります。

前者は、エンドユーザー向けであり、過去の取引内容、今回の取引数量、相手先の規模、競合の有無、支払いサイトなどによって提示価格が変わってきます。

といっても見積ごとに毎回考えているわけではありません。

大抵の場合は、3パターン位の値引き率を持っていて、

大口案件向けの割引価格
中規模案件向けの割引価格
取り敢えずの提示価格

の何れで出すかの適当な理由をくっつけて上席の許可を取った上で提出します。

一方で、後者も条件によってよって変わるものの流通業者向けは年間取引高＆定量在庫を前提にした一律仕切りが基本ですが、その先のエンドユーザーが何処なのかによって変わって来ることもあります。

尚、「ネット価格」とはWeb経由での取引価格ではありません。それこそインターネットが出現する前の時代から使われていた用語で、要するに卸売り価格で、流通業者向けと一般販売店向けの両方で使われます。

3つ目のchannelとは、取引ルートのことで、一般には、

直接取引（Web経由を含む）
販売店経由
流通業者→販売店経由

の3通りがあり、チャネル間で対エンドユーザー価格のバランスが崩れないように注意しなくてはなりません。

加えて、二つ目と三つ目の両方においても、更に複数の販売店がぶら下がるのが珍しくありませんでしたし、特定市場における一括案件などでは「回し」（と当時は言っていました。）により全ての参加業者間を請求書が通る場合もあって、値引き要求はきつくなるし支払いサイトは長くなるしで厄介でした。

更には、多くの場合には前回の記事に書いたRFP/RFQが曖昧なままで様々な条件を考慮しながら作成しなくてはならないだけでなく、受注する可能性が無いのにワザワザ見積を求めてくる場合もありました。

私が一時期に世話になっていた方の紹介で止む無く取引していた某社の営業さんは、「○○社向けにｸｵｰﾄ（Quote）するので大至急取引条件を提示して下さい。」と何故か“ｸｵｰﾄ”の部分を半角で書いてメールを送ってくるのですがいうのが、いつも相見積もり参加ばかりだったので、用意していた雛形を弄って提示するだけでした。

また、関西系では「今回は当社は儲け無しで対応しますので御社も協力願いします。」と言ってくる業者がいますが、政策的な対応を別にして、通常取引において利益なしで商売することなど有り得ません。

脱線の連続で前置きが長くなりましたが、

の一番目で紹介されている、apparound社のwebsiteを見てみると、

Now sales teams can just sell!
Book bigger deals faster with the sales automation platform that reps actually love using.

と書かれたメッセージが目に留まりますが、

当社の製品/サービスを使ってもらうことで営業部門の方は、営業活動に専念でき、実際に愛用しているシステムと併用しながら、より大きな案件を次々に獲得できるようになります。

と今回も大盛にしてみました。

そして、

Apparound can be integrated with your business software
(Apparoundは貴社が導入しているビジネスソフトウェアと統合可能）

として、

Microsoft社のDynamics 365
salesforce
HubSpot
SAP
ORACLE

などが挙げられているので、まさに中・小規模～大規模な利用まで幅広く対応できるのでしょう。

2024-02-26

Contract Proposals & RFPs

そのまま読むと、

契約、提案書 & RFP

となります。

契約書、提案書は誰でも分かるでしょう。

でもRFPはシステム業界以外の方には、馴染みが無いかもしれませんが、IT調達ナビさんが、

RFPとは“Request for Proposal”の略で、日本語では「提案依頼書」と言います。企業が情報システムの導入や業務委託を行うにあたり、発注先を選定するために、候補となるシステム開発会社に具体的な提案を依頼する文書です。システムの目的や概要、要件や制約条件などが記述されています。

と分かり易くまとめてくれていますので、参考にして下さい。

前置きはこれくらいにして今回もDescriptionから読んで行きます。

Create proposals with custom fields and variables to insert information like names, product descriptions, case studies, images, RFP responses in one content library.

とのことですが、

カスタムフィールドと変数を使用して提案を作成し、名前、製品説明、ケーススタディ、画像、RFP 回答などの情報を 1 つのコンテンツライブラリに挿入します。提出する客先向けに項目や内容を入れ替えることができる雛形となる標準提案書を用意しておきます。そして案件の都度、相手先の社名、製品詳細、事例、製品イメージ、RFPへの回答などを入れ込んで提出します。

と少々大盛にしました。

また、Typical Functionalityは、

Approval roles and routing
（作成した文書の承認者とその順番を決める機能）
Content & RFQ response repositories
（資料や文書と見積もり依頼書に応じて提出した見積書の一括保存機能）
Esignatures and invoicing
（署名と請求書発行機能）

といったところでしょう。

ここでは先ほどのRFPではなくRFQが出てきましたが、

「RFQ」とは（Request for quotation）の略であり、日本語で「見積依頼書」です。
商品やサービスの購入を検討する際に、重要なのが「見積り」ですが、提供するサプライヤーに見積を依頼する時に口頭やメール文では十分な情報を与えることは難しいです。希望する内容・条件を明記した「RFQ」見積依頼書が必要になります。

とintra-mart Procurement Cloudさんが説明してくれています。

RFPもRFQも全ての顧客から出てくるわけではありませんし、もっと言うと自社に何が必要なのかを分かっていない会社もあります。

そういった場合に時々出てくるのは「タイプＡ、タイプＢ、タイプＣに分けて提案してみてよ」なんていう曖昧な依頼です。

この場合、色々と質問してくるものの契約に至ることは稀で、所謂「話好きは買わない客」に近いパターンです。

もっと酷い話は、日本を代表する電気メーカーの某事業部の課長さんの話で、色んな会社の営業担当者を呼びつけては、技術者の同席を要求した上で詳細な提案書を提出させます。

でも、その提案書の利用目的は自身の社内提案（改善の為に頑張ってますよアピール）の為であって、導入を前提とした稟議書を書くことはありません。

恥ずかしながら私も1回ひっかかりましたが、同業他社の何人もが同様の経験をしていて、挙句の果てに言われたことも「君の提案の程度が低かったから事業部長から却下された。」と同じでした。先輩からは「これも経験だ。」と助言されましたが、以降は肝に銘じるようにしました。

逆に、ベンダーへの要請内容を依頼をしっかり書いてくれる顧客/ユーザーもいます。金額も含めて厳しい内容が多かったと記憶していますが、しっかり対応すれば契約率は高かったですし、後で「言った言わない。」も発生しませんでした。

もっとも私が駆け出しだった頃はFAXでのやり取りでしたが、1995年前後に各社でe-mailの導入が始まってからは、文書でのやり取りが加速しました。

更には、全く知らない顧客/ユーザーからの見積もり提案要請が自社のwebsite経由で突然来るなんてこともこの頃から増えました。

今日では、当たり前になっているのかも知れませんが、ユーザー側からすると何社へも提案/見積依頼をし易くなった半面、ベンダー間の競争が激しくなっているわけで、先のDescriptionにあったように、可変部の入れ替えをするだけで完成する標準提案書的なシステムの必要が高まったのかも知れません。

毎度のことながら今回も話が大幅に脱線しましたが、最後に、

の一番目に挙げられている、upland Qvidianのwebsiteを見てみると、

Proposal Management & RFP Response Software
（提案書管理機能とRFPへの対応を支援するソフトウェア）

と書かれていますが、

Help teams collaborate to create stand out proposals and RFP responses quickly, shorten sales cycles, track results, and score more wins.

つまり、

チームで協力して優れた提案とRFPへの回答書を迅速に作成することで、短期間で商談を進めて進捗を確認しながら、より多くの案件を獲得します。

のような業務に対して支援してくれるそうです。

日本の多くの会社では、今でも担当の個人管理が多いのかもしれませんが、ある程度システマティックに数多くの商談機会に対応して行くには、こういった製品/サービスが欠かせないのでしょう。

2024-02-20

Customer Success & Renewal Mgmt

CLOSEは2つでしたので後でまとめることとして、今日からEXPANDに入ります。

といってもここもCustomer Success & Renewal Mgmtだけです。

Complete Guide to SalesTechに説明がありませんし、前半と後半で意味合いが違うので、

Customer Success Mgmt
Renewal Mgmt

に分けて調べて行きます。

因みに言うまでも有りませんが、“Mgmt”とは“Management”の略語で“Mgt”と記される場合もあります。

大昔に映画を観ていて“ASAP”が“As soon as possible”であると気付いた時は感動しましたが、このように省略された言葉を調べる時は、All Acronymsを使うことをお勧めします。

さて、話を戻します。

Customer Success Mgmtについては、既に日本語「カスタマー・サクセス・マネージメント」として定着しているので皆さんご存じだとは思いますが、改めて検索してみると、

より深く掘り下げてデータ収集や分析をもとに、より顧客の成功体験に注目したのがカスタマーサクセスマネジメント

と説明しているミツカルさんのサイトに辿り着きました。

では何故そんな活動が必要かというと、

顧客が商材やサービスを通して感じてもらう「良い体験（サクセス）」がより重要視される

ということは、

使って良かった

と思ってもらうことが大事だからなのですが、以前は分野によっては「売ったら終わり」のような時代もあって、その結果、シェルフウェアという、

Shelf（棚）＋Software/Hardwareを繋げた新語で、簡単に言うと「持っているけどほとんど使っていないソフトウェア、ハードウェア資産」

とデジタルテクノロジーさんがココで説明しているような事例が沢山ありました。

でも、そんな状態になったら、社内で利用を広げて貰ったり、或いは次回の更新の時に声が掛からなくなるので、トレーニングやサポートに力を入れるわけです。

特に今の時代はサブスクリプション契約で毎年/毎月の契約更新となっている場合が多くなっていますから、利用を止められたら一大事です。

それに営業さんは次の契約を取ることに気持ちが行ってしまっていますから、納入先の利用を支援する為に専門の組織を作って対応するケースが多くなっているのでしょう。

もっとも、

カスタマーサクセスはやめとけと言われる理由

をワザワザ説明しているサイトがあるくらいですから大変な仕事でもあります。

ところで、そのカスタマーサクセスマネジメント分野で利用できるシステムとして、

にも挙げられているGainsightさんは、先のミツカルさんでも、

本場米国で高い評価を受けています。顧客からのフィードバックやヘルス状態を、高い精度でAI分析できる機能が特徴です。

と紹介されていますし、有難いことに日本法人のwebsiteもあります。

主な機能は、ココに紹介されているので参考にしていただくとして、

契約はゴールではなくスタート

というのは、その通リだと思います。

また、そうやって契約できて使い始めたお客様が利用を継続してもらえるようにするのが、Renewal Mgmtで、scalebaseさんが、

リニューアルマネジメントは、サブスクリプションビジネスにおいて、契約期間が終了する前に顧客との円滑なコミュニケーションを図り、契約更新の意思確認をするCS活動のことです。

とココで説明してくれていますが、手が掛かるものの欠かせない業務です。

以上から、Customer Success & Renewal Mgmtは一対であり、EXPANDにおいて顧客を深耕して行くためには大変重要だということが理解いただけたと思います。

ただ、実際には、大手企業においても、横の繋がりが全くないケースや不仲であることが珍しくありません。

酷い時には「○○事業部が使っているのならウチの部門はお断りだ!」なんて言われる場合もあるわけで、このあたりは再び営業さんの出番になります。

2024-02-14

ESigning

あまり馴染みのないスペルなものの、よく見たらE-Signなので大体の想像はつきましたが、先ずはDescriptionを読みます。

Get documents signed and returned quickly without the need to print, sign, fax or scan and email. No need for prospects to have special software.

注文書/契約書を印刷して、それに署名してFAXで送ったり、或いはスキャンして電子メールに添付して送信するなんていう面倒なことはせずに、画面上で文書に署名してすぐに返送できます。また、その際に顧客側が特別なソフトウェアを用意する必要もありません。

私が駆け出しの頃は口頭注文で段取りに走るなんてことがありましたが、今日では許される筈がありません。

それに、書類を交わすにしても、複写式の注文書を客先に持参して、ゴム印、角印を貰って、更には、同様に上席の責任者が捺印した注文請書を後日郵送、或いは持参するなんてことをしていました。

でも広いアメリカで、そんな仕方をするわけはないでしょうし、日本国内の中小企業でも全国レベルで取引をしている場合は、ESigningが必要になるのでしょう。

久しぶりに冒頭から脱線しましたが、Typical Functionalityに戻ります。

Sending documents to one or more parties for signing

（署名してもらう文書を複数の関係者に送付する）
Tracking who has and hasn't signed
（署名済みは誰なのか、未だ署名してくれていないのは誰なのかを追いかける）
Automatic distribution of signed documents
（関係者の署名済みの文書を必要な部門に自動的に送付する）

これだけでは少し分かり難いかもしれないので、当ブログなりに補足します。

日本国内の中堅以上企業の場合には、上申の段階で各部門の合意がとれているので、稟議が下りた後は資材/購入部門との最終交渉を経て注文する品名、金額、支払い条件、納入時期などを記入した注文書が発行されます。

しかし、支払い担当（経理部門）や法務部門等も含めた関係部門との合意を取る必要がある場合には、一番目の機能が役立つでしょう。

もっとも客先の特定部門の責任者の考えが変わったり、或いは不在の場合は何処で止まっているのかを確認することとなるので、二番目の機能が必要となります。

そして目出度く注文書が発行された暁には、成立した契約書/注文書（或いは、注文請書）を客先の関係先だけでなく、注文を受ける側の関係部門にも送付する場合には、三番目の機能は便利です。

以上から大体のことは分かったと思いますが、有難いことに、

の一つ目に紹介されているSignNowについて、TextCortexさんが、

SignNowは、電子署名を作成・投下し、必要な時に簡単に入手できるeコマースツールです。例えば、クライアントが何かサインをする必要があるときや、ベンダーとの間で書類にサインをする必要があるときに、SingNowを使うことができます。

と日本語で説明してくれていて、実際の使い方や効能として、

SignNowを使えば、文書をダウンロードして手動で署名する時間の無駄がなくなります。いつでも数秒で素早くデジタル署名を入れることができます。何より、署名には法的拘束力があるので、法的価値のない署名を作る心配がないのが魅力です。

も挙げてくれています。

では、何故書類を交わすことが重要になったかですが、今から30年前の所謂バブル期あたりまでは、いい加減な取引があったのは事実です。

会社によって売り上げ基準がバラバラで、受注したら納入していないのに売り上げに計上するのも珍しくありませんでしたし、受注できていないのに芋判を自作して勝手に架空の注文書を作成した某中堅メイン・フレーマーの話を聞いたことがあります。

もっとひどい場合として、架空の会社向けシステムを販売会社経由で受注したことにしたケースや納入先を紹介することを条件に販売会社に注文書を出させて在庫を押し込んで特別ボーナスを貰ってトンズラ退職した営業マンなんていうのもいました。

当然時間が経てばバレるので、各社で盛大に売り上げの取り消しや穴埋めをすることになったわけです。

その後は管理がより厳格に伴って契約の書類化を推し進めたのでしょうが、一方で世界的に著名な某専用メーカーの米国内の事業所では、正式な本契約書とは別に所謂サイドレター（には「いつでも解約返品が可能です。」と記載されている。）の乱発が横行したこともありました。

他の業界に於いても飛ばしや架空取引により不良債権が問題化したのと同じ頃です。

結果、営業さんへの縛りが益々厳しくなったわけですが、逆に真面目に仕事に取り組んでいる営業さんの面倒なことを手助けをしてくれるE-Signが登場するキッカケになったのかもしれません。

2024-02-09

Pipeline Reviews

いよいよCloseに入ることとなり、その一番目は“Pipeline Reviews”ですが、いつものようにDescriptionを読んで行きます。

Enable productive sessions with clear guidance and coaching. These solutions provide standardized views and insight needed to standardize the review process.

明確な指針を示し営業担当へ適切に指導すれば、実りのある営業会議となります。また、商談状況の進捗把握に必要な一般的な見方、及び標準商談の進行を標準化する為に必要となる識見はPipeline Reviewsが提供します。

直訳では意味が分かり難そうなので、相当に盛ってしまいましたが、営業で会議と言えば売り上げ見通しの報告会議です。

当然、話されることと言えば、抱えている案件の進捗と確度になるのですが、人によって見方にバラツキが出てはまずいので、活動を標準化させながら売り上げを安定化させることが求められます。

その為に必要なTypical Functionalityとしては、

Configurable actions
（取りうる営業対応）
Goal identification
（目標の設定）
Survey-type pre-meeting input
（会議前の事前聞き取り）

などが挙げられています。

3番目は考え過ぎかもしれません。

でも日本の会社においては、会議前に商談見込み一覧を提出させられることが多い筈で、これが「聞き取り」に相当するものでしょう。

では、実際にどんな風に進んで行くかですが、私が若い頃の話です。毎月の営業会議の前には、上席から「フォーキャスト（Forecast＝受注・売り上げ見通し）を出せ」と言われるので、予算を少し上回る程度の手持ちの案件をリストにして提出します。

記載項目は、客先名、売り上げ予定金額、受注予定月などで、営業の進捗状況は備考に書くか、或いは口頭で補足する程度に留めます。というのも、上席によっては、各担当から上がってきたリストをそのまま合計して部門長や役員に提出してしまうからです。

当然、失注することが有るものの、売り上げに穴を空けるわけにいきません。そこで、その他案件に確度の高そうなバックアップ案件を潜ませておき、埋め合わせをして期を乗り切るわけです。

今日の営業チームはもっとスマートになっているでしょうが、そういったことを支援してくれるであろうツールとして、

の1番目に紹介されている、akoonuのwebsiteを見て行きます。

先頭に掲げられているキャッチフレーズは、

Forecast with Ease and Confidence
（簡単かつ確実に売り上げ見込みを立てる）

です。

「そうなれば良い」と誰もが思っていることを言っています。

また、特徴として、

Akoonu Pipeline Reviews
Immediate and actionable insights about your pipeline’s current status, changes, and trends.Everything in one place to manage your deals and your pipeline.Easy insights for all levels of the organization to save time and build confidence in decision-making

と言っていますが、これの意味するところは、大まかに言うと、

Akoonuが提供する商談進捗把握機能
現在進行中の各案件の商談進捗、或いは取り巻く状況の変化、そして流れ（受注or敗退）がスパッと分かるように情報を集約しているので、長々と会議をすることもなくなって営業チーム所属メンバーの時間節約にもなるし、確信をもって営業上の意思決定ができます。

といったところでしょう。

でもAkoonuさんのシステムでも、先に挙げたような、その他に潜り込ませたバックアップ案件の発見は難しいかもしれません。

2024-02-03

EARNのまとめ

先週でEARNが終わったので、一旦まとめるにあたり、改めてのココで確認すると、

顧客が稟議書を書く、或いは来期の予算を申請することを前提に、相談してくる段階になります。

と書いていて、いよいよ大詰めとなりますが、色んなことを同時並行的に進めなければなりません。

このあたりになると既に概算見積は提出しているでしょうから、その範囲での導入に納めなくてはなりませんし、「こんなこと聞いていなかったよ。」がないようにしなければなりませんから、Presales Enablementにて技術担当を挟むのは当然です。

それに、顧客に最終稟議書を上げて貰う為には、費用対効果を示すのは当然で、Value Selling & ROIを上手く使えば良いのかもしれませんし、導入事例を添付した方が先方の役員が安心しますから、Customer Reference Mgmtを通じてストックしておいた中から最適な事例を慎重に選びます。

他方、こうやって導入してもらった顧客も是非、当社ソリューション導入先に加わって頂くことへの打診も必要で、担当部門との最終ネゴ、更には資材/購買部門からの値引き要求に対しては交換条件とすることを前提に、今度は自分の上席に対して値引き幅の了解を得ておくこととなります。

また、こういったやり取りでは、結構なな書類の行き来が発生しますし、もっと言うと、顧客の稟議書の下書きをすることもあるのですが、一連の資料類をDigital Sales Roomsで、