Definition

bGraph is a term named by DDM (Diamond Digital Marketing) with the portmanteau of the prefix “b” and the word “Graph” . We apply the word “b” as the prefix due to the fact that the underlying system is built on top of Budibase (initial as “b”), which is a low code SaaS platform for building SaaS, which is a descendent of the AppSheet (i.e. another low-code SaaS Building platform) which we used before.

Meanwhile , the component “Graph” is referring to the data pattern of how humans read, learn , comprehend , interpret and behave. Infact, as long as we want to find (or connect) every single concept that we know, we can apply a Graph pattern, which is backed by the Graph Theory invented (or discovered) by Leonhard Euler in the 18th century.

What is bGraph

bGraph (built by DDM) is in fact a SaaS (Software as a Solution) which is acting as a Knowledge Management System in DDM, which is a perfect tool to turn Graph Theory into a system which facilitates the users to learn , comprehend and behave.

What problem the bGraph is solving in DDM

Diamond Digital Marketing is a multi international corporation which drives our business engine to be exposed under different parameters:

Multi Geo
Multi Language
Client from Multi Countries
Client from Multi Industries
Client from Multi Company Scale
Multi Product
Multi Job Title
Multi Job Capabilities
Fast Pace Technology innovation
Multi Staff
Multi Job Seniority (e.g. Rookie and Expert)

Living within this ever changing business engine, anyone can imagine this is a disaster for us to barely maintain a business, not to mention to scale up.

During the business process, there are 5 costs incurred in every single step or every single action of each team player within the whole organisation:

Production Cost

This is literally easy to understand. Product cost simply means the quantifiable and observable cost incurred during the production process.

For example, when we want to write a human-written Article for SEO purposes, the Production Cost is simply the production lead time which (associated with an hourly rate) is spent by the copywriter to do the research on the knowledge domain, as well as the time on actually writing the article. As long as we provide a job description to limit the number of words of output of that Article , The Production Cost is quantifiable , observable with no doubt.

Cost of Searching

However, not every cost can be observed or identified easily like Production Cost. Under the same metaphor, before the copywriter can actually do the writing, he/she may need to understand the knowledge domain in advance. In fact, the time spent on research-oriented tasks can vary from hours to days, depending on what granularity you want to deep down. While the revenue that we can earn from providing the service to clients is with a cap (i.e. ceiling , or maximum) , the Cost of Searching can be infinity that you can “research” for years before writing.

In a statistical way of thinking, while every time the revenue of the task “article writing” is limit with a maximum cap , the cost of the “article writing” is unlimited, which means after 1,000 times , eventually we will definitely have a lost (i.e. Cost > Revenue) with no doubt. (because revenue is limited and cost is unlimited)

How to quantify the “search” actions, refine the boundary of research, and name the granularity (i.e. the deep down level) of the research is definitely a changeling task, which is more an art than a science.

Cost of Error

I think all of you who worked for a while have experience that your superior or clients will modify or even totally reject the service / product that you deliver to them. While our product / services in most of the time is charged based on the measurable quantity of the deliverable (e.g. Number of Words written / Number of hours in Research), the Cost of “Error” part which is rejected or modified by the clients can never be absorbed by the price that we charged the client.

Imagine the case that when we promise to deliver an article with 1,000 english words to the client for USD$200, in fact we may write 5,000 words because we have modified 10 times due to the unsatisfactory feedback from the client. The 4,000 extra words (5,000 – 1,000) is the hidden Cost of Error that is hard to spot in a systematic way.

Again, whenever our business engine has any hidden cost that cannot be absorbed by the price we charged the client, we will definitely have a loss after 1,000 times we sold out that product / service.

Cost of Communication

Every time we receive an order from a client, we should have a job description input from the client to guide what we should deliver. For example

Number of Words
Language
Tone of manner
Delivery Time
Presentation Format
Scope of Knowledge Domain

Imagine how much time we need to spend on communicating with the client the job description , not to mention that we cannot guarantee our Salesperson (i.e. the Training Cost) to remember all the job descriptions (among 100+ of different Tasks) and ask the client in the right time, and assumed that the clients can understand the questions and provide a correct answer, which is unlikely the case.

Remember how often the job description has too much jargon that the clients do not understand and hence provide you a wrong job description input which the Salesperson passed to the production process, and in turn produce a wrong deliverable rejected by a client and finally we were requested to redo.

