Being the person who literally “wrote the book on ACT” (or at least five For Dummies books on ACT) I hear from many ACT users. Although most ACT users are “ACT FanACTics,” I do hear from a number of unhappy Act users. Here are a few “myths” I often hear, and some easy solutions to your act database issues.
- Myth 1: ACT Performance is slow. No, ACT is actually faster than previous versions although it may initially take longer to start. Try running a Lookup or replacing the information in multiple fields and you’ll see what I mean.
- Myth 2: I know everything there is to know about ACT. Hmm, I’ve written five books on the subject, and attend yearly conferences and quarterly webinars because I know that knowledge comes from more than just “using” software.
- Myth 3: I can just convert my old database and everything will work fine. If you never made changes to core fields, faithfully performed maintenance once a week, did routine clean-up work on your notes and histories and didn’t add a bunch of fields that you never used – then you’re probably OK. However, if you convert a database that is in need of repair you can expect to encounter problems.
- Myth 4: I can install ACT on the same machine I used for previous versions. Possibly, if that machine is not an old clunker. I recommend 1 gig of memory on work stations and 2 gigs on servers. In addition, variables like slow spinning hard drives (found on low end laptops) and low end processors can effect performance.
- Myth 5: ACT is buggy. ACT went through months of Beta testing. However, because there is so much variation in software and hardware configurations, you might find that a small part of a single feature might not work on your machine. Sage periodically delivers free updates to correct any known issues.
- Myth 6: My current version of ACT works just fine. If you’re a stand alone user and everything’s working well you don’t have to upgrade. However, you might benefit from some of the newer features. Or, if you upgrade your computer to Windows 10 or a newer version of Office, you version of ACT will not be compatible with those products.
- Myth 7: I can install ACT exactly like I installed prior ACT versions. Prior versions of ACT (Act v6 and older) were written in Fox Pro; newer versions of ACT use SQL. There is a great amount of difference in installation and maintenance procedures.
- Myth 8: New versions of Act are a lot more complicated to learn. Most users are pleasantly surprised to find that the basic Act functions work exactly like in prior versions. However, there are lots of new tricks which are well worth the time it might take you to learn them.
- Myth 9: I’m good with computers – I can figure ACT out on my own. If you’re a do-it-yourself-er and something goes wrong – please don’t blame the software!
- Myth 10: ACT’s Tech Support stinks; I hate to go off shore for help. Today’s software user wants two things: cheap software pricing and free white-gloved support. Sorry folks, that’s just not going to happen be it with Microsoft Office, QuickBooks or Act. However, as I mentioned in a recent blog article, there are actually many more sources of free support than there were 20 years ago!
For more information on ACT please visit my Website or shoot me an email.
I would like to create another database that handles an entirely new set of customers in an entirely different industry. My question is…….can I set this up by myself? If yes, can you refer me to documentation that provides direction on how to do this? If no, do I need to call into TechBender support and seek their assistance. I prefer to do it myself….so that I will know how to do it next time.
I would like to create another database that handles an entirely new set of customers in an entirely different industry. My question is…….can I set this up by myself? If yes, can you refer me to documentation that provides direction on how to do this? If no, do I need to call into TechBender support and seek their assistance. I prefer to do it myself….so that I will know how to do it next time.
Personally, I wouldn’t create a second database – that means you’ll have 2 sets of data to maintain, 2 calendars to access andpossible duplicate between systems. Why don’t you simply add a field to designate if the contact belongs to one company or another?