Workflow Sample: May 2013

"Case Studies" or "Customer Story" articles on the Website is important. Especially for IT companies, "Sales" might depend on the quality of these contents.

In fact, companies like Microsoft, IBM, SAP,,,
,,, Oracle, Google, Salesforce,,, so on
almost all the IT vendors with their own products, are listing 'Customer Case Study' on their Website. As a matter of course, Questetra as well. => Customers

The following Workflow is for writing a "Case Study Article". In some cases, the duty would take more than a month to be completed. Visualizing the "progress" clearly, aggregating the "performance" occasionally, and keep on improving for the business process 'To-Be'.

[Case-study Publishing flow]

On 26 May 2013 this week, the Revision of the Public Officers Elections Act will be enforced.
Finally, 'Election campaign' on the internet will be available in Japan. (Too late...)

That means, candidates (political parties) will be updating Facebook everyday during the campaign. Emailing as well. They can fairly appeal 'Please vote for me!' (It seems stupid now that telephoning over and over before.)

What you should be cautious is that even ordinary people are also 'campaigning'.
For example, anyone can originate messages such as 'Hooray for Candidate TANAKA!' or 'Support for candidate SUZUKI!' Or just carelessly be outgoing 'Candidate YAMADA, such guy shouldn't Win.'
However the regulations enforced this time, requires indication of 'information about contact' to whom campaigning and negative campaigning on their blog or Social network Services. It will not be a problem if posting to Facebook or Twitter, but need to be careful when letting the messages outgoing from blog or home page.

(Little bit digressing though,) "Election campaign" with email is still expressly prohibited in Japan. General public is not allowed 'election campaign' with email including Forwarding.

Well...
There seems to be happening new duties in service providing companies for blog and BBS.

A. Requesting deletion of libel and defamation against the author.
B. Notifying violation of duty of indication of contact information.

It seems like to become human tasks of considerable scale to me...
The person who would claim the "Delete of libel", would be the candidate him/herself. First of all, 'personal Identification' must be carry out. And if it is popular sites, there might be that notification of the breach of display duty will be a huge number. For Internet-related companies, maintenance of related business process (workflow development) is urgently needed.

[Public Article Modification Request flow]

Accepting the participation application on "Web Forms", sending an "Invoice" automatically.

Anyone would think such "labor saving using IT", nowadays.
A Web site which is totally automated by connecting a 'Web form' and a 'Payment system' can be created easily, If limited to a particular method of payment to "PayPal" or "Google Wallet".

However in fact, for an event of about 50 or 100 people, you would like to correspond on the phone and by e-mail. Why?
In short, it is because there will be various demands (exceptions) such as "invoicing for corporation name" or "Cash payment of day of the event". If humans response, they could handle anything flexibly. (Though mistakes would occur, of course ...)

The Business process below is a Workflow that humans make the payment confirmation operations.
Taking over the participation application data received in the Google Spreadsheet, humans do the subsequent processing. Specifically speaking, humans confirm the settlement completion by "Invoicing + Bank Transfer" or "PayPal Credit Card" or "Handing Cash on the Day".

Excellent point of it is that an "Invoice PDF" will be sent automatically when the participation applicant designate "invoicing + bank transfer".

[Invoicing flow]

In most of SFA (Sales force Automation), "Deal data" is registered.

The status of each deal is visualized, and the "Future Orders" can be foreseen in good accuracy. Specifically, the negotiating price and orders accuracy such as '20%/ 80%/ 100%', will be registered. The definition of "Deal" to be registered is various depending on Companies.

'This gonna be a 'deal' soon, but...'

However, this "determination of to be registered or not" is quite tricky. Some Sales people aggressively register deals in "the level of yet just talking", and others register when the deal 'the orders comes in sight'.

The Boss would say, "All of them! Register all of them!"

The following Business Process is a little bit different in approach to activity records.
Here, instead of "the point of view of deals", it records the sales history in "the point of view of the talks (contacts)". Don't need special 'determination', just register day-to day talking activities. Recording when finish talking (on the way back) on visiting or on the phone or meeting over the Internet. I might call it 'Daily Report of Sales'. It is also good to name this business process 'Visit Report flow', for companies which their sales are based on visiting.

[Talks Report flow for Visualizing Opportunity]

[Talks Report flow for Visualizing Opportunity: '1. Talk Registration' screen]

You will find if you have a closer look at the Business Flow Diagram, it is assumed that 'Sales Activities' will be managed in the following classification

Stage of not a clear deal opportunity.
Stage of a clear deal opportunity.

That is, when the deal opportunity becomes clear, it switches to a system that manages the status of the deal as well as most SFA. In this sample, it manages the activities before the submission of a quote as "in the point of view of Talks (contacts)", and after the initial quote has submitted, switches to 'deal management process'.

You will find in actual operation, that anyone can analysis the time which took from a lead to negotiation (the initial quote). Needless to say, this is extremely important data for each salesman and for the company.

[Download]