Testing Protocol for Sales....

A good question, and a fine riddle entreprenuers are faced with when starting a company....is building out their SALES group.

Often times, it's done last, as a company figures out a business model, sets up the technology, aligns operations --- and then, poof - Sales should start rolling in.

WRONG.

Now more than ever, I'm officially of the belief that, "Sales Leads the Company."

What does this mean, and why?

It simply means, resources at most companies are scarce. There are not enough internal assets, to complete all projects in a timely manner.

It's a fact, that many companies are facing this problem.....it's called "Scalability."

Many projects, and initiatives, get placed in a que, and processed ACCORDING to operations, immediate needs (fixes) -- or, different and new ventures by key employees.

Testing Protocol for Sales.

(**this is based on when the company is in the critical stage of having multiple projects at once, but has a problem focusing on WHAT'S most important --- and, this is an ongoing problem at most GROWING, STABLE companies. The question is, how to deal with it?)
I've recently seen the model, and have watched it work well - that has the following business rules. (when dealing with operational efficiency, for dealing with Sales Needs, and Internal Processes)

***********************************************

1 - all internal operations issues - which require IT, or technical resources of any kind, are split into TWO camps. This data needs to be filled out BY SALES with EVERY request needed....it is to be clear, and measured.

Is the request --?
a) a fix to a existing program, or current project
b) non-fix - or NEW


2 -REVENUE potential.

a) precise amount associated with request. What is the the revenue model, and case you have built out for this project? (moreso, if it's B above)


Keeping a record of requests, and making sure the data they place in front of the company is realistic, and in fact -- honest. (making it part of a comp plan)


Sounds corney?

The early stages of this being put into place in a company has had stellar results after 90 days.

1 - moral is much higher in the IT group
2 - every employee has a clear understanding of the project they are working on
3 - job tickets are down 60% (requests)
4 - completion rate within a 5-6 days timeframe for all projects is UP 80%.
5 - Productivity in IT/Tech is up...employees are more "involved" and feel part of the team.
WHY?

Because SALES had some input on projects - IT dept. gets to feel a "part of" directly creating value. .

Sales never interfaces directly with IT, but SUPPLIES the information and data to operations. There is typically a point of contact between Sales and Tech...to filter.

But, it's NOT layer upon layer of operations.

As a company grows, and fills out their "organizational chart" -- the end result is usually a BALLOONING of the internal operations that lie between TECH/Sales groups. More employees between 2 VERY important groups.

It just happens that way.

It kills innovations....makes people feel like employees. Rather than "business owners" working in their department.

Communication, and GOOD DATA -- along with using it properly, allows companies to continue to grow..and scale.

Sales Teams want a project done yesterday.
Tech/IT teams are swamped by project after project.

Both need BETTER DATA, to add value.
A common theme amongst TECHNOLOGY employees in any company is "lack of corporate focus." -- and, "not feeling a part of the team."

Testing Protocol allows MORE EMPLOYEES to gain important insight, on the VALUE and importance of the jobs - and projects they work on.

Too often --- they feel as though they are just part of an assembly line.

Creating value is VERY HARD.

Making people feel they are part of the VALUE is another.

This is a beginning. It works well.......