Community
Showing results for 
Search instead for 
Do you mean 
Reply

Long post on our Act! process tree. Could use optimization.

Tuned Listener
Posts: 49
Country: United States

Long post on our Act! process tree. Could use optimization.

We use Act! Premium 11.0 at my small/medium business.

 

I’m posting in order to see if you guys have found better/easier ways of doing what we are doing with Act!. And to see if we can spark some idea’s for us all to better utilize this software.

 

When we first acquired Act!, it was really just a “Learn as you go” approach. We’d use it, find we needed to do something new, and then just add a field or find the quickest way to do it. Over the last few years, we have constantly tweaked and messed with our act to make it like we want.

 

However I get the feeling that we are doing things all wrong, that there MUST be better/faster/easier ways to do what we do. Our process is quite cumbersome. There are dozens of complex processes to keep track of, so many that we have had to hire a fulltime employee just to maintain our act! Databases.(Db’s) We’ve added TONS of fields, manage (or try to manage) about 15 Database’s, CONSTANTLY export/import between Database’s, monitor about 250,000 records and often swap fields within each Database. And really we want to radically expand that number. Our team spends hours a day racking our brains on how to make these processes smoother and more reliable. And I’m sure many of you do the same.

 

To give you a better understanding of our situation, I will explain what we use our act! for and why we have so many Databases:

 

We are a sales team. We use Act to manage our contact’s, run call campaigns off of, to run email campaigns off of, and to keep track of sales. We don’t do any of these things too well. We also use it for data storage. The reason we have so many DB’s is because we found that Act! starts to slow drastically when the database has 20,000+ records in it. So we split up the records into different DB’s in order to keep it running smoothly.

 

So it starts with Data storage. We buy lists of information from companies and then import that information (usually from txt. or csv. files) into Act!. Since these lists are so large, we create a new DB for almost every list of info we get (thousands of records). That process requires going into the csv. file with excel and matching up columns with the proper field in Act! Then opening the Empty DB and importing the csv. file. That’s not hard.

After we get the info into Act! We have another company run call campaigns to that database, which requires us to export each DB to excel and then email it to the Call Center. The call center calls them, and any record the feel is a lead (a possible sale) they report back to us. Then we have our internal sales team follow up. Every morning we get a list of leads from the Call center. Here is where the madness begins.

 

So, as you can imagine, our internal sales team only cares about these “Hot” leads from the call center. And really, these are the only leads WE (in the office) want to monitor/manage. So we have a separate Db’s for all the hot leads. This is so the sales rep’s don’t have to constantly change Db’s and look up records in all 16 of our Db’s. We don’t want our sales guys combing through thousands of records in 16 Db’s to just call these leads.

 

So, what we do, is have a guy in the morning, go through every Db and look up the records that the call center is reporting back to us as a hot lead. We match the records by phone number, schedule a call for them, then export them to our Main Leads database. So when our sales guys log onto our main Db the calls activities alert them. Once in the Main Database We do mass replace/swap fields in order to add Dates and other info.

 

After each call, whether we make a sale or not, we schedule follow-ups, add in notes, and add in any more info we can to that record. Our main DB is now 15,000 large.

 

This is how we keep track of it all.

 

The problems with this process are:

  1. Its extremely time consuming to find/export/import these records into our Main DB.
  2. Its unreliable. We often find that Act! makes error’s while doing that much switching between DB’s.
  3. It also messes up records from time to time, while doing replace fields, and swap fields.
  4. Not enough automation. There are wayyyyy to many opportunities for human error. Which does occur, and when it does, it can ruin many potential leads.
  5. Not measurable. Its hard to measure which call campaigns to which DB’s are effective. Which DB is performing and which ones aren’t. Tracking the data through so many steps, with so many records, and over long periods of time because extremely difficult. Especially cause there is so much room for human error.
  6. Its hard to keep track of calls. How many calls made a day/ how many answer/ things of that nature.
  7. Not intuitive. Many fields we have, have random information in them. Or incomplete information.
 

Well that’s all I can think of right now. If you’ve read through this then you must be very interested. Like I mentioned, I think its because we don’t know how to utilize act! rather then problems with act! Itself.

 

Well, got idea’s? Anything to add? Or is our process as good as its going to get?

 

-Ian

Copper Super Contributor
Posts: 206
Country: USA

Re: Long post on our Act! process tree. Could use optimization.