The Cost of Communication incurred, again is hardly observable and hence not measurable and not be absorbed by the price charged to the client.

Opportunity Cost

Opportunity Cost in an academic way means highest option value forgone. In a common sense way it means how much you sacrifice when you make a decision.

For example, assumed that your availability is only have 2 hours , if you spent 2 hours to accept an job copywriting job with an hourly rate of USD$20, you cannot spend the same “2 hours” to win a job with an hourly rate of USD$50, which means your Opportunity Cost of accepting the USD$20 offer will be USD$50 – 20 = USD$30.

Put it in short, if you use all your hands to grab a penny, you have no hand to grab a dollar.

Opportunity Cost is another typical cost that is hidden and hardly observed by the business owner. Although technically you do not suffer any additional loss , you at the same time also cannot earn more which you should have.

We can imagine that while there is only one way to make money (i.e. Selling Revenue) which is predefined and limited , there are 5 ways that we can lost money (i.e. Cost) which is hidden and unlimited.

You can now understand why most of the businessmen failed. And imagine how many hours you have to spend on training the teammate to avoid all these costs, assuming that the business owner already recognized all these costs, which is unlikely to be the case.

The objective of bGraph is to eliminate all these 5 types of cost as much as possible.

How bGraph Behaves

Before embodying the bGraph, allow me to introduce the bGraph Model which theories all the thinking and behaviour within DDM from the knowledge being acquired by us, to the services being sold out by us to the clients.

While in DDM there are 1,000+ SKUd (i.e. the types of services) that we can provide to our client, each SKUd will go through the same procedures before it is successfully delivered to the client. We called these procedure “Knowledge Monetization”

1. Problem Pattern

To provide a metaphor is the best way to illustrate the concept. Imagine when your client wants to run a business online, he may need to “Build a Website”. Infact he will not know anything about building a website, he has no idea on what is wordpress, woocommerce, not to mention what is domain name or web hosting. In this case, the Problem Pattern that can be recognized by the client himself is “Website Building”.

Therefore , probably he will search in Google “website building agency” or “how to build a website” as this is his perception entry.

On the contrary, he will NOT search in google “domain name registration” or “web hosting service” as he doesn’t even know what this is about. He can never search for something out of his perception.

We regard the “Problem Pattern” as the Trigger of the Knowledge Monetization process because this is how the story starts.

Perception Status

Problem patterns can be further classified to 6 status based on the Perception Status of the client regarding that particular Problem Pattern. The Perception Status highly affects the Sales Parameters when we (DDM) are communicating with the client.

01 – Spotlight – In this perception status , the client heard of the service or products type name , but in fact does not know exactly what he is going to buy, or what he needs. SEO Service is one of the examples of [01 – Spotlight] Service. Other than the pronunciation “SEO” , the client most of the time does not know what the service scope is covered, how much it is , how to justify the price , what is the fine-grained specification of the service, or even what will be the deliverable or the KPI. Infact , the client just heard of the service / product name somewhere and he realised that everywhere in the world is talking about this. For the sake of FOMO (Fear of Missing Out), he is going to seek out SEO.

Client Behaviour Aspect	Behaviour Description
Price Sensitivity	Extremely Price Oriented. The only parameter that he is going to do the comparison among vendors is price.
Problem Solving	Most likely he cannot solve his problem by simply buying the service because he didn’t clearly define the problem , as well as the specification of the service.
Order Size	Small amount of the product or trial period of the service is what he is seeking for. He will not spend a lot to buy something that he don’t understand
Searching Keyword	He is going to (and can only) search for the most generic and iconic Keyword. (For example , “SEO”). He will not search for any technical terms (e.g. DNS Caching) Do not expect him to search for any jargon (e.g. backlink) or service specification. The search term still will not deep down to operational and executable level.

02 – Learning by Reading – Some of the clients may step further to read through the internet / KOL after he went through [01 – Spotlight]. Under the metaphor of SEO service, the client, although most likely still not know how DNS caching may enhance the SEO performance, he may know that Keyword installation or Backlink Building is a common service scope of SEO.

03 – Learning by Doing – Having experienced the service from any vendor, the client starts to understand the logic behind the service. He may have encountered the Problem Pattern that he had never imagined before, and can comprehend what the vendor is talking about. To continue the example of the SEO service, the client may now realise that it is hard to do the Keyword Research to enumerate all the Keywords relevant to his business because he lacks access rights to an Active Google Ads account. Or he may realise that it is very time consuming to build backlink by himself due to the fact that he needs to create a dummy account for each business directory or guest blog one by one by himself.

