ブログ

  • How to Automate WordPress Posts with No Code

    How to Automate WordPress Posts with No Code

    Many companies use WordPress to create and update their corporate websites and product/service websites.

    This time, we would like to introduce a way to automate part of the WordPress posting and page posting process to save your time and effort.

    How to Automate Posting to WordPress

    Cloud Service Tools to Prepare

    The tools we will use are WordPress and Questetra BPM Suite.

    Questetra BPM Suite is a business system platform that allows you to build a business system with no code. The steps on the workflow diagram are processed in the order they are placed on the workflow diagram.

    How Drafts are Automatically Created

    Set up the information of the site you want to submit articles to Questetra BPM Suite, such as the information of the site and the post title, the content of the post. Questetra BPM Suite will send a signal to automatically create a draft article in WordPress based on the settings information.

    A draft post is automatically created in WordPress and information such as the URL of the draft post is sent to Questetra BPM Suite.

    How it is Submitted to WordPress

    Below is a workflow diagram depicting the process of getting a draft posted to WordPress, using an automated processing item that will automatically post the draft to WordPress.

    WordPress Article Submission workflow diagram

    Specifically, posting to WordPress is completed in the following order

    1. Human Task: Set the title/article body/excerpt/post type (post/page), etc.
    2. Automatic processing items: A draft is automatically created in WordPress based on the information set in 1.
    3. Human Task: Check the draft created in WordPress and publish it (click the [Post] button when completed).

    By adopting this business process, all the contributor has to do is fill in the required fields on the input form as shown in the figure below, check the completed draft, and click the “Submit” button. This simplifies the submission process and saves labor.


    Image of the input form for the Input Submission Details process

    ※ Input form items can be created/configured for each process.

    How to Utilize it in Business Processes

    The main feature of Questetra BPM Suite is that it can be used in organizations involving multiple people/multiple departments.

    When creating or updating a website, especially a corporate website or a product page, it is necessary to post accurate information. Questetra BPM Suite helps to realize such a cross-functional business process within a company.

    In addition, Questetra BPM Suite allows the use of automated items in business processes involving multiple people/departments. In the workflow diagram that you create you can set up both processes that are handled by humans (e.g. creating a post, checking the content, etc.) and processes that are handled by the system (e.g. items that automatically create a draft of an article). This makes it possible to improve efficiency and save labor even in operations involving organizations.

    The workflow diagram below illustrates the use of an automated item in which draft articles are automatically added to WordPress for a business process in an organization.

    The specific process treatment flow is as follows

    1. Human Task: Input the title/article body/excerpt/post type (post/page), etc.
    2. Human Task: Check the contents set in 1. If any modification is necessary, it is sent back to be corrected.
    3. Automatic Task: A draft is automatically created and added to WordPress based on the information set in 1.
    4. Human Task: Check the draft created in WordPress, and publish it (click the [Post] button when completed).
    5. Human Task: Check the posted content. If it needs to be revised, it is sent back to be revised.

    Thus, with Questetra BPM Suite, drafts are automatically created and added to WordPress, which makes your work more efficient by shortening your work time.

    In addition, irregularities in work can be prevented because work can proceed according to the workflow diagram. In addition to this, it is also possible to improve the quality of work and reduce errors by including a checking process in the workflow.

    If you are interested please give it a try.

  • オジサン世代向け GA4 Conversion 概説

    オジサン世代向け GA4 Conversion 概説

    ◆ Q1. コンバージョンは Event?

    GA4 時代の「操作ログ」は、(”PageView” ではなく)、全て “Event” という単位で記録されるらしい。  と、いうことは、、、コンバージョンも “Event” なの?

    A1. コンバージョンも “Event” です

    GA4 の「コンバージョン Event」は、既存の Events 定義の中から指定されます。「Conversion というランクに格付けされた Event」と理解しても良いと思います(GA4 における制限:30個)。

    具体的には、(多くの会社では)、

    • 購入した
    • 資料請求した
    • 体験版を申し込んだ

    といった Event が「コンバージョン」として格付けされます。

    • [GA4] コンバージョン イベントのセットアップと管理
      https://support.google.com/analytics/answer/9267568
      コンバージョンを測定するには、ビジネスにとって最も重要なイベントを選択し、コンバージョン イベントとして設定します。

    ちなみに、”購入イベント” (←イベント名が purchase となっている Event)だけは、自動的に「コンバージョン Event」として認識(格付け)されます。そして[購入の可能性]や[予測収益]や「生涯顧客価値」(LTV)の予測モデルに活用されます。イベント名 purchase は、ある種の “予約語” と言っても良いと思います。

    Conversion / Convert には【変換】や【転換】といった意味があります。(野球の世界なら「内野から外野へ Convert された」、パソコンの世界なら「JPEG から PNG に Convert した」など)。ビジネスの世界においては、「見込顧客を【変化】させた」や「見込顧客を【改宗】させた」といったニュアンスで使われています。大量に記録される Events の中で、どの Event を「コンバージョン」と見なすべきなのか?、を考えるコトは、容易なことではありません。

    ga4 Events and Conversions

    ◆ Q2. コンバージョンは、どう設定するの?

    Google アナリティクスで「コンバージョン」を定義するのはタイヘンなの? プログラミング知識が必要だったりするの??

    A2. “GA4-UI” もしくは “GTM” で実装します

    大まかな手順は、以下の2ステップです。

    • 1. Event を作る
    • 2. Conversion マークを付ける(←格付けする)

    たとえば “thank_you_conversion” というアリガチな「コンバージョン Event」を設定したい場合は、まず、次のような設定で新しい Event を作成します。

    • event_name: 次と等しい page_view
    • page_location: 次を含む thank-you.html

    これらは Event page_view のサブセット(←パラメータの値で絞り込んでいるだけ)です。このような場合、Google アナリティクスの管理画面(GA4 UI)で作成することができます。コーディング知識は全く必要ありません。(追加の学習コストは不要)

    サイトのアクセス状況に応じて「Shareミス対策」や「Botトラフィック対策」などの工夫が必要になるかも知れません。(例: page_referrer 次で始まる "https://example.com/"

    一方、「あらかじめ定義されている Events」(全11種)のサブセットにはならないような Custom Event (Conversion Event) は GTM で作成します。たとえば「XMLファイルの click」という Event は “全11種” では、効率良く捕捉できていないため、”GTM での作成” を検討することになります。コーディング知識は必要ありませんが、追加の学習コストが必要です(トリガー/タグ/ワークスペースといった仕組みについて要学習)。

    • Web Events
      • page_view
      • user_engagement (10s,,,)
      • scroll
      • session_start
      • first_visit
      • file_download (pdf,xlsx,,,)
        • ※ Event file_download では「ファイル拡張子」が対象外です
        • (.xml は全くトリガーされません)pdf|xlsx?|docx?|txt|rtf|csv|exe|key|…
      • click (outbound link)
        • ※ Event click では「アウトバウンド Link」に限定されてしまいます。
        • (クロスドメイン測定ドメインの外へのLink)
      • view_search_results
      • video_complete
      • video_progress
      • video_start

    Google アナリティクスのマニュアルに『新しいイベントは、初めてトリガーされてからしばらくの間、表には表示されません』と記載されているように、GA4 の[設定]メニューにある[イベント]はナカナカ更新されません(202205現在)。Custom Events は、別途 Google Sheets などで管理した方が良いかも知れません。

    Custom Events via GTM

    ◆ Q3. コンバージョンの命名規則は?

    「各部門KPIのコンバージョン化」や「マイクロ・コンバージョンの追加」など、、、コンバージョンは上限の30個まで作ってしまいそうダ…。コンバージョンやイベントに、命名規則(流儀)とか、あるの?

    A3. 自前実装時も既定の名前にすべき場合があります

    「Googleが推奨するイベント名」に準拠することが大切です。

    Conversion Events は原則、「Events の3分類」を継承し、以下の 1.2.3. のいずれかに該当します。そして、この中の「2.推奨イベント」に該当する場合は、purchasesign_up といった既定の名前を使う必要があります。

    • (0. 自動収集イベント / Automatically collected events)
    • 1. 測定機能の強化イベント / Enhanced measurement events
    • 2.[要実装]推奨イベント / Recommended events
    • 3.[要実装]カスタム イベント / Custom events

    たしかに「2.推奨イベント」(と「3.カスタム イベント」)は、独自実装するので自社ローカルな名前を付けたくなるのですが、、、後々の「レポート生成」や「予測モデル活用」に配慮し “推奨名” (既定の名前)で命名します。

    • [GA4] イベントについて
      • https://support.google.com/analytics/answer/9322688
      • 「自動収集イベント/測定機能の強化イベント」は、コードを追加しなくても収集できます。より高度なデータ収集が必要な場合は、「推奨イベント」や「カスタム イベント」をコードに追加します。
    • [GA4] 自動的に収集されるイベント
      • https://support.google.com/analytics/answer/9234069
      • …基本的な操作によってトリガーされたイベントは、自動的に収集されます…、これらのイベントを収集するコードを追加で記述する必要はありません。
    • [GA4] 測定機能の強化イベント
    • [GA4] 推奨イベント
      • https://support.google.com/analytics/answer/9267735
      • より有益なレポートの生成に加え、新たな機能と動作の測定を行うことができます。…すべての業種のすべてのお客様におすすめします。
        • ad_impression
        • earn_virtual_currency
        • join_group
        • login
        • purchase
        • refund
        • search
        • select_content
        • share
        • sign_up
        • spend_virtual_currency
        • tutorial_begin
        • tutorial_complete

    なお、「3.カスタム イベント」に該当する Conversion Event も、長期利用に耐える Event name (≒イベント種類)にしたいところです。

    無計画に命名すると、”User が何を達成したのか”(≒「見込顧客をどう【変化】させたのか)が分からなくなり、運用・保守・追加開発(デベロッパー エクスペリエンス)がスムーズに進められません。一般的な命名アイデアとしては、

    • {Resource}_{UserAction}
    • {OwnerDiv}_{BusinessProcess}
    • など

    が挙げられます。

    極端な話、、、たとえ自社サイトが purchasesign_up と無縁なサイトだったとしても、サイト訪問者に期待する Event シナリオ(カスタマージャーニー)を考察し、「仮想的な purchase」や「仮想的な sign_up」を設定すべきなのだと思います。あるいは(もっと言えば)、、、「tutorial_begin / tutorial_complete を体験できるサイト」(orアプリ)の追加(への改変)を検討すべきなのだと思います。

    ◆ Q4. オーディエンスって何?

    Google アナリティクスが「Event 単位で記録されるようになった」ということは “オーディエンスの考え方” も大きく変わったんだろうね。 “GA4 オーディエンス” も、ちゃんと設定した方がイイ?

    A4. 最先端の顧客グルーピング機能です

    GA4 の計測単位である「Event」を、あえて違う表現で(掘り下げて)説明するなら、「ユーザの操作」(user’s interaction/activity)と言うことができます。 (⇒ UA 時代の「セッション内の PageView」とは対照的です。)

    しかも、そのユーザ操作は「デバイス横断的に計測される」という特徴があります。 (⇒それでいて「プライバシー配慮」〔GDPR/CCPA準拠〕って、スバラシイ。)

    ユーザのグループ化機能(セグメント化機能)である[オーディエンス]は是非とも設定しておきたいところです。(GA4 における制限:100個)

    とりあえずは、「Daily Active Users 数」や「Paid Customers 数」といった “アリガチな実績値” (≒業界標準の計測指標)は設定すべきなのでしょう。加えて、”各部署のKPIに沿ったセグメント” を設定するのが良いと思います。(オーディエンス規模の目安は各週において1000人程度が出入りするくらいが最適のようです)

    たとえば、『「XMLファイルの click」を3回操作したユーザたち』というアリガチな[オーディエンス]を設定したい場合は、以下の様な設定になります。

    • Sequence 1
      • Step 1: Across all sessions (全セッション)
        • Event: wpSupportTemplates_clickQar
        • Event Parameter: (null)
      • Step 2: Across all sessions (全セッション)
        • Event: wpSupportTemplates_clickQar
        • Event Parameter: (null)
      • Step 3: Across all sessions (全セッション)
        • Event: wpSupportTemplates_clickQar
        • Event Parameter: (null)

    あるいは、『サポートPageを2回以上見た日本ユーザたち』という[オーディエンス]を設定したい場合は、以下のような設定になります。

    • Condition Group:
      • Geography, Country ID (地域, 国ID):
      • filter: exactly matches (完全一致) JP
    • Sequence 1
      • Step 1: Across all sessions (全セッション)
        • Event: page_view
        • parameter: page_location begins with (先頭が一致) https://support.questetra.com/
      • Step 2: Across all sessions (全セッション)
        • Event: page_view
        • parameter: page_location begins with (先頭が一致) https://support.questetra.com/

    なお “オーディエンスへの追加” を Events として登録することも可能です。さらには Conversion Events として登録することも可能です。(Audience-trigger Events)

    通常の Events は発生時パラメータだけで判定されますが、”Audience-trigger Events” はサーバサイドで判定されます。これは「非常に複雑な Events を実装できる」ということも意味します。 GA4 を使いこなす上で、非常に重要な機能と言えるでしょう。(「最後のイベントのメタデータが、トリガーされたイベントにコピーされる」という仕様が、少し使いづらいかも知れません。)

    ちなみに、デフォルトで “購入者/Purchasers” という特別なオーディエンスがセットされています。ここにも GA4 が Event purchase を重要視していることが表れているように思います。

    正直なトコ、2022年5月現在、この「オーディエンスTriggers」には未完成な印象を感じます。マニュアル表記が “インターフェース” (≒仕様)と異なるケースも多く、また、解決策(パラメータ値のセットや追加等)が明示されていないケースも少なくありません。
    ◇オーディエンスのメンバーシップが更新されたときに追加のイベントを作成する(1 日 1 回まで)
    →”オーディエンスのメンバーシップが更新されると追加のイベントがログに記録されます”
    ◇Create an additional event (up to one per day) when the audience membership refreshes
    →”Log an additional event when audience membership refreshes”
    とは言うものの「オーディエンスTrigger (Events)」は、デキルコトが飛躍的に増える、とても魅力的な機能です。今後の仕様推移を見守りたいと思います。

    Audience-trigger Events

    ◆追伸

    結局のところ、新しい[GA4プロパティ]は、「日々是精進」「習うより慣れよ」です。筆者自身も、コツコツ改善していこうと考えています。 

    CM: 集計値取得業務の自動化

    ところで、「Google Analytics 集計結果の取得を自動化したい」と考えるのは、イマドキ当然です。

    クラウド型ワークフロー『Questetra BPM Suite』なら、ワークフロー設定内に “自動工程” を配置しておくと、日々のデータ取得が自動化されます。 GA4プロパティ対応の自動工程は、どんどん随時追加していく予定です。 (←もし、ご要望等あれば問い合わせフォームよりメッセージください。)

  • オジサン世代向け GA4 概説

    オジサン世代向け GA4 概説

    「GA4」とはナンダ? “Google アナリティクス” は、どう変わったのだ? 報道記事を読んでも、基本的なことが理解できていないので「読解」できない。だれかに「移行させる」にしても、どう指示を出したら良いものか…。 とお考えのアナタ(オジサン世代)のために「GA4の概要」をまとめてみました。

    ◆ Q1. ちなみにタグマネージャーって何?

    『Google Analytics』ならタマに使うから、よく知っている。Webサイトへのアクセスが “トラッキング” される仕組みだ。そう言えば昔は、サーバにログインして “access_log” をゴニョゴニョ〔grep uniq ときどき awk〕してたっけ…。だから “Urchin” (あーちん)が登場した時〔2000年頃〕は、ホント度肝を抜かれた。懐かしい。

    ところで、、、「タグマネージャー」ってナニ??

    A1. 平たく言えば「タグ埋め込み管理システム」です。

    HTML を書き換えることなく、さまざまな「タグ」(Tracking tag)〔←小さなプログラム〕を追加できます。”計測タグ” を HTML に埋め込む作業が不要になるだけでなく、様々な “計測タグ” をいつでもいくつでも、追加・変更できるようになります。

    具体的には2012年、『Google Tag Manager』というサービスが誕生しました。各Webページには「GTMタグ」(親)という “ハコ”(←[コンテナ])だけを用意しておきます。そして “ナカミ” である各「計測タグ」(子)は、Google Tag Manager(GTM)側によってコントロールします。一般には「タグ管理システム」と呼ばれます。

    たとえて言えば、「ビル内の “全ての部屋の電灯” を管理室でコントロールできるようになった!」みたいな感じでしょうか? あるいは「”var intX1, intX2, …;” と個別宣言していたデータを “var arrX” と配列宣言したので詰め込み放題!」みたいな感じかも知れません?!? 誤解を恐れずに真正直に言うなら、「バックドアを作った!」みたいな感じ、です(爆)!
    (バックドア: 正規の手続きを踏まずに内部に入ることが可能な侵入口 by Wikipedia) https://w.wiki/4xbC

    ◆ Q2. 計測や分析はどう変わったの?

    『Google Analytics』は、2020年に大々的にリニューアルされたらしい。そして2023年には強制的に移行させられるらしい。ウチも『ユニバーサルアナリティクスプロパティ』というバージョンから、『Googleアナリティクス4プロパティ』というバージョンになるらしい。”第四世代” という意味くらいまでは…。

    ていうか、スマホアプリの操作ログまで収集できるって、ほんとスゴイ! でも、どうやって収集してるんだ?
    (どうでもイイが、ネーミングの一貫性が無さすぎるトコ…、気に入らん…)

    A2. “Pageview” から卒業することになります。

    操作ログを送信する “計測タグ” (←小さなプログラム)は大きく進化してきました。「ブラウザ進化にあわせて進化してきた」と言っても良いと思います。 具体的には “urchin.js”、 “ga.js”(2007)、 “analytics.js”(2013)、 “gtag.js”(2017)です。 しかし一方で、Analytics 側のログ格納方法やログ分析方法は【Pageview ベース】という点において、変化はありませんでした。

    2020年に登場した『Googleアナリティクス4プロパティ』(GA4)では【Event ベース】に変わりました。要するに、「ページを表示させた」(page_view)だけでなく、「スクロールさせた」(scroll)、「ダウンロードした」(file_download)、「じっくり見た」(user_engagement)といった様々な Event が同列に格納されるようになります。〔計測タグ: “gtag.js” のみ〕

    この変化は、「デバイスの多様化(≒スマホの普及)にあわせて進化した」と言っても良いと思います〔ベータ版時代は『Google Analytics App+Web property』と呼ばれていた〕。 なお “格納庫” に保存データという観点でも、「GA4 Property」とそれまでの「UA Property」に互換性はありません。

    ◆ Q3. データの見方が難しくない?

    新しい『Google Analytics』〔GA4プロパティ〕にログインしてみたけど、メニューは少ないし、グラフも見づらいし、ヨクワカラナイ。

    いろいろ設定しなきゃダメなんだろうけど、[パラメータ]ってナニ? [オーディエンス]ってナニ? 肝心の[コンバージョン]はドコ?

    A3. まずは自社が注目すべき Event を決める必要があります。

    GA4プロパティには「ありとあらゆるユーザ操作」(Event)が記録されるようになりました。つまり「分析の自由度が増した」と言えます。しかし、裏を返せば「分析の難易度も増した」とも言えます。

    記録される Event は、その種類だけでも11種もあります。(←Web に限っています)〔202204時点〕

    • click (outbound link)
    • file_download (pdf,xlsx,docx,,,)
    • first_visit
    • page_view
    • scroll
    • session_start
    • user_engagement
    • video_complete
    • video_progress
    • video_start
    • view_search_results

    どんな Event が記録されているのかが分かってくれば、「自社にとって計測すべき Event」について、再考する必要が出てくると思います。つまり、「ページ遷移」だけを考えるのではなく、加えて「どこどこページにおける〇〇イベント」といった具合に、モニタリングしたい Event を再確認する作業が必要になってくると思います。イベント種類([イベント名]←イベントClass)を増やすことになるかも知れません。

    [GA4プロパティ]の利用開始時には、基本的な設定〔データ保持期間・計測除外IP・クロスドメイン〕も必要です。

    ◆ Q4. ディメンションと指標は健在なの?

    「分析」と言えば、”テーブル” だろ! Analytics の “テーブル” といえば[ディメンション]と[指標](メトリックス)だろ! まだ使えるの?

    ちなみに、[ディメンション]は『ページごとに』とか『地域ごとに』とか、いわゆる “ごとに系の軸” のコト! そして、[指標]は『PV数』とか『セッション数』とか、いわゆる “計測値系の軸” のコト! それくらいは知っている。

    A4. どちらのテーブル軸も進化しています。

    [ディメンション]〔Dimension(s)〕と[指標]〔Metric(s)〕を使って分析することに変わりはありません。

    『Dimension』は “配列型” であり、各値はいわゆる “A列” に〔≒縦方向に〕列挙されます。『指標』は “数値型” であり「Dimension の値」〔A列の値〕ごとに集計表示されます。 指示の例:「毎週、{pagePath} ごとの {screenPageViews} (の数)と {sessions} (の数)を計測しよう!」

    [UA プロパティ]の格納データは、Google Analytics が提供するテーブル軸によって分析されていました。具体的には、Dimension(s) として

    • “ga:pagePath” や
    • “ga:browser” や
    • “ga:country”

    など100種類ほど分析軸が用意され、一方 Metric(s) (指標)として

    • “ga:pageviews” や
    • “ga:uniquePageviews” や
    • “ga:sessions” や
    • “ga:newUsers”

    など50種類以上の計測値が用意されていました。 

    そして[GA4 プロパティ]の格納データも、あらかじめ用意されている Dimension(s)(150超)と Metric(s)(50超)で分析できます。

    Dimensions:

    • “pagePath”,
    • “browser”,
    • “country”,
    • “audienceName”,
    • “videoUrl”, …

    Metrics:

    • “screenPageViews”,
    • “screenPageViewsPerSession”,
    • “sessions”,
    • “newUsers”,
    • “activeUsers”,
    • “conversions”,
    • “eventValue”,
    • “totalRevenue”, …

    しかし[GA4 プロパティ]はさらに、分析軸や計測値を、任意に追加したり詳細化したりすることが可能です。「自社にとって必要な “軸” を考えること」は容易ではありません。 〔[カスタムディメンション]、[オーディエンス]、[カスタム指標]…〕

    UA Dimensions & Metrics Explorer

    GA4 Dimensions & Metrics Explorer (←ログインして利用することになります)

    なお、詳細なグラフやレポートの作成には、[Google データポータル](旧称[Google データスタジオ])や[Google BigQuery]の併用が必要になってくると言えます。

    ◆ 追伸(まとめ?)

    結局のところ、新しい[GA4プロパティ]も、「日々是精進」「習うより慣れよ」だと思います。(「ローマは一日にして成らず」とも言う)

    筆者自身も、コツコツ改善していこうと考えています。

    【追記:2022-05-12】 続編『GA4 Conversion 概説』も書いてみました。

    困った時は公式ドキュメントへ!

  • Questetra: No-Code development platform v14.0, Bulk Work Start Added

    Questetra: No-Code development platform v14.0, Bulk Work Start Added

    Reduces time and effort for entering data

    Original Japanese version

    Kyoto, Japan, Apr. 11th, 2022, Questetra, Inc., the global SaaS provider of Business Process Management (BPM), today announced that they have published the new version 14.0 of the No-Code development platform Questetra BPM Suite. The new version 14.0 allows the operator to start a large number of business cases IN BULK by uploading a business data file.

    As telework is promoted due to the influence of COVID-19, workflow systems that realize digitalization and visualization of business progress are attracting attention. In a common workflow system, the person in charge inputs business data one by one to start a business matter. Therefore, when starting multiple business items, it is necessary to enter data as many as the number of cases. The same was true for Questetra BPM Suite, which is classified as a workflow system.

    From the new version 14.0, the person in charge can start multiple business cases in bulk by uploading a file in which business data is recorded. In the fixed asset valuation, for example, if you upload the fixed asset list file, you can start the workflows for each fixed asset for which a valuation will be performed.

    Questetra BPM Suite

    Questetra BPM Suite is a No-Code development platform for realizing paperless and remote-working environments. You can develop a workflow system with No code by Dragging & Dropping the Step icons. It will help to realize on-site-led digitization, automation, and unmanned operation. This is a cloud SaaS service for ISO-certified companies, BPO contractors, and corporations who want to work on continuous process improvement.

    You can apply it to various business operations such as an Approval request flow, Document translation flow, Quality check process, and Invoice issuance process. Process owners of each Business Process can practice the Improvement of Business Processes little by little in daily work. (Examples of Business Flow Diagrams: https://questetra.zendesk.com/hc/en-us/articles/360012492211 )

    Business Issues Bulk Start

    When the person in charge uploads the business data list file created in the TSV (Tab Separated Values) format, business issues corresponding to the number of lines in the TSV can be started in a batch in the state in which the business data has been entered. You can also download the TSV file template corresponding to the Workflow App.

    Business Issues Bulk Start Operation Overview

    Other Improvements

    Google Drive: add sharing scope

    This new Service Task allows you to control the addition of sharing scopes for files and folders in Google Drive. For example, it will be possible to build a mechanism where once a draft of the in-house notification document is approved, it automatically sets the document that previously only had viewing permissions for the section so that viewing permission is given to the entire company (with the domain). *Available Editions: Advanced, Professional

    Embedding video on the Process Operating Form screen

    You can now embed HTML video tags in Process Operating Form screens. By showing the video of how to handle the Task on the Operating Form using the video tag, it is expected to reduce the cost of education for workers and reduce work mistakes.

    Displaying a list of Business Issues that have stagnated other than the human Tasks

    Previously, in the list of stagnant Business Issues (Heatmap function), only the human Tasks (*) in the workflow diagram could be displayed. From version 14.0, it is possible to display a list of stagnant Business Issues even for items other than human Tasks, such as a Step that waits for an HTTP request. *Steps to be handled by humans

    Ver. 14.0 Release Note: https://support.questetra.com/versions/version-140/

  • No-Code 開発基盤 v14.0、業務案件一括開始を追加

    No-Code 開発基盤 v14.0、業務案件一括開始を追加

    SaaSベンダーの株式会社クエステトラ(京都市、代表執行役 CEO 今村元一)は4月11日、No-Code 開発プラットフォーム 『Questetra BPM Suite』 の新バージョン14.0を公開しました。新バージョン14.0からは、担当者が業務データファイルをアップロードすることで、大量の業務案件を “一括” スタートできるようになります。

    コロナ禍の影響でテレワークが進む中、電子化や業務進捗の見える化を実現するワークフローシステムが注目されています。一般的なワークフローシステムでは、業務案件を開始する際、担当者は1件ずつ業務データを入力します。従って、複数の業務案件を開始する場合には、その件数分の入力が必要になります。ワークフローシステムに分類される『Questetra BPM Suite』も、この点について同様でした。

    新バージョン14.0からは、担当者は業務データが記録されたファイルをアップロードして、複数の業務案件を一括開始できるようになりました。例えば、固定資産の評価業務で、固定資産一覧ファイルをアップロードすると、それぞれの固定資産に対して評価が行われる業務案件を一括開始できます。

    Questetra BPM Suite とは

    『Questetra BPM Suite』は、ペーパーレス環境やリモートワーク環境を推進するための No-Code 開発プラットフォーム です。業務案件は業務フロー図に従ってコントロールされ、案件が人間工程に到達すれば担当者はアウトプットを求められます。また、案件が自動工程に到達した際には、「PDFの生成」や「クラウドストレージへの保存」といった既定の処理(サーバサイド処理)が自動的に行われます。(BPM: Business Process Management)

    「稟議承認フロー」「文書翻訳フロー」「品質チェックプロセス」「請求書発行プロセス」といった様々な業務に適用していただけます。各業務のプロセスオーナーは日々の業務の中で少しずつ「業務プロセスの改善」を実践できます。

    (業務フロー図サンプル: https://questetra.zendesk.com/hc/ja/articles/360012492211

    業務案件一括開始

    TSV(Tab Separated Values)で作成された業務データ一覧ファイルを、担当者がアップロードすると、行数分の業務案件を、業務データが入力された状態で、一括開始させられるようになりました。ワークフローアプリに応じた、TSVファイルのテンプレートをダウンロードすることもできます。

    その他の機能改良について

    Google ドライブ 共有範囲の追加

    自動処理工程を利用して、Google ドライブのファイルやフォルダについて共有範囲の追加をコントロールできるようになります。例えば、社内通達文書の原稿が承認されると、それまで部内でのみ閲覧許可されていた原稿が、全社(ドメイン)で閲覧許可されるように自動設定される仕組みを構築できるようになります。※対象エディション: Advanced, Professional

    工程処理フォーム画面に動画挿入

    工程処理フォーム画面に HTML の video タグを埋め込めるようになりました。video タグを利用して工程処理のマニュアル動画が表示されるように設定すると、作業者への教育コストの抑制や業務ミスの低減が期待されます。

    ヒューマン工程以外に滞留した業務案件の一覧表示

    従来、ワークフロー図において滞留した業務案件の一覧はヒューマン工程(※)でのみ表示可能でした(ヒートマップ機能)。バージョン14.0より、HTTPリクエストを待ち受けるアイテムなど、ヒューマン工程以外のアイテムでも、滞留している業務案件の一覧を表示させられるようになりました。※人に処理される工程

    詳細については、リリースノートを御参照ください。

  • 請求書発行と入金確認をノーコードで自動化する方法(  PayPal 編)

    請求書発行と入金確認をノーコードで自動化する方法( PayPal 編)

    企業の請求業務では、請求書の作成/送付や、入金確認に手間がかかりがちです。同記事では、これらの請求業務を自動化し、手間の軽減に加え、ミスを防止し、業務品質/効率を上げる方法をご紹介します。

    自動化に必要なツール

    請求業務の自動化に必要となるツール(クラウドサービス)は以下の2つです。

    • PayPal
    • Questetra BPM Suite

    PayPalとは?

    PayPal(ペイパル)とは、米国の決済代行サービスです。

    PayPalアカウント間の送金や決済が可能です。PayPalアカウントに、銀行口座(振替)やクレジットカード、デビットカードなど複数の決済サービスを紐づけられます。そのため、1つのアカウント(メールアドレスID/パスワード)で複数決済が可能です。

    Questetra BPM Suiteとは?

    Questetra BPM Suiteとは、業務システム開発プラットフォームです。

    ノーコード/ローコードで業務システム(ワークフローアプリ)を構築できます。複数部署/担当者が関わる様々な「業務プロセス」を電子化し自動化します。PayPalの他にも、以下のようなクラウドサービスとAPI連携し、各サービスの自動処理が可能です。

    • GoogleWorkspace
      • Googleドキュメント、Googleスプレッドシート、Googleスライド、Googleグループ、Googleドライブ、Googleカレンダー、Gmail
    • Microsoft 365
    • Box
    • kintone
    • Slack
    • WordPress
    • Stripe
    • Salesforce
    • Google BigQuery
    • Google Analytics
    • Google Fit
    • Google 翻訳
    • DeepL
    • AirTable
    • SendGrid
    • ChatWork
    • Typetalk
    • Backlog
    • Image-Charts
    • Zendesk Support

    など

    自動化の仕組み

    Questetra BPM Suiteに入力された※1 請求情報(メールアドレス/会社名/担当者名/請求金額/請求日など)をもとに、PayPal上で請求書の下書きが自動作成されます。(この際、Questetra BPM SuiteはPayPalに、請求情報を送信するとともに、請求書の下書きを作成させるシグナルを送ります)

    PayPal上で作成された請求書を請求先に送信するよう、Questetra BPM SuiteがPayPalに対してシグナルを送ります。

    Questetra BPM SuiteがPayPal上にある請求先※2 の支払い状況を取得します。

    ※1. 既に取得している情報を自動的に差しこむことも可能です。

    ※2. 本記事の自動化を実現するためには、請求先(支払者)がPayPalアカウントを持っている(作成する)必要があります。

    請求書の作成/送付と入金確認を自動化する方法

    Questetra BPM Suiteでは、以下の図のようなワークフロー図が業務システム(ワークフローアプリ)の設計図の役割を果たします。

    作成されたワークフロー図上には、人間が処理する工程と(システムにより)自動処理される工程が存在します。これらの工程は、開始工程から終了工程まで順番に処理されます。


    <PayPal自動請求>

    上の図は、「PayPal自動請求」のワークフロー図です。具体的な処理の流れは以下の通りです。

    1. 人が処理する工程:請求内容(請求先情報/請求金額/支払期日など、ワークフローアプリを作成した際に予め設定した項目)を入力します。
    1. 自動処理工程(PayPal請求書生成アイテム):1で入力した情報をもとに、PayPal上に請求書の下書きが自動生成されます。
    1. 自動処理工程(PayPal請求書送信アイテム):2で生成された請求書(請求メール)が請求先に自動送付されます。
    1. 自動処理工程(タイマーアイテム):1で入力された「支払期日」の翌日まで待機します。(設定した期間、同工程で待機します)
    1. 自動処理工程(PayPal支払状況確認アイテム):請求案件について、支払状況が自動的に取得されます。

    この様に、プロセス(開始工程から終了工程までタスクが遷移すること)が開始されると、請求情報を入力するだけで、請求書作成から請求書送付、入金確認までが自動化されます。

    請求業務を自動化する方法

    前項でご紹介したシンプルなワークフローアプリを応用すれば、実際の請求業務を自動化することが可能です。

    例えば、複数部署が関わり、部内での承認を含む請求業務においても、PayPalの自動処理アイテムを使うことで自動化できます。実際のサンプルワークフローアプリが、以下のサポートサイトで閲覧できます。

    この様に、Questetra BPM Suiteを使えば、様々な業務に対応した業務システムをノーコード/ローコードで構築できます。API連携されたクラウドサービスの自動処理も可能です。

    業務の電子化/自動化。一度、ご自身の手で試してみてはいかがでしょうか?

  • Introduced Update Date Choice system

    Introduced Update Date Choice system

    Original Japanese version

    Convenience improvement for Pre-renewal Verification

    Kyoto, Japan, Mar. 25th, 2022, Questetra, Inc., the global SaaS provider of Business Process Management (BPM), today announced that they are going to introduce updating schedule options for the cloud-based workflow, Questetra BPM Suite, on and after April the 1st.

    Conventionally;

    On the release date of the new version, all customers’ workflow platforms were updated. (Notice announced principally 2 weeks in advance)

    Hereafter (on and after April 1, 2022);

    • Workflow platforms for which [Rapid Update] is chosen will be updated on the release date of the new version
    • Workflow infrastructures for which [Scheduled Update] is selected will be updated approximately one month after the release date of the new version

    However, updates with a bug fix version (patch version) will be applied to all workflow platforms.

    Demands for Pre-verification

    In recent years, due to the declining workforce and COVID-19 effect, further improvement in work quality and productivity has been required. Many companies are actively pursuing business reforms that utilize IT to meet these demands.

    Specific examples include the automation of operations that realize labor-saving and unmanned operation, and the construction of a telework environment that includes the utilization of cloud services.

    Customers who are using Questetra BPM Suite are no exception to these efforts. In particular, Questetra BPM Suite is used for business automation and data linkage with multiple cloud services.

    There was a problem using Questetra BPM Suite, as the automatic processing did not work as expected due to the update, especially when the customer’s own automatic processing was set.

    Previously, the verification workflow platform (“Online Demo Platform”) which has no access restrictions was used to verify the new version. However, since it is also a workflow platform that anyone can access it was difficult to verify, for example, for scripts used in actual business. In addition, the update of the verification workflow platform to the new version was done only one week in advance of the customer’s platform update, and it was an environment where a sufficient verification period could not be taken.

    Based on this background, you will be able to choose the update to the major/minor version (*), either;

    • at the same time as the release of the new version [Rapid Update]
    • about one month after the release of the new version [Scheduled Update]

    This makes it easier to verify scripts used in actual business by separately subscribing to a workflow platform for verification and selecting [Rapid Update]. In addition, the period until the [Scheduled Update] is about one month, so you will be able to secure a sufficient verification period.

    * Version notation X.Y.Z (e.g. 13.2.1) means that X is the major version, Y is the minor version, and Z is the patch version. (Semantic versioning)

    Starting

    From the update to the new major version scheduled for April 2022.

    * This update is performed only with the workflow platform for verification of sales partners by [Rapid Update], and for the customer’s platforms, it will be performed by [Scheduled Update] about one month after [Rapid Update].

  • アップデートスケジュール(更新日)の選択制を導入

    アップデートスケジュール(更新日)の選択制を導入

    SaaSベンダーの株式会社クエステトラ(京都市、代表執行役 CEO 今村元一)は、2022年4月1日以降、クラウド型ワークフロー『Questetra BPM Suite』のアップデートスケジュールについて選択制を導入します。

    従来

    新バージョンの公開日に、すべてのお客様のワークフロー基盤がアップデートされていました。(予告アナウンスは原則2週間前)

    今後(2022年4月1日以降)

    • [即時アップデート] が選択されているワークフロー基盤は、新バージョンの公開日にアップデートされるようになります。
    • [計画的アップデート] が選択されているワークフロー基盤は、新バージョンの公開日から約1ヶ月後にアップデートされるようになります。

    ただし「不具合修正バージョン(パッチバージョン)にともなうアップデート」はすべてのワークフロー基盤に適用されます。

    事前検証ニーズ

    ここ数年、労働者人口の減少やコロナ禍等により、より一層の業務品質の向上、生産性の向上が求められるようになりました。多くの企業では、このような要求に対応するために IT を活用した業務改革が積極的に進められています。

    具体的には、省力化・無人化を実現する業務の自動化、クラウドサービスの活用などを含むテレワーク環境の構築などが挙げられます。

    これらの取り組みは Questetra BPM Suite をご利用のお客様も例外ではありません。特に業務の自動化や複数のクラウドサービスとのデータ連携などに、Questetra BPM Suite が活用されています。

    Questetra BPM Suite の活用において、特にお客様独自の自動処理が設定されている場合、アップデートの結果、それらの自動処理が期待通りに動作しなくなる、という問題がありました。

    従来は、アクセス制限のない検証用ワークフロー基盤(”Online Demo Platform”)にて、新バージョンを検証していただいていました。しかしながら、誰でも利用できるワークフロー基盤でもあり、たとえば「実業務で使われているスクリプト」等を検証しづらい環境であったと言えます。また、検証基盤が新バージョンに更新されるのは有償基盤の2週間前であり、十分な検証期間が取れない環境であったとも言えます。

    このような背景を踏まえ、メジャー・マイナーバージョン(※)への更新(アップデート)について、

    • [即時アップデート] 新バージョンの公開と同時
    • [計画的アップデート] 新バージョン公開から約1ヶ月後

    を選択して頂けるようになります。

    これにより、別途 “検証用のワークフロー基盤” をご契約いただき、[即時アップデート]を選択していただくことで、「実業務で使われているスクリプト」等を検証しやすくなります。また、[計画的アップデート]までの期間は約1ヶ月ですので、十分な検証期間を確保していただけるようになります。

    ※ バージョンの表記 X.Y.Z(例:13.2.1)とした場合、X はメジャーバージョン、Y はマイナーバージョン、Z はパッチバージョンと呼ばれます。(セマンティックバージョニング)

    適用時期

    2022年4月に予定されている新メジャーバージョンへのアップデートから。

    ※このアップデートは、販売パートナー様の検証用ワークフロー基盤のみ [即時アップデート] で行われ、その他の有償でご利用のお客様の基盤は [即時アップデート] から約1ヶ月後に [計画的アップデート] で行われます。

  • What is MQL and PQL?

    What is MQL and PQL?

    From the time a person learns about a product (including goods and services) to the time they make a purchase, they go through various stages. The product provider wants to find customers who are more likely to buy the product and encourage them to buy it sooner.

    Therefore, MQLs, SQLs, and PQLs are level classifications of the awareness/status of potential customers (leads) who are interested in the company’s products, based on their behaviors.

    These are concepts that have been used predominantly in marketing for the past decade. In this article, we will examine the meaning of the terms and how they (lead level identification and management) can be automated.

    What are the Four QLs?

    A Qualified Lead (QL) is a potential customer who meets certain criteria; QLs increase in level from IQL to MQL to SQL/PQL as the probability of purchase/paying increases.

    ※Of these, IQL and PQL are already broadly defined, whereas MQL and SQL are defined differently by each company. Therefore, the relative level and position of each of these differ from company to company. In particular, PQLs should be considered as a separate layer.

    Lead Level

    What is an IQL?

    Potential customers whose contact information is known among the leads are called Information Qualified Leads (IQLs).

    Specifically, these are leads that received helpful materials, white papers, or other information in exchange for providing an email address or other information.

    At this point, the lead is aware of their problem but both the lead and product provider does not know if the product will solve that problem.

    Therefore, the marketing team should take steps to understand the issues that the lead is facing (through surveys, interviews, etc.) and provide examples of issues that can be solved with the product (through video content, webinars, etc.).

    Through such efforts, it is necessary to increase leads’ willingness to purchase the product by making them aware that the product is a good match for their issues.

    What is an MQL?

    MQLs (Marketing Qualified Leads) are prospects to focus marketing efforts on, also known as Warm Leads (soon-to-be customers).

    Leads that meet the (company-determined) criteria are defined as MQLs. This reduces unnecessary marketing costs and lost opportunities (i.e. the risk of missing out on promising prospects) by eliminating inappropriate leads that are unlikely to purchase your product.

    Examples of criteria include:

    • Repeated visits to specific pages (features/prices/examples, etc.)
    • Must have downloaded product literature
    • Know the name of the company (for B to B) / name of the person in charge / phone number.
    • Participation in a webinar
    • Customers must have a problem that can be solved by the product (e.g. survey respondents).

    In other words, leads that are looking for products that can solve their problems and leads that can be specifically contacted with the possibility of making a purchase.

    Marketing and internal sales will conduct marketing activities such as offering free trials and free consultations to these MQLs.

    While defining leads in this way allows for effective marketing activities, the following challenges exist when determining MQLs. To understand site visits it is necessary to track/record lead behavior by referring to access analysis tools. In addition, if multiple criteria have been established it is important to understand how well the other criteria are being met, so it becomes necessary to organize and devise methods of obtaining and recording information. Doing these manually takes a lot of time.

    What is an SQL?

    SQLs (Sales Qualified Leads) are prospects that should be the focus of your sales efforts, also known as Hot Leads (immediately-to-be customers).

    Examples of criteria for determining SQL include:

    • Have actually tried the product by signing up for a free trial or free sample
    • Must have applied for a free consultation
    • Requested an estimate
    • Must have signed up for a demo
    • Budget must match product price
    • Company size (as determined by the company) must be greater than or equal to the criteria
    • Permission for sales to contact them

    SQLs believe that using the product may solve their own problems. They also have a certain level of willingness or ability to purchase the product.

    The sales representative will contact the SQL directly and suggest ways to solve the issues that the lead has. In the case of SaaS business, we also provide support on how to use the product by offering free trials. These efforts can lead to a purchase/contract.

    What is a PQL?

    So what is a PQL?

    PQLs (Product Qualified Leads) are promising prospects who have signed up for a free trial or free edition of a product.

    PQLs have the intent to use the product and therefore have the potential to purchase it. Therefore, as a level of prospect, they are the closest leads to SQLs. (However, it is necessary to determine if the lead is a true PQL based on the frequency of trial use and interviews, as it is possible that the lead may have applied for the product by mistake or for incentive purposes.)

    As with SQL, the main activities for PQLs will be to propose solutions to issues that leads have and to provide assistance on how to use the products.

    How to Automate MQL and PQL Identification/Management

    It is very difficult to manually obtain the information that will be used as the basis for these QL decisions and to make conformity judgments. In particular, tracking/recording lead behavior by multiple criteria can be time-consuming, costly and error-prone.

    The cloud-based no-code development platform Questetra BPM Suite can be used to automate MQL and PQL identification/management.

    In Questetra BPM Suite the workflow diagram is the blueprint of the business system. Therefore, you can construct a business system by drawing a workflow diagram. It is also possible to operate the created workflow diagram as it is as a business system.

    If you want to create an automatic identification/management system (workflow application) for MQLs and PQLs, organize the criteria for decision-making and the management method for MQLs/PQLs from which the criteria information is obtained. Based on the organized information a workflow diagram can be created to show who processes what and in what order.

    There are two types of processes on a workflow diagram: processes that are handled by humans and processes that are handled automatically by the system. In the human process an input form (processing screen) is automatically created by setting input/selection items. In the automatic process you can set how the workflow is automatically processed.

    With Questetra BPM Suite such a Workflow App (business system) can be built with no code. In addition, samples (templates) can be downloaded and used immediately. If you are interested, please try it out.

  • WordPress投稿をノーコードで自動化する方法

    WordPress投稿をノーコードで自動化する方法

    企業において、コーポレートサイトや、製品(商品/サービス)サイトを自社で制作/更新する際、WordPressを利用するケースは多いでしょう。
    今回は、WordPressの「投稿(post)」や「ページ(page)」の投稿作業の一部を自動化し、作業を省力化する方法をご紹介したいと思います。

    WordPressへの投稿を自動化する方法

    準備するツール(クラウドサービス)

    使用するツールは、「WordPress」と「Questetra BPM Suite」です。Questetra BPM Suiteとは、ノーコードで業務システムを構築できる業務システムプラットフォームです。Questetra BPM Suiteでは、システムの設計図となる「ワークフロー図」を作成します。これにより、ワークフロー図上に設置した工程が、設置した順に処理されていきます。

    下書きが自動作成される仕組み

    Questetra BPM Suiteに、記事を投稿したいサイトの情報やタイトル、投稿内容などを設定(入力)します。設定情報をもとに、WordPressに下書き記事(草案)が自動的に作成されるようQuestetra BPM Suiteからシグナルが送信されます。WordPressに下書き記事が自動的に作成され、下書き記事のURLなどの情報がQuestetra BPM Suiteに送信されます。

    WordPressに投稿されるまでの流れ

    下の図は、WordPressに投稿されるまでの流れを描いたワークフロー図です。WordPressに下書きが自動投稿される自動処理アイテムを使用します。

    <WordPress記事投稿ワークフロー図>

    具体的には、以下の順でWordPressへの投稿が完了します。

    1. 人が処理する工程:タイトル/記事本文/抜粋/投稿タイプ(post/page)などを設定(入力)する。
    2. システムが処理する工程(自動処理アイテム):1で設定された情報をもとに、WordPressに下書きが自動的に作成される。
    3. 人が処理する工程:WordPress の編集画面で確認し、下書きを「公開」にする(作業後に[投稿]ボタンを押す)。

    この業務プロセスを採用することで、投稿者の作業は、下図のような入力フォームにある必要項目を入力し、出来上がった下書きを確認/投稿ボタンを押下するだけです。そのため、投稿作業が単純化され省力化されます。

    ※入力フォームの項目は、工程毎に作成/設定できます。

    業務プロセスで活用する方法

    Questetra BPM Suiteは、複数人/複数部署が関わる組織で使用できる点が大きな特徴です。サイト制作や更新において、特にコーポレートサイトや製品ページなどでは、正確な情報を掲載する必要があります。そのため、複数の部署/担当者が、内容に間違いがないかを確認する必要があります。Questetra BPM Suiteは、この様な社内における部門横断的な業務プロセスを実現するために役立ちます。

    また、Questetra BPM Suiteでは、複数人/複数部署が関わる業務プロセス内に、自動化アイテムを使用できます。作成するワークフロー図内には、人が処理する工程(投稿文作成や内容確認など)とシステムが処理する工程(記事下書き自動作成アイテムなど)の双方を設置できます。そのため、組織が関わる業務においても、効率化/作業の省力化が可能です。以下のワークフロー図は、WordPressに記事の草案が自動的に追加されるアイテム(自動処理工程)を組織における業務プロセスに使用した例です。

    具体的な工程処理の流れは以下の通りです。

    1. 人が処理する工程:タイトル/記事本文/抜粋/投稿タイプ(post/page)などを設定(入力)する。
    2. 人が処理する工程:1で設定された内容をチェックする。要修正の場合は、修正するよう差し戻す。
    3. システムが処理する工程(WordPress記事草案自動追加アイテム):1で設定された情報をもとに、WordPressに下書きが自動的に作成(追加)される。
    4. 人が処理する工程:WordPress の編集画面で確認し、下書きを「公開」にする(作業後に[投稿]ボタンを押す)。
    5. 人が処理する工程:投稿された内容をチェックする。要修正の場合は、修正するよう差し戻す。

    この様に、Questetra BPM Suiteを使えば、WordPressに下書きが自動的に作成(追加)されるため、作業時間の短縮による業務の効率化や省力化が可能です。また、ワークフロー図通りに仕事を進めていけるため、業務のムラを防止できます。これ以外にも、業務プロセスにチェック担当/工程を入れることで、ミスの軽減による業務品質の向上を実現することも可能です。ご興味のある方は、是非お試しください

  • Google Analyticsからアクセス数をノーコードで自動取得する方法

    Google Analyticsからアクセス数をノーコードで自動取得する方法

    サイトに集客する際、どのページのアクセス数が伸びているかを定点観測し、次に繋げたいものです。
    今回は、Google Analyticsでサイトの「アクセス数/アクセスランキング」を確認する作業をノーコードで自動化する方法をご紹介します。

    アクセス数を自動取得する方法

    準備するツール(クラウドサービス)

    ノーコードでサイトのアクセス数やアクセスランキングを自動取得するのに必要なツールは、以下の2つです。

    • Questetra BPM Suite
    • Google Analytics

    クラウド型ワークフロー「Questetra BPM Suite」では、アクセス数を自動取得するアイテムを使うことで、ページビュー数やセッション数など様々な情報(※1)が取得される仕組みを構築できます。また、その結果がレポートされる方法を複数の方法(※2)の中から選べます。アクセス解析サービス「Google Analytics」は、Questetra BPM Suiteからのリクエスト(設定条件に合致するアクセスデータの取得要求)に応答し、アクセスデータを渡します。(サイト計測の設定は既に実施されているものとします)

    ※1. 取得できる主な情報は以下の通りです。(指定したサイト/ホスト/ページと、指定した期間の)

    • ページビューランキング
    • ページビュー数
    • ユニークページビュー数
    • セッション数
    • 閲覧開始数

    …など

    ※2. 指定できる主な方法は以下の通りです。

    • 指定アドレスへのメール自動送信
    • Slackへの自動投稿
    • Googleスプレッドシートへの自動入力
    • Googleドキュメントへの自動入力
    • Googleドライブへの自動保存

    …など

    自動取得する仕組み

    Questetra BPM Suiteで、アクセスデータを取得したいサイトの情報や計測条件などを設定(入力)します。その情報をもとに、Google Analyticsから該当するアクセスデータを自動取得します。取得された情報はQuestetra BPM Suiteに取りこまれ、予め設定した方法で報告されます。

    アクセスランキング取得までの流れ

    Questetra BPM Suiteにおいて、下図「アクセスランキングを自動取得するワークフロー図イメージ」の様に設定(ワークフロー図を作成)した場合、アクセスランキング取得までの流れは以下のようになります。

    1. 自動処理工程(タイマー起動アイテム):毎週月曜日の8時にプロセス(ワークフロー図上のタスクが開始から終了まで遷移する一連の流れ)が自動的に開始されます。

    2. 自動処理工程(Google Analytics アクセス数自動取得アイテム):API連携されたGoogle Analyticsから、設定条件にあったアクセスデータが取得されます。

    3. 自動処理工程(メール自動送信アイテム):設定した送信先/内容に自動送信されます。設定により2で取得したアクセスデータをメール内容に差し込まれます。(データ成型も可能)

    <アクセスランキングを自動取得するワークフロー図イメージ>

    業務プロセスにおける活用方法

    Questetra BPM Suiteの特徴の一つとして、複数担当者/部署の業務を連結できる点が挙げられます。そのため、複数人(複数部署)が関わる業務プロセス(業務フロー図)の中に、アクセス数が自動取得されるフローを組み込むことが可能です。以下のワークフロー図は、人事部、マーケティング部、カスタマーサービス部の担当者が、制作担当者に部門サイトのページ制作/更新を依頼する業務プロセスです。

    <サイト制作/確認プロセス例>

    具体的な流れは以下の通りです。

    1. 人が処理する工程:各部門がページ制作を依頼する。
    2. 人が処理する工程:制作担当者が依頼を受ける。(ページ制作/更新する)
    3. 人が処理する工程:各部門が成果物を確認する。
    4. 自動処理工程(条件分岐アイテム):修正依頼箇所があれば「修正」工程へ遷移し(制作担当者に修正依頼され)、修正がなければプロセスが終了する。

    この業務プロセスに、先ほどの「自動処理工程(Google Analytics アクセス数自動取得アイテム)」を加えます。

    <アクセス数が自動取得されるサイト制作/確認プロセス>

    これにより、以下の様に制作したページのアクセス数を自動取得する(自動報告を受ける)ことが可能となります。(つまり、ページ制作後の効果測定をセットにした業務プロセスとすることができます)

    1. 自動処理工程(タイマーアイテム):(予め設定した期間である)7日間待機した後、次の工程に自動的に遷移します。
    2. 自動処理工程(データ更新アイテム):制作されたサイト/ページ情報が自動的にセットされます。
    3. 自動処理工程(Google Analytics アクセス数自動取得アイテム):2でセットされたサイト/ページ情報をもとに、Google Analyticsのデータが自動取得されます。
    4. 自動処理工程(メール自動送信アイテム):(3で取得したアクセスデータの差込など)予め設定した内容で、予め設定した送信先にメールが送信されます。

    この様に、Questetra BPM Suiteを使えば、ノーコードでサイトのアクセス解析を自動化できます。ワークフロー図を作成することで、業務システム(ワークフローアプリ)を構築できます。

    アクセス数の取得を自動化することで、本来人が時間をかけるべき「データを見て戦略を練ること」に注力できるようになります。ご興味のある方は、是非ご自身の手でお試しください。

  • 業務プロセス・ワークフローと「行動デザイン」(前編)

    業務プロセス・ワークフローと「行動デザイン」(前編)

    こんにちは。クエステトラの木村です。
    突然ですが、皆さんは「行動経済学」「社会心理学」といった言葉をご存知でしょうか。ここ近年、特にビジネスの分野でも目にすることが多くなってきた様に思いますが、個人的にはビッグデータが流行り出した後に、「データから人の行動を理解する」という文脈でも多く使われてきた気がしています。

    行動経済学 Wikipedia
    社会心理学 Wikipedia

    さて、今回なぜ上記の言葉に触れたかというと「自分自身の行動」を変えたかった時があったからです。
    まあ「仕事のある場面で出てくる癖を直したい」でも良いですし、「ある特定の技術に習熟したい」でもなんでもいいんですが、こういった「朧げな目標」に対して、先送りにしてしまう自分がいるわけです。

    「今はAの方が優先度・緊急度が高いので、◯◯は次にしよう」
    「◯◯を行うにはアレとコレが準備されていないといけないので、次にしよう」

    と。さて、行動経済学から発展して、これらの概念を個人に対して適用することを試みた人がいます。
    B.J.Fogg PhD さんです。

    行動デザイン

    (B.J.Fogg PhD)は25年以上スタンフォード大学と連携しており、さまざまなクラスで教鞭をとりました。
    現在も副教授として健康と人間のパフォーマンス部門(HHP)の副教授に任命されています。さてそんな彼が世界に打ち出したものが「行動デザイン」です。「意志の力(モチベーション)」に頼らずに目標を達成するため、「行動」をデザインするというやり方です。と聞くと、なんだか物々しい感じもありますが至ってシンプルな考え方です。

    B=MAP

    上の図は彼が「行動デザイン」を提唱するにあたり、前提となる考えを示しています。それは B=MAP、「行動」は「モチベーション」&「能力」&「きっかけ」が一定の条件を満たした時に起こる、というものです。具体例を示します。

    行動デザインの例

    私が住む町の隣の駅前には、BIG ISSUEという有料フリーペーパーを販売している方がいらっしゃいます。
    (有料だけどフリーペーパーと呼ばれているのは無視してください)

    ※BIG ISSUE=雑誌(有料フリーペーパー)をつくりホームレスの人の独占販売事業とすることで、ホームレス問題の解決をはかる試み。
    ホームレスの人の救済(チャリティ)ではなく、仕事を提供し自立を応援する事業。ロンドン発祥。

    私はこの駅を訪れた際、販売者がその場にいる時には必ずこの雑誌を購入しています。

    では何故、この「行動(毎回購入する)」が起こるのでしょうか。
    以下に簡単に説明します。

    • モチベーション:頑張っている人を応援したい。
    • 能力:450円なら払える。またそもそも外出時なので、手元にお金を持っている。
    • きっかけ:駅前に販売者がいなかったら、購入していない。

    上記の様に、モチベーションと能力、そしてきっかけが「バチ」っとはまり、私は行動を起こしたわけです。
    多分、上記のうちの何か一つがかけていた場合には、行動を起こさなかったであろうと思います。

    以下の図は、今回の行動がどの様な見方ができるのかを示した図です。モチベーションと能力が高い場合には、行動を起こす分岐点となる「行動曲線」を容易く越えます。そして「きっかけ」さえあれば、行動は起きるということですね。

    きっかけ=トリガー

    行動デザインでは「AをしたらBをする」という風に、ある行動をトリガーとして捉え、次の行動を促します。実はこのトリガーが先ほどの公式(B=MAP)にあったP(Prompt。きっかけ)なのです。例えばですが、朝起きたらカーテンをあけます。しかしこの行動は、誰かに頼まれて実行していることでも、目標をたてているわけでもありません。「起きる」という行為自体が、トリガーとして無意識のうちに次の行動を促しているのです。

    きっかけを考える

    さて、それでは次にトリガーの例を考えてみます。ここでは「読書」を取り上げてみます。仮に、私は読書家になりたいと思いつつ、なんら読書ができていない状況だとします。あれやこれや計画を立てるも上手くいかない。そんな際の失敗するパターンは以下の通りです。

    • 頻繁に読書する(予定を立てる!またはそう心に誓う)
      → 予定を立てるだけでは、その他の行動となんら結びついていないため、意志の力(モチベーション)を必要とする
    • 読書をする時間をカレンダーに入れておく
      →予定通りに行かない際に立ち消える。
      また、カレンダーのリマインダーなどで「行動」を促すことはできるが、その他の事項との優先順位に負けてしまう事が多々ある(いつでもできると考えるため)

    要は「AをしたらBをする」という、意志の力を使わずとも関連づけられるトリガー(きっかけ)が設計されていないわけですね。
    では、具体的にどの様な「行動デザイン」をもち、読書が可能となるのでしょうか。答えの一例が以下となります。

    • 目標:読書をしたい
    • 課題:本を読む時間がない
    • 行動デザイン:朝起きたら、枕の上に本を置いて部屋を出る。寝る前に1ページだけ読むことにする。

    上記はAをトリガーとしてBをする(またはBをするための補助をAでする)という行動デザインです。私もこの方法を取り入れた結果、毎日少しずつ本を読むことが習慣となりました。(読書家に成れた気がします)「ほんとかな?」と疑いたくなりますが、1日の仕事を終え寝床に着く際に枕の上に本が置いてあるとめくってみたくなるものですよ。お勧めします。

    業務プロセス・ワークフローと行動デザイン

    とまあ、「行動デザイン」って面白いなーと感じる私は、日中は弊社でマーケティングを担当しています。無論、弊社の業務は Questetra BPM Suite であらゆる業務がアプリ化(ワークフロー化)されています。この様な環境で自社のワークフロー図を見ていると「あ、これは使える(意識の力を必要とせずに、業務を動かす)」と感じるものがありましたので、2部に分けてブログ記事にしてみる事にしました。さて、前編となる今回はAをしたらBをする(もしくはBをするためのトリガーがたちあがる)です。

    意志の力(モチベーション)を使わずとも仕事をすすめるコツ

    業務の中で毎日行わなければいけない事は、探すと結構出てきます。例えばですが、日報、朝会、夕礼、数値計測、進捗確認、制作作業などなどです。ここでもう結論から述べてしまいますが、例えば朝出社すると「今日のあなたの仕事はこれです」とタスクが明示されていたら、めちゃくちゃ楽だと思います。おまけに、そのタスク全てに順番(優先順位)が割り振られている場合、もっと楽になりますね。なぜなら意志の力を使わずとも順序よくこなせば1日の仕事が終わるからです。

    「そんな簡単にいくかいな」という異論は受け付けます(笑)もちろん、発生ベースで自分のタスク以外に費やす時間はどうしても出てきます。それでもですよ。毎日自動で自分のタスクが明示される環境は「自身が処理すべき”核”の部分のタスクはこれである」と認識する事ができるため、相対的に他のタスクに割り当てられる時間を柔軟に割り当てる事ができるためです。と、説明というか論説で説得する様な文章になってきたので、具体的な項目を説明していきますね。

    行動デザインパターン

    • AをしたらBをする
    • 出社したら、タスクAを処理する。(自分のタスクリストにタスクAを割り当てる)

    これはもうめちゃくちゃ簡単です。下の図の様に「タイマー」で平日の定時にタスクを起動させる事がもっともシンプルで楽です。

    タイマーで自動起動されたタスクは、以下の図の様に「マイタスク」に表示されます。
    後は処理するだけです。

    「なんだ、これだけか。こんな内容は聞かずともわかるわい!」と考える方がいらっしゃると思います。はい。その意見は正しいです。しかし、「わかる」事と「実施できる(習慣化)」できることは別です。また今回の例は、「行動デザイン」を説明するために極端に簡素化された例です。まずは素直に「意志を使わないきっかけ」というものに頼れることを理解していただけると幸いです。

    なぜなら、これまで単純に「タイマーで起動すればいいじゃん」と考えていた対象「意志を使わないきっかけ(トリガー)」と捉え直せるからです。この話は、いわゆる「自動化」という概念とも関連してくるのですが、「意志を使わずに何か行動を起こす」という視点を持つと、「自動化」されたもののアウトプットに対する意識を変えることも可能です。

    ※数字を見るだけの状態から、週一で数字の内訳の仮説を立てるためのタスクを自動起動する、などより密度の濃い仕事を促す事もできる。

    さて今回はここまで。次回、後編では発展系を紹介したいと思います。
    もうこの段階でタイマー起動を試してみたくなった方は、弊社の無料トライアルをお試しください。