Ok I will take a stab at this; First of all I want to commend you for your commitment to managing your sales data and your sales process, it’s refreshing.

 

At this point in your evolution a detailed review of each piece of your process and the tools you’re using to manage them is probably in order, you may benefit greatly by consulting with a process flow expert. Having said that there are some major red flags in your post:

Dozens of processes

Tons of custom fields

Random or incomplete information in fields

250,000 records and growing at the top of the pipeline

15 or more databases

Multiple import export points in the system, likewise with update and replace data functions. 

 

Start with your assumption that at 20K records ACT dogs out. Verify that your version of ACT, the equipment you are using, and your internal network are tuned for performance in a SQL environment. Managing and processing 50-100k records is very doable in ACT. 

As I was reading your post a total of two databases emerged in my thinking a front end for the top of the pipeline and a backend for the funnel itself, the hot leads. I would look for a way to redesign the process of obtaining new leads, distributing them to the call centers, and returning the “hot leads” for entry into the actual sales process. ACT is not the right tool for this quantity of data and the required shuffling of records between the processes. Focus your use of ACT on the actual “hot lead” sales process. 

 

Revisit each custom field in your data structure, where you see incomplete or invalid information work on your design to ensure correct data entry. Eliminate fields you don’t really need. This is an area where TRAINING is king. The mass edits and updates are of particular concern this bottleneck is probably caused by a disconnect between your front end and back end data structures. Also revisit ACT’S built in features for recording what happens with a specific record during the sales process.

Brad Marquardt
realtimeACT, Inc
Colorado, USA
Tuned Listener
Posts: 49
Country: United States

Re: Long post on our Act! process tree. Could use optimization.

There are, of course, many topics in your post I'd like to address. But I do have a few quick questions that will probably better help me clear up things.

 

First. The addition of fields in Act! has been a long process. After adding about 10 fields when we first got Act!, we slowing kept adding 4-5 fields every month for the last year/year and a half. We added to suit our needs. Nows we have about 30-40 custom fields added. First, is that a lot of custom fields for act!? I just assumed it was becuase it looks like its a lot! (kind of sloppily put in aswell, not very intuitive)

But my main question about the custom fields is, since we slowly added them in, does that slow/gunk up Act!? If we made a fresh Database and added all the fields we need at once, rather then slowly over years, would our Act! work more cleanly? Kind of like  defragging your Harddrive, helps quicken your computer?

 

Also, about the 20k mark in Act! I mentioned in my first post. I meant that as in, 20k seems to been that amount of records our Act! can handle before it starts to slow down. In our business its very important that we can pull up Contact Records quickly, add notes quickly, and switch to another Record. In many of our Db's we have around 80k records, and Act! handles it. But It handles it slowly. It doesnt run quickly enough to be suitable for our sales guys. When you mention that Act! can handle 50-100k records, what did you mean? Did you mean it can do it quickly and stabily? or just that it can handle it?

 

Also you posted "ACT is not the right tool for this quantity of data and the required shuffling of records between the processes. Focus your use of ACT on the actual “hot lead” sales process."

Are you suggesting having Act! for our Main DB, for the Hot Leads, then having another program (like Excel, or something similar) for the data that we are simply using to give the that call centers? Its funny, cuase i never thought of that before. The main reason we use Act! to store all this info, is becuase its the only software that I know of, that we can look up records by certain criteria (like name, phone number, etc) But it seems to dawn on me that I didnt really research to see what other programs can do that aswell. It doesnt seem unreasonable that many other programs, that are not CRM's, would have this capability. Am in on the right track with this sort of thinking? Is that what you meant? If so, any sugestions on software i look into?

 

I really appreciate your efforts realtimeact. And really, im probably going to end up hiring consulting anyway. but i want to see how much i can learn by myself, so when i do hire a consultant, i can use there time (and my money) wisely.

 

Thank you,

Ian

 

Copper Super Contributor
Posts: 206
Country: USA

Re: Long post on our Act! process tree. Could use optimization.

A rushed reply

 

30 to 40 custom fields doesn't present any real performance issues, it's really a matter of usability by your people. That's a lot to remember and complete properly (which they are not as you pointed out earlier). A common design flaw is to over document your records, its a sales tool .Think elegant, fluid, intuitive.

 

Make sure your systems are maximized for processing data in a SQL environment, then reassess your size threshold.