Client Behaviour Aspect	Behaviour Description
Price Sensitivity	More prone to Quality Oriented instead of Price Oriented
Problem Solving	More willing to listen to the service scope that out of his cognition , which normally is the missing puzzle for solving the problem
Order Size	More willing to engage into longer service periods.
Searching Keyword	Search for the Problem Pattern during the operational procedure. (e.g. how to check if the black link is “nofollow”)

04 – Learn From Mistake – Having used the service for a while, the risk or error derived from the service that he did not purchase in [03 – Learning By Doing] (due to the fact that this service is out of his perception) starts floating up. Even worse, most of the time he cannot correlate the mistake he made , or the problem shown up, with what he service that he didn’t purchase before. Under the same metaphor of SEO service, the client may realise that the ranking of his website is not climbing up but instead dropping, although he did realise that the dropping of the website is due to a particular cause – backlink. What he only knows at this moment is that he is suffering from the mistake and needs to fix up as soon as possible.

Client Behaviour Aspect	Behaviour Description
Price Sensitivity	Quality Oriented and Responsive Oriented instead of Price Oriented. Less doing comparison among vendors.
Problem Solving	Dedicated to solve the problem by all means in order to resume his business to normal condition
Order Size	Does matter as long as the problem can be solved
Searching Keyword	Search for the Problem Pattern and the Solution of the Problem Pattern.

05 – Cannot Form Question to Ask for Help – This Perception Status is in fact the extension of 04 – [Learn From Mistake], which the main difference between Stage [04] and [05] is that the client even don’t know what is the reason that cause the problem he suffered in this moment. For example, the client who bought the SEO service from a SEO Agency found that in one day the ranking of his website dropped dramatically. He cannot even tell what step he or his SEO agency made to bring this result. The only phenomenon (Problem Pattern) that he can observe is that the ranking of his website dropped.

06 – You Don’t Know What You Don’t Know – In this Perception Status, the client doesn’t even address the problem. He may regard the Problem as Phenomenon (instead of Problem) because he does not think that he is suffering. Under the metaphor of SEO service, for example , while the homepage of his website is still shown up in the Google Search Engine Result, he may not realise that 90 out of 100 URLs in his website are not indexed by Google Search Engine because he never knew how many URLs his website actually had.

Client Behaviour Aspect	Behaviour Description
Price Sensitivity	Not Price Sensitive No Quality SensitiveIn fact he is sensitive to nothing because there is no demand
Problem Solving	As the client does not address the problem, he is not going to fix up anything
Order Size	No Order as he as no intention to buy anything
Searching Keyword	Will not search for anything.

2. Theoretical Model

While “Website Building” is the only Knowledge node understood by the client, to run the business and provide the service to the client, of course we (DDM) need to master all the academic theory, knowledge and skill set behind .

For example , to know how to build a Website, we should master:

HTML
MVC (Model-View-Control)
OSI (Computer Network Communication Model)
Colouring System
…

While you cannot directly ask for your client to pay for you after you tell him what is a <H1> in HTML tag , which instead your client will only tell you that he want to BOLD the Title of an article, (which in fact is executed via giving a <H1> tag to the Title) it is a prerequisite for you to know what is a <H1> HTML tag before you can build a website.

Therefore, in there HTML is a Theoretical Model (i.e. the knowledge) that we should address in our bGraph.

Features

Theoretical Model can be further fine-grained to Features. For example, when your client is under the harassment of spam registration, he may only come to you with a Problem Pattern that he wants to block the spam registration (which is the Problem Pattern in this case) . Most of the time , he may not tell you that he wants to install a Firewall to block these spam registration, which in this case Firewall is the Feature (i.e. the Solution) that he wants to tackle the Problem Pattern.

3. SKUd

SKUd is a portmanteau used within DDM which consists of the acronym “SKU” which stands for Stock Keeping Unit, and the suffix “d” which stands for DDM (initial as “d”). The SKUd is named in order to differentiate it from the SKU of Client which we denoted SKUc.

In reality , especially in a product based (in contrast to service based) business, the concept of SKU is easy to understand. While you visit a supermarket and buy a canned Coca Cola 350ml , this product “Set” is called a SKU with a SKU number because all those specific 100 cans of Coca Cola 350ml all have the same price, which therefore are classified under one SKU Number.

