Event Hub has learned the value of clear and transparent rules for engaging with related parties. This applies to;

This document attempts to provide a set of "rules of engagement" for resellers or agents of the Event Hub(EH) product for commercial return. This framework attempts to provide a fair and equitable set of guidelines so that expectations are transparent and concise.

"Critical Path: Key workflow steps that are expected to be fully redundant 24 x 7. Any failure on the critical path is expected to be resolved as a matter of urgency.

"SAAS": "Software as a service" is a way of building and selling software to many multi-user "tenants". No single customer owns the software. They use it for a monthly fee. No customer has the right to demand any feature in the product.

Event Hub (EH) is a SAAS product, our investors have invested in and expect commitment to the SAAS process.

Executional implications:

Our product has a vision that is executed by our Product Manager referring to our Road Map.

https://eventhub-roadmap.suggested.co/

Customers may offer ideas and we use this as INPUT to our strategic road map. We offer general by-quarter timings on our road map. We never provide or publish the date of individual feature delivery and only accept Priorities of need. Of course, certain ideas will get more attention and focus. You can help us drive our road map by voting on our feedback board.

"Elite team"

Event Hub agrees with and attempts to apply the following software build strategy:

https://blog.codinghorror.com/commandos-infantry-and-police/

Generally, this means we believe in smaller teams of higher skill and quality over larger teams of more average skill. Where resources are required from either side we expect higher-than-average skills applied. We believe, by implication, average skills will not enable "super-profits".

As part of EH growth, we plan and have engaged resellers and agents. We expect resellers/agents to provide market experience and customers in foreign markets. As of July 21, EH sees this as the primary value offered by Resellers.
​

Executional implications:
Where a reseller or agent is experienced in a foreign market, we expect the reseller to share its technical experience where relevant. This can be exposed by a technical review before a market release. For example, GDPR requirements or API's are needed due to a region's regulatory framework. We do NOT expect to re-invent the wheel for each market or have to duplicate resources. If we do need to do this we may as well set up our own offshore sales/support team. EH is very experienced in offshore 24 x 7 Support through our partner Indian and Pakistani teams.

If this expectation cannot be met - the reseller or agent should make this clear. EH will assess the value exchange of an agreement with this in mind.

'In Control": Proactive - versus RE-active

EH identifies and performs testing on the "critical path". We do this daily - sometimes hourly. If we see (critical) issues not caught by the current critical path, we expand the critical path. This provides baseline control and a systemised approach to continual coverage and "uptime".

Executional implications:

We expect any frontline teams to be trained in and adopt this process - immediately and at least 2 weeks before a market release. This forces:

Bugs (software defects) should be raised with as much information as possible - to replicate the bug. Most software companies use bug templates to ensure a close as possible replication of any issue. Loom videos are appropriate.

Where reconciliation is expected - real numbers or values in dispute should be supplied.

Executional implications:
Use Looms. Provide actual measure numbers where possible. Use approved reporting templates.

Any new product requests will adopt the EH product development program. This involves Jira and EH-approved Swim-lanes. New requests are expected to be added to the board as requests - only.

EH does not expect:

EH does expect:

Modern CI/CD delivery of software is very different from past methods and also very different "in the cloud". We deploy to production daily. We prefer to test with PRODUCTION DATA so that data issues are isolated from code or landscape issues.

If you wish to force us to adopt older methods for whatever reason, you should re-evaluate what SAAS means and reconsider re-selling our product.

Executional implications:

Understand and recognise how EH deploys its software. Forcing us to change adds complexity and cost. We expect this added cost to be reimbursed.

We will never re-brand our core product. It creates very little value and causes too much complexity. The product itself is white-level for all front-end interfaces by the use of "Brand type" - a feature..

Software needs to be kept simple wherever possible.

If you would like to rebrand our product internally - buy it outright :)

Where learning and knowledge transfer are needed to support the product, a structured approach is expected. EH expects knowledge to be shared once (or perhaps twice) with one internal SME who then disperses it into the new organisation. We should not have to answer the same questions over and over from different people from different company departments.

Both Scott and our CTO provide 20 hrs per week on their calendar primarily for knowledge sharing. These sessions can be recorded and then used over and over. We are happy to provide multiple sessions to the same people. People learn at different speeds. We do however expect learning growth through self-investment/training/practice. This can be measured via login times and transactions generated in our application.

https://scott-eventhub.youcanbook.me/

EH expects the learning processes to be "pulled when needed" not pushed by EH due to error.

​Executional implications:

Identify one resource to become a 'New product SME" in a structured and formal way i.e. make someone accountable.
Record or document the learning. Share it with others who need to know. Build an accessible repository, with cataloging, for others for dissemination.

There is often a need to transfer files in computing. File sharing is a good example and proxy for a company's "attention-to-detail" and quality norms. Files shared should be screened, should be free of error, and fit for purpose. We do not expect to be hand-balled 'dirty files' which we have to clean.
​
Of course, EH expects the same from our team. If you receive a poorly prepared file from our team - please "scream loudly".

Executional Implications:

Check files and screen them before passing them to EH. Do not expect our resources to clean and prepare them for you. If you are not sure what a clean file is, please ask for a template.

House Cleaning

If EH provides new stacks for Sandbox and QA, we expect the data in them to be maintained. If we see uncontrolled test data in these stacks, we will build our own silos and only support tests on the critical path in these silos.

A "clean your desk" policy is arguably more important in a digital environment.

Measurement

It is very easy to report facts such as:

Facts should be captured from day one of any GTM plan for immediate and ongoing review and comparison from agreed measures and best practices.

Executional implications:
Jira boards can be set to automatically export these stats. They can then be issued weekly as a "KPI-FLASH." EH is happy to resource this.

Disputes

If there are disagreements as to the process we expect that where the issue is product-related - and relates to the EH product - then EH should have the right to make the final call.
Vice versa for a reseller who owns a customer. If the issue is customer-related, the reseller should have the final call.

General Behaviours we believe make our software work

Scott Hyde Bec MBA COO

Dr. Alex Karolis. PHD CTO

Rob McQuade Co-Founder Fmr GM-Commercial SCG Trust.