Several 80K record database's? Think data warehousing.

 

Yes for the massive front end cold calling effort you may want to have something designed that is very clean and fast preferably with a SQL back end, ideally it would allow the records to be tagged as hot and append all the information you want in ACT. You may be able to eliminate some or all of the replace/edits you are doing now, and a utility could be developed to automate some of the import process into your new "Hot Leads ACT database.. 

 

Fun project keep us posted.

 

Brad

Brad Marquardt
realtimeACT, Inc
Colorado, USA
Tuned Listener
Posts: 49
Country: United States

Re: Long post on our Act! process tree. Could use optimization.

hmm, ok. Im starting to get a clearer view of what direction i need to go with all of this. This conversation has really sparked my imagination.

 

First, keeping in mind the way we slowly added filed into our Act!, would there be any performance improvements to starting all over from a fresh new scratch Database and customizing it to what we need? Or could we simply "restore as" one of our current DB's and make new modifications to it (to make it more intuitive) Would there be any real difference?

 

Second, I had never really heard of Data warehousing before. So after serveral Google searches i find myself more confused then anything. Its a pretty dense area of expertise. From what I COULD gather from my research, Data wearhousing seems like something i could USE, but not something we NEED. It seems like data warehousing is a pretty expensive thing, and really I just dont have the funds right now to transfer a few grand over to buying new hardware. Not including the time it would take to train and successfully implement it.

 

Do you think there is anyway to manipulate Act! to do this task? Do you think there is anyway for a single Act! Database to handle 300-500 thousand records? (keep in mind these records wont have notes/history's/activity's/etc.... just company/phone/contact/address info.)

 

Do you know any website that can help me maximize my systems for processing data in a SQL environment?

 

Thank you!

Ian

 

Tuned Listener
Posts: 49
Country: United States

Re: Long post on our Act! process tree. Could use optimization.

oh, and also, i blanked out when i said we have 30-40 custom fields. i forgot a whole about a whole area of them. we probably have like 100-125. haha (i know big difference)

 

does that matter?

 

-Ian

Copper Super Contributor
Posts: 206
Country: USA

Re: Long post on our Act! Process tree. Could use optimization.

My concern with the 100+ (and growing) custom fields isn't so much about performance, although it is a consideration, it's really about usability that is a lot to keep track of. Evaluating the start over/not start over question has to be considered on both fronts. I can't answer the question without reviewing your Process in depth.

 

I mentioned data warehousing (sorry for the tech speak) with the idea that your main selling Process maintains between 10-15k records at any given time, I like ACT as the tool for managing this.

 

In addition you maintain several 80K+ record databases what I am suggesting is containerizing those data sets and putting them on a shelf readily available but not in the way. Maybe in ACT or maybe designing a mean and lean database just for storage.

 

You also have the front end dataset for cold calling which is quite large, Id like to see a more elegant Process for dealing with those records updating them and transferring them either to the hot leads system or back to the data warehouse.

 

Optimization for ACT (SQL) has a lot to do with raw processing power (read big beefy machines) two things you can do immediately is one identify the source of your processing, probably a server, and verify that it is up for the task. And two compress and reindex your databases regularity.

 

My suggestion at this point is to start mapping this out on paper, focus on your Process not the software. Identify each datasource and what information it needs to contain and approximate number of records at each point. Then you can go to your software toolbox and decide which tools to use for each piece of the Process.

 

B

Brad Marquardt
realtimeACT, Inc
Colorado, USA
Platinum Elite Contributor
Posts: 6,662
Country: USA

Re: Long post on our Act! process tree. Could use optimization.

Often, but not always, when I see a large number of added fields in a database, they are there to record data that would be better stored in a one-to-many table. The ACT! database now will accommodate adding custom one-to-many tables to the database through the SDK. At present an addon program is the best way to configure and use such a table.
Roy Laudenslager
ACT! Certified Consultant
ACT! Report Expert
Durkin Impact Report Designer
www.techbenders.com
royel@techbenders.com
541-343-8129
Copper Super Contributor
Posts: 206
Country: USA

Re: Long post on our Act! process tree. Could use optimization.

I suspect your right Roy, I wouldn't be suprised to find the actual number of fields required to be significantly less than what they have set up. We won't know til someone gets in there and looks at the database. B
Brad Marquardt
realtimeACT, Inc
Colorado, USA