While you are purchasing a can of Coca Cola 350ml with the price of USD$1 and checkout, the cashier will pack you exactly that ONE particular can of Coca Cola 350ml, no more and no less. Definite, crystal clear.

On the contrary, when you visit a hair-styling store and you request the stylist to deliver you a “beautiful” haircut , the term “beautiful” is in fact hard to define , measurable and quantifiable .

Not only because the term “beautiful” is subjective , the service time of the haircut cannot be always quantifiable. You never see that the charge of a hair-style is based on the number of hair or the length of the hair that the client possesses.

The ambiguous definition of the deliverable “beautiful haircut” can definitely derive lots of communication cost including the argument on the “beauty” of the deliverable, the service time , the attitude of how the hair-stylist service you , so on and so forth.

Imagine if you are going to build a website for the client, following specification will significantly affect the price you charge to your client:

No. of pages to create
No. of language
Speed of the Web Server
Capacity of the Web Server Storage
No. of Functionality of the Website
No. of customised programming code.
Cost Domain Name
…

If we simply classify the “Website Building” to a single SKU, it definitely is not enough to cater all different needs from different clients in different scenarios.

How to design a quotation system which can quickly and accurately generate a quotation which covers all the requirements from the client, while at the same time having a short learning curve, is a world class challenge, not to mention most of the time the client doesn’t even know what he actually needs. (e.g. Do you think the client will proactively require you to install a DNS Caching system in order to speed up his website?)

Besides, Service will always derive hidden cost of communication and cost of error. How to define a quantifiable and deliverable service is crucial for success.

The term “Service as a SKU” is the business model applied by Amazon Web Service (AWS), one of the biggest IT companies in the world, to eliminate the hidden costs derived by Service, by modularizing and quantifying all the services as much as possible via API.

In DDM, we will apply the same “Service as a SKU” model (as much as we can) . We can simply name all these SKUs a “Solution” in our Knowledge Monetization process.

4. Interface

After we have sold a particular Solution (continue to use the “Website Building” as the metaphor) to the client, we should consider how the Solution interfaces with both the Client , our Teammate , as well as other Computer Systems.

Before we illustrate the concept with an real life example, allow me to enumerate and elaborate the Interface that we are going to cater:

GUI – Graphical User Interface , which usually is easily and intuitively controlled by the end user (e.g. drag and drop). Most of the users will use the software via the GUI and didn’t even notice that they are using the GUI. The button you clicked to submit, or the drop down list you used to choose an option inside a software, are all examples of a GUI.

Source Code Interface – While most of the time the user can use the software by GUI , there is a scenario that the software allows the user (or the developer) to customise the software based on his specific need. Due to the fact that there are an infinite number of scenarios which can be requested by the user, it is impossible to in advance create all the GUI components to cater anyone for everything. And that’s the reason why the software will always provide a console which allows users to write their own programming code to alter the function of the software to fit their needs. We called this interface as “Source Code” interface

CLI – Command Line Interface , which 99% of the time will not be touched by the end user. It should only be touched by the developer to place an order directly to the software without interacting with the GUI. CLI facilitates the developer to place an order in bulk hence the developer can automate the process. While the interface requires the developer to write Computer Command Line (e.g. type in copy C:/windows/abc.jpg to copy the file in the Windows Command Line Prompt), that’s the reason why it’s named Command Line Interface.

API – Application Program Interface, While all 3 above are talking about how the human (user / developer) is interacting with the software, the API is covering how to interact with one software (or system) to another software (or system). The “consumer” of the Interface is in fact the “Application Program” (i.e. the software), and that’s the reason why it named “Application Program Interface”

To continue our Website Building metaphor , Imagine the client requested us to add a Captcha function in order to avoid the spam new user registration, you can think of the interface matrix as below:

Interface	Parties involved	Action
Website Frontend GUI	Website Visitor	Tick the Recaptcha Checkbox
Website Backend GUI	Website Designer	To change the Colour of the border of Checkbox of the Recaptcha To change the font size of the Checkbox of the Recaptcha
Source Code Interface	Developer	Write a if-then-else scenario to control only non-logged in user should fill in the Recaptcha Box, while logged in user can skip this process
CLI	Developer	Write a scheduled program to periodically upgrade the version of the Recaptcha Plugin from the Vendor’s server.
API	Recaptcha Vendor (e.g. Google Recaptcha)	Charge the developer based on number of usage of the Recaptcha

