Operation: Reception of "Information request"

  1. Number of received information requests
  2. Number of submitted estimates
  3. Number of concluded contracts

Although it is a classic marketing method, "1) Number of received information requests" is an index that directly linked to "3) Number of concluded contracts". The correlation is extremely strong. Therefore, many companies set it up as KPI. Car dealer, insurance company, moving company, design office, and so on. It does not matter whether the scale is big or small or which type of business it is.

In the meantime, in order to realize a smooth Workflow, there are some companies that accept requests from customers at the "Form Start Event" of cloud based Workflow. By using a Workflow, downstream Steps such as "Address printing" and "Shipping" are also executed without mistake.

And the automatic transmission of the "Acceptance email" (placing an email transmission event) would be also "royal road". The customer can recognize that "the request was accepted". In addition, "Acceptance number" should be described in the text body. Doing so, the customer can make inquiry for questions through the phone or chat by tracking the "Acceptance number".


Challenge: Identity confirmation with Acceptance number only

"Process serial number" (# {processInstanceSequenceNumber}) is convenient for "Acceptance number". After all, KPI management is easy with it.

But at the same time, it is also a "number easy to infer". For example, when "cancellation of application" came by telephone or chat, it may be a situation inevitable to confirm "identity verification". In other words, if you are asked to cancel acceptance number 123 in a sincere voice, you may accept it as it is. But when you face a person who is likely to be malicious, you will confirm the identity by asking "email address". This could be called customer discrimination.

However, if it is a long number like a cipher text to be a "hard to infer number", it will be inconvenient. Not only "KPI management" becomes troublesome, but also it is hard to verbally tell on the phone, and it is rather difficult to guarantee that it is unique. Hmm...

[Information Request Correspondence]

Operation: A Large Amount of the End of the Month Billing

The monthly billing business at the end of the month has become to be conducted without missing!

With regard to "charged amount" to each customer, it became possible to catch in real time that who has input or who approved and when. Moreover, thanks to the "Automatic Step" which accesses the credit company API (Stripe API), charging to credit cards are directly performed from the Workflow system. In other words, it eliminates "dual entry" into the accounting system.

Challenge: Reduce Dependence on Human

However, this Business Process is still depending on "data input by human". That is, a human (sales representative) is in charge of input of "billing amount" that is crucial.

Certainly, "customer information" is set automatically, and "card billing code" (Stripe CustomerID) is also preset. Furthermore, "list of billing work" also appears on the list of Offered without missing, so it is easy to do the billing work by multiple people cooperating. So, I think that "labor saving of inputting" has been realized at a fairly high level, but...

However, the information on "charge amount" (billing amount) is in the "Sales management system" which is an "external system" from the viewpoint of the Workflow system. I wonder if there is a measure to automatically acquire sales summary somehow? (Today, "API economy" is urged out, and I think that where Business Process Improvement is heading to is "unmanned"...)

[Credit Card Charging - Recursive call-Full automation]


Operation: Monthly Credit Card Charging

Great labor-saving has done on the billing operation at the end of the month!

In the new Workflow application, "credit card charging" is automatically carried out as the department manager approves "Billing amount of this month" registered by the sales representative. There is no necessary for the Accounting side to do work such as "printing / signing / mailing of invoices". Of course, you don't need the work of "bank payment confirmation", either. Stripe, bravo! API economy, bravo! Questetra, bravo!
Incidentally, it gains favorable reputation also among customers.

They say it is good with that the expense details can be confirmed in "notification email", not to mention that the actual work such as "approval on invoice" and "procedure of bank transfer" has gone away. (Paperless)

(I wish "bank APIs" to be opened soon, as well...)

Challenge: Who is not charged?

However, it is hard to confirm "if I charged all the customers or not" at present condition.

Certainly, it is simply to Start (reuse start) the Workflow manually from "1r". However, relying on "manual" for its start, it would be hard to realize, for example, "to charge all the customers who billed in the previous month without oversight".

When the number of billing increases, "billing mistake" may incur, one day...

[Credit Card Charging - Recursive call]

Operation: Charging to Registered Card

I did create a mechanism of "Credit card registration"! (See previous post)

The mechanism is, credit card information such as "card number" and "CVC" is committed to Stripe (Payment Service Provider), and only "Stripe Token" (tok_ {24 characters}) as "deposit number", flows to Workflow. That means, it complies with what Japanese government is advocating that "Achievement of non-possession of credit card info by March 2018". (Non-possessing = The primal measure for protecting credit card information)

This will bring down "the risk of credit card info breaching from in-house system" to zero! Customers can make web registration without worry!!

* Stripe Token is a specification that can only be used for one processing (single-use token). In this example automatic conversion from "Stripe Token" to "Stripe CustomerID" (cus_ {14 characters}) is also done simultaneously. (Auto-step "Token to Cus_ID")

Challenge: Eliminate Manual-work in Charging Operation

But wait and look. What I did is just realized only "protection of credit card info".

Mistakes in "Total amount", for example, or in "Charge"... Risks of occurring such error in "charging operations" is not yet zero. Suppose if you had sent a charging statement to "email address of Mr. Brown" with "addressee name of Mr. White"...doesn't it make you shill?
  • Customer's name
  • Customer's email address
  • Token or Customer ID
Data like as above should be automatically entered beforehand. By making so, error rate will be close to zero. The burden on "unreliable boss" who is in charge of checking at the downstream Step will be alleviated a little.

[Credit Card Charging]

Operation: Acceptance of credit card registration

Want to promote credit card charging...

If I could charge to "credit cards" according to the service usage record automatically, very smooth settlement would be possible. If I could digitize "bill issuance", I would drastically reduce cost on payment collection.

I would like to prepare a "card payment system" like an electric company, gas company, or mobile phone company.

Challenge: Risk of credit card information data breach

However, as security requirements become more stringent, "holding a credit card number" seems to be a big risk.

Our company is not a power company nor, a big company such as Google or Facebook. In other words, it seems that we unlikely could comply the requirement that "PCI DSS" says. "What important is," the credit companies (Acquirer) say, "not to possess cardholder's info".

Alright, I'm going to leave cardholder's info such as PAN, PIN, CVC, to "Payment agencies", as it is advocated in a document by the Japanese government that "we aim for non-retention by March 2018". (But how?)
  • PAN:Primary Account Number (card number)
  • PIN:Personal Identification Number
  • CVC: Card Verification Code/Value (3 digit number. Formally CVC2, aka CID)
* Reference: PCI DSS (PAYMENT CARD INDUSTRY
DATA SECURITY STANDARD) Ver.3.2 2016-04
* Reference: Payment services (PSD 2) - Directive (EU) 2015/2366

[Credit Card Info Reception]

Operation: Vulnerability Response Process

They say, "There is no software without a weak point."

In other words, computers and communication devices with countless software built in are "full of dangerous weak points". There are also business systems that manage sales and salaries...

"Vulnerability Response" by IT department is, in simple words, "repair work of software".

Specifically, the IT department collects vulnerability information from "IT information site" or "Google Alert email" on a daily basis. If information relates with the software used by the company's computer, they conduct "patch application" or "version upgrade", etc. Although there are many software perform "automatic patch" and "automatic update" by themselves recently, there are still not a few "incidents that must be handled manually".

Incidentally, once or twice a year, a security test ("vulnerability assessment") by a specialized contractor should be carried out to check whether the repair work is done properly.

Challenge: Response depends on individual

However, a tremendous number of "attack methods" are found everyday.

"Methods of attack" on old software are also reported almost every day. Even though "weak points" should have been overcome by daily repair, it seems that attackers are also improving their ideas and power, day by day. It seems to continue forever. "Vulnerabilities" announced by CVE, for example, are count to more than 10,000 annually.
(CVE:Common Vulnerabilities and Exposures)

It is no longer the amount that IT department can check through. The reality is, that experienced employees are responding using their "individual information network" and "smell?"

Hmm, wouldn't be there any way to deal it more systematically?

To put it more, I would like to record and share precisely about who decided what kind of judgment on urgent vulnerability. For example, I would like to look back on when and how the correspondence was made against sensational vulnerabilities such as "ShellShock" or "Heartbleed". (OpenSSL, GNU bash)

[Vulnerability Response Process]


Operation:Soliciting Improvements from in-house

It seems that the Japanese government seriously wants to make "work style reform".

Certainly, there are "creating documents that no one sees" or "inefficient exchanging" also inside our company. I would like to think about a method more actively to absorb concrete "improvement idea", such as "introduce cloud service for certain work" or "utilizing IoT". For example, "mid-career employees" and "temporary workers" are grumbling while they are drinking... It is really wasteful if it just ?ended up in vain.

However, even if the president cried out that "Improve the business process and increase productivity!" at the morning meeting, specific "improvement proposal" will not come up.

Oh, yeah. First of all, let's ask "Internal Audit Office" to accept "idea submission" like the image of the so-called "suggestion box".

And let them operate a Workflow such as let it advance to 'on-site hearing step' and 'president reporting step' about good ideas. And let them operate a Workflow which make it advance to 'on-site hearing step' and 'president reporting step' about good ideas. (Business Improvement Idea Reception Process)

Challenge: Form that anyone in the company can post to

However, all the workers do not have "login ID" to the Workflow platform.

If "login ID" was required for idea posting, temporary workers and part-timers are not able to post. (I suppose the inefficiency of the work-floor could be surely being pressed on to part-timers and temporary staffs...)

Thinking carefully, it needs to secure some degree of "anonymity", as well.

I would like to endorse bold idea such as, for example, "Improvement idea to lower manager's fraud risk".

Hmm, it seems that soliciting questionnaires on "a completely opened webform on the Internet" is one of the way, but it makes me feeling nervous somehow. (The URL might be exposed, or people who have nothing to do with might make suggestion...)

[Business Improvement Idea Reception Process]