While the client is referring to this “reCaptcha” function as “i’m not a robot box” , the Website Designer will tell the programmer this is a “Checkbox” with CSS ID = “google_recaptcha” . Meanwhile, the developer will name as an “Object” the recaptcha vendor will regard it as a “Recaptcha API Endpoint”

How to communicate among Client / Salesperson / Website Designer / Developer / Vendor will be a big challenge.

Do you think the client will call the Salesperson and tell him that :

“Hey guys, i want to write a if-then-else logic to block the spam registration from spam bot , i will call the API end-point 1000 times per month and to align the brand tone colour of my website , so please set the checkbox border-colour = rgb(242,129,123,0)”

There is a huge demand for a lookup table to translate all the different jargons which are referring to the same thing among different people.

That’s one of the duties of the bGraph.

How to communicate among Client / Salesperson / Website Designer / Developer / Vendor will be a big challenge.

Do you think the client will call the Salesperson and tell him that :

There is a huge demand for a lookup table to translate all the different jargons which are referring to the same thing among different people.
That’s one of the duties of the bGraph

Put everything of bGraph Together

To bring what knowledge we (DDM) acquired and turn it into a deliverable which can be sold to our client, this is what we called Knowledge Monetization Process.

Below are the Knowledge Monetization Process examples we showcase some of the option values of each step inside the Process.

(Step 1) Problem Pattern	(Step 2) Thertocial Model	(Step 3) SKUd	(Step 4) Interface
Avoid Spam CommentMembership System1st Purchase CouponSend Company Email	OSI HTTP Javascript SMTP DNS	Recaptcha Installation Membership System Installation SMTP Setup Coupon Code Setup Website UI Design Usage Training	Frontend GUI Backend GUI Source Code Interface CLI API

In real life all the Steps 1 to 3 in the Knowledge Monetization Process involve 1,000+ option values that we can choose for.

if we want to successfully sell the SKUd to the client based on the problem pattern he had raised out, we should choose 1 appropriate combination among all the combinations , which is

[Options Value Steps 1] x [Options Value Steps 2] x [Options Value Steps 3] x [Options Value Steps 4] x

4 x 5 x 6 x 5 = 600 combinations

We called these 600 combinations the (i.e. the result of that multiplication operation) Cartesian Product. These 600 combinations bring us a big question, how can we train up our Salesperson / Website Designer / Developer / Client to pick ONE appropriate combination among 600 so that the client can solve his problem? (don’t forget in real life all Step 1 to Step 3 have 1,000+ option values for each step, which in turn bring almost infinity numbers of combinations)

For example, below is 15 of the combinations out of 600 which should deliver to the clients in order to solve his problem (i.e. Avoid Spam Comment)

(Step 1)Problem Pattern	(Step 2)Thertocial Model	(Step 3)SKUd	(Step 4)Interface
Avoid Spam Comment	Javascript	Website UI Design Recaptcha InstallationUsage Training	Frontend GUI (Recaptcha Checkbox) Backend GUI (Colour of the Checkbox) Source Code Interface (if-then-else code to require only non-logged in user to tick the Recaptcha) CLI (auto update the version of the Plugin) API (Calculate the usage of the Recaptcha and hence charged by the vendor)

How can our Salesperson know that he should pick up 3 SKUd (out of 6 in this example) to achieve the goal?

How can our Developer know that he should tackle 5 interfaces to deliver the setting?

How can our human resource manager know what knowledge the developer should know if he wants to recruit a developer to do the programming on the Recapthca installation process? (in this example, the developer needs to know how to write Javascript)

This is a typical cartesian product data pattern that we will always face when we are acting as a business consultant. To cater this cartesian product data pattern is simply by building a database to map all the option values in different steps.

This is how a business consultant should act (assist anyone to choose , i.e. make a decision) , and then bGraph is (and going to be) a powerful system (i.e. the database with interface which can be used by users) which is acting as an automated consultant.

In conclusion, bGraph is the foundation stone of our business , or even the definition of DDM.

In bGraph it is :

Acting as a library , containing all the option values for each steps in Knowledge Monetization process

Acting as a Graph Theory, which records every single relationship (we called it “edge”) among each “node” which are related to each other.

With the automated business rules written inside the bGraph, acting as an automated business consultant to suggest the appropriate option value to the user in right time and right place.

Thousands of hours can be saved in terms of all 5 costs mentioned above, and therefore we can scale up our business globally without any hiccup.

About bGraph