{"id":13,"date":"2015-02-27T10:23:02","date_gmt":"2015-02-27T10:23:02","guid":{"rendered":"http:\/\/a.fbschedul.in\/?p=13"},"modified":"2023-04-12T02:52:48","modified_gmt":"2023-04-12T02:52:48","slug":"evaluating-and-purchasing-major-software-systems","status":"publish","type":"post","link":"https:\/\/whatiscrm.net\/evaluating-and-purchasing-major-software-systems\/","title":{"rendered":"Evaluating and Purchasing Major Software Systems : guide"},"content":{"rendered":"<p class=\"intro\"><em>A major software package shouldn&#8217;t be chosen lightly. In this detailed guide, Peter Campbell walks through how to find software options, evaluate them, make a good decision, and then purchase the system in a way that protects you. <\/em><\/p>\n<p>\u00a0A smart shopper evaluates the item they want to purchase before putting money down. You wouldn\u2019t shop for shoes without checking the size and taking a stroll up and down the aisle in order to make sure they fit, would you? So what\u2019s the equivalent process of trying on a software package will size? How can you make sure your substantial software purchase won\u2019t leave you sore and blistered after the cash has been exchanged?<\/p>\n<p>That\u2019s the goal of this article\u2014to provide some guidance for properly evaluating major software investments. We\u2019ll walk through how to find potential software options, gather the detailed information you need to evaluate them, make a solid decision<\/p>\n<hr \/>\n<p>and purchase a package in a way that protects you if it doesn\u2019t do what you hoped it would for you.<\/p>\n<h2>\u00a0Is it A Major Software System?<\/h2>\n<p>The evaluation process described here is detailed, so it\u2019s probably not cost effective to apply it to every software tool and utility you purchase. How do you know if the package you\u2019re considering is major enough to qualify? Major systems have a dramatic impact on your ability to operate and achieve your mission\u2014they aren\u2019t measured by budget, they\u2019re measured by impact.<\/p>\n<p>To help identify a major purchase, ask yourself:<\/p>\n<ul>\n<li>Will the application be used by a significant percentage of your staff?<\/li>\n<li>Will multiple departments or organizational units be using it?<\/li>\n<li>Will this software integrate with other data systems?<\/li>\n<li>If this software becomes unstable or unusable once deployed, will it have significant impact on your nonprofit\u2019s ability to operate?<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p>Giving significant attention to these types of major purchases is likely to save your organization time in the long run.<\/p>\n<h2>Taking Preliminary Measurements<\/h2>\n<p>Prior to even looking at available software options, make sure you thoroughly define your needs and what the application you select should be able to do for you. Nonprofits are process-driven. They receive, acknowledge, deposit and track donations; they identify, serve and record transactions with clients; and they recruit, hire and manage employees. Technology facilitates the way your organization manages these processes. A successful software installation will make this work easier, more streamlined and more effective. But a new system that doesn\u2019t take your processes and needs into account will only make running your organization more difficult.<\/p>\n<p>So it\u2019s critical that, before you begin looking for that donor database or client-tracking system, you clearly understand the processes that need to be supported and the software features critical to support that work.<\/p>\n<p>This is an important and complex area that could easily be an article\u2014or a book\u2014in its own right. We could also write numerous articles that delve into project management, getting company buy-in and change management\u2014all critical factors in organizational readiness. However, for the purposes of this article, we\u2019re focusing on the process of evaluating and purchasing software once you\u2019ve already identified your needs and prepped the organization for the project.<\/p>\n<h2>Finding the Available Options<\/h2>\n<p>Once you know what you need and why you need it, the next step is to identify the pool of applications that might fit. An expert consultant can be a huge help.<\/p>\n<p>A consultant who knows the market and is familiar with how the systems are working for other nonprofits can save you research time, and can direct you to systems more likely to meet your true needs. While a consultant can be more expensive than going it alone, money spent up front on the selection and planning phases is almost always recouped through lower costs and greater efficiency down the road.<\/p>\n<p>If a consultant isn\u2019t warranted, take advantage of the resources available to the nonprofit community, such as Idealware, Social Source Commons, Techsoup\u2019s forums or NTEN\u2019s surveys. Ask your peers what they\u2019re using, how they like it and why. Ideally you want to identify no less than three, and probably no more than eight, suitable products to evaluate.<\/p>\n<h2>Considering an RFP<\/h2>\n<p>With your list of possible software candidates in hand, the next step is to find out more about how those packages meet your needs. This is traditionally done through a Request for Proposal (RFP), a document that describes your environment and asks for the information you need to know about the products you\u2019re evaluating.<\/p>\n<p>Well-written RFPs can be extremely valuable for understanding the objective aspects of large software purchases. For example, if you are looking for a Web site content management system (CMS), questions such as \u201cdoes the blogging feature support trackbacks?\u201d or \u201cCan the CMS display individualized content based on cookie or user authentication?\u201d are good ones for an RFP.<\/p>\n<p>What you want from the RFP is information you can track with checkboxes. For example, \u201cIt can\/can\u2019t do this,\u201d \u201cIt can\/can\u2019t export to these formats: XML, SQL, CSV, PDF,\u201d or \u201cThey can program in PHP and Ruby, but not Java or Cold Fusion.\u201d Questions that encourage vendors to answer unambiguously, with answers that can be compared in a simple matrix, will be useful for assessing and documenting the system capabilities.<\/p>\n<p>An RFP can\u2019t address all the concerns you&#8217;re likely to have. Subjective questions like \u201cHow user-friendly is your system?\u201d or \u201cPlease describe your support\u201d are unlikely to be answered meaningfully through an RFP process.<\/p>\n<p>Certainly, you can arrange for demonstrations, and use that opportunity to ask your questions without going through an RFP process. But while the formality of an RFP might seem unnecessary, there are some key reasons for getting your critical questions answered in writing:<\/p>\n<ul>\n<li>You can objectively assess the responses and only pursue the applications that aren\u2019t clearly ruled out, saving some time later in the process.<\/li>\n<li>A more casual phone or demo approach might result in different questions asked and answered by different vendors. An RFP process puts all of the applications and vendors on a level field for assessing.<\/li>\n<li>The RFP responses of the vendor you select are routinely attached to the signed contract. An all-too-common scenario is that the vendor answers all of your questions with \u201cyes, yes, yes,\u201d but the answers change once you start to implement the software. If you don\u2019t have the assurances that the software will do what you require in writing, you won\u2019t have solid legal footing to void a contract.<\/li>\n<\/ul>\n<h2>Structuring Your RFP<\/h2>\n<p>RFPs work well as a four section document. Below, we walk through each of those sections.<\/p>\n<h3>Introduction<\/h3>\n<p>The introduction provides a summary of your organization, mission and the purpose of the RFP<\/p>\n<h3>Background<\/h3>\n<p>The background section provides context the vendor will need to understand your situation. Consider including a description of your organization\u2014for instance, number of locations, number of staff and organizational structure, the processes the system should support, and such technology infrastructure as network operating system(s) and other core software packages. Include any upcoming projects that might be relevant.<\/p>\n<h3>Questionnaire<\/h3>\n<p>The questionnaire is the critical piece of the document\u2014you want to be sure you ask all of the questions that you need answered. In preparing these questions, it\u2019s best to envision what the vendor responses might look like. What will have to be in those responses for you to properly assess them? Consider asking about:<\/p>\n<ul>\n<li><strong>Functionality<\/strong>. In order to get answers you\u2019ll be able to compare, ask your questions at a granular level. Does a CRM support householding? Does a donor database have a method for storing soft credits? Can multiple users maintain and view records of donor interactions? Can alerts or notifications be programmed in response to particular events? Use the results of your business requirements work to focus in on the functions that are critical to you and your more unusual needs.<\/li>\n<li><strong>Technology specifics.<\/strong> Make sure the software will integrate properly with other applications, that the reporting is robust and customizable by end users, and that the platform is well-supported. Ask which formats data can be exported to and imported from, how many tables can be queried simultaneously and what type of support is available\u2014both from the vendor and third parties. Ask for a data dictionary, which a technical staffer or consultant can review, because a poorly designed database will complicate reporting and integration. And ask for a product roadmap. If the next version is going to be a complete rewrite of the application, you might want to rule out the current version for consideration.<\/li>\n<li><strong>Company information. <\/strong>Think through what you\u2019ll want to know about the company itself. How big is it? Do they have an office near you? How long have they been in business? Are they public or private? Can they provide some documentation of financial viability? Who are the staff members that would be assigned to your project? References from similar clients with similar-scope projects can also be very useful. For more information on this area, see Idealware\u2019s article Vendors as Allies: How to Evaluate Viability, Service, and Commitment.<\/li>\n<li><strong>Pricing and availability. <\/strong> What are their hourly rates, broken down by role, if applicable? What are their payment terms? What is their total estimate for the project as described? How do they handle changes in project scope that might arise during implementation? What are their incidental rates and policies (travel, meals)? Do they discount their services or software costs for 501(c)(3)s? How long do they estimate this project will take? When are they available to start?<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p>While it\u2019s important to be thorough, don\u2019t ask a lot of questions you don\u2019t plan to actually use to evaluate the systems. Asking questions \u201cjust in case\u201d increases the amount of information you\u2019ll need to sift through later, and increases the possibility that vendors might decide your RFP isn\u2019t worth the time to respond to.<\/p>\n<h3>Instructions<\/h3>\n<p>Close with a deadline and details about how to submit replies. For a sizeable RFP, allow a minimum of four to six weeks for a response. Remember that this isn\u2019t a confrontational process\u2014a good vendor will appreciate and want to work with a client that has thought things out this well, and the questionnaire is also an opportunity for them to understand the project up front and determine their suitability for it. Respect their schedules and give them ample time to provide a detailed response.<\/p>\n<p>Include an indication as to how additional questions will be handled. In general, if one vendor asks for clarification or details, your answers should be shared with all of the RFP participants. You want to keep things on a level playing field, and not give one vendor an advantage over the rest.<\/p>\n<p>You might do this via a group Q&amp;A, with all the vendors invited to participate in a meeting or conference call after the RFP has been sent to them but well before they are due to respond. With all vendors asking their questions in the same room, you keep them all equally informed. Alternatively, you can specify a deadline by which written questions must be submitted. All participants would then receive the questions and answers.<\/p>\n<h2>Evaluating the Answers<\/h2>\n<p>Once you receive RFP responses, you\u2019ll need to winnow down your list to determine which packages you\u2019d like to demo.<\/p>\n<p>If you asked straightforward, granular questions, you\u2019ll now reap the benefit: you can set up a comparative matrix. Create a table or spreadsheet with columns for each vendor and rows for each question, summarizing the responses as much as possible in order to have a readable chart.<\/p>\n<p>You might add columns that weight the responses, both on the suitability of the vendor&#8217;s response (e.g. 1, unacceptable; 2, fair; 3, excellent) and\/or on the importance of the question (for instance, some features are going to be much more important to you than others).<\/p>\n<p>Going through the features and technology sections, you\u2019ll see the strong and weak points of the applications. In determining which fit your needs, there will likely be some trade-offs\u2014perhaps one application has a stronger model for handling soft credits, but another has more flexible reporting. It\u2019s unlikely that any will jump out as the perfect application, but you\u2019ll be able to determine which are generally suitable, and which aren\u2019t.<\/p>\n<p>For example, if you\u2019re looking for software to manage your e-commerce activities, inventory management might be a critical function for you. If a submitted software package lacks that feature, then you\u2019ll need to eliminate it.\u00a0 As long as you understand your own critical needs, the RFP responses will identify unsuitable candidates.<\/p>\n<p>You might rule out a vendor or two based on what the RFP response tells you about their availability or company stability. Take care, though, in eliminating vendors based on their RFP pricing information. RFP responses can be very subjective. Before determining that a vendor is too pricy based on their project estimate, dig deeper\u2014other vendors might be underestimating the actual cost. If you feel you have a solid grasp on the project timeline, use the hourly rates as a more significant measurement.<\/p>\n<p>The RFP responses will tell you a lot about the vendors. You\u2019re asking questions that are important to your ability to operate. Their ability to read, comprehend and reasonably reply to those questions will offer a strong indication as to how important your business is to them, and whether they\u2019ll consider your needs as the software is implemented and into the future. If they respond (as many will) to your critical questions with incomplete answers, or with stacks of pre-printed literature\u2014saying, in effect, \u201cthe answers are in here\u201d&#8211;then they\u2019re telling you they won\u2019t take a lot of time to address your concerns.<\/p>\n<p>Keep in mind, though, that a weak sales representative might not mean a weak vendor, particularly if they&#8217;re representing a product that comes recommended or looks particularly suitable on all other fronts. It&#8217;s acceptable to reject the response and ask the vendor to resubmit if you really feel they have done you, and themselves, a disservice\u2014but temper this with the knowledge that they blew it the first time.<\/p>\n<h2>Trying It All On for Size<\/h2>\n<p>At this point the process will hopefully have narrowed the field of potential applications down to three-to-five options. The next step is to schedule software demos. A well-written RFP will offer important, factual and comprehensive details about the application that might otherwise be missed, either by too narrow a demo or by one the vendor orchestrates to highlight product strengths and gloss over weaknesses. But the demos serve many additional purposes:<\/p>\n<ul>\n<li><strong>Evaluating look and feel. <\/strong>As good as the specs might look, you\u2019ll know quickly in a demo if an application is really unusable. For instance, an application might technically have that great Zip code lookup feature you asked about in the RFP, but it may be implemented in a way that makes it a pain to use. Prior to the demo, try to present the vendors with a script of the functions you want to see. It can also be useful to provide them with sample data, if they are willing\u2014evaluating a program with data similar to your own data will be less distracting. Be careful not to provide them with actual data that might compromise your\u2014or your constituents&#8217;\u2014privacy and security. The goal is to provide a level and familiar experience that unifies the demos and puts you in the driver&#8217;s seat, not the vendor.<\/li>\n<li><strong>Cross training. <\/strong>The demo is another opportunity for the vendor to educate you regarding the operating assumptions of the software, and for you to provide them with more insight into your needs. A generic donor management system is likely to make very good assumptions about how you track individuals, offer powerful tools for segmentation and include good canned reports, because the donor-courting processes are very similar. But in less standardized areas\u2014or if you have more unusual needs\u2014the model used by the software application can differ dramatically from your internal process, making it difficult for your organization to use. Use the demo to learn how the software will address your own process and less conventional needs.<\/li>\n<li><strong>Internal training. <\/strong>Even more valuable is the opportunity to use the demos to show internal staff what they\u2019ll be able to do with the software. Demos are such a good opportunity to get staff thinking about the application of technology that you should pack the room with as many people as you can. Get a good mix of key decision-makers and application end-users\u2014the people who design and perform the business processes the software facilitates. The people who will actually use the software are the ones who can really tell if the package will work for them.<\/li>\n<\/ul>\n<h2>Making the Decision<\/h2>\n<p>With luck, your vendor selection process will now be complete, with one package clearly identified as the best option. If key constituents are torn between two options or unimpressed with the lot, senior decision-makers might have to make the call. Be careful, however, not to alienate a group of people whose commitment and enthusiasm for the project might be needed.<\/p>\n<p>If none of the applications you evaluated completely meets your needs, but one comes close, you might consider customizations or software modifications to address the missing areas. Note that any alterations of the basic software package will likely be costly, will not be covered in the packaged documentation and help files, and might break if and when you upgrade the software. Be very sure there isn\u2019t an alternate, built-in way to accomplish your goal. If f the modification is justified, make sure it\u2019s done in such a way that it won\u2019t be too difficult to support as the software is developed.<\/p>\n<p>Before making a final decision, you should always check vendor references, but take them with a healthy grain of salt. An organization\u2019s satisfaction with software depends not only on how well it meets their needs, but how familiar they are with their options\u2014there are a lot of people who are happy using difficult, labor-heavy, limited applications simply because they don\u2019t know there are better alternatives.<\/p>\n<p>If you still have a tie after RFPs, demos and reference checks, the best next step is to conduct on-site visits with an existing customer for each software package. As with demos, bring a representative group of management, technical staff and users. Assuming the reference can afford the time to speak with you, the visit will highlight how the software meets their needs, and will give you a good, real world look at its strengths and weaknesses. You\u2019ll also likely walk away with new ideas as to how you might use it.<\/p>\n<h2>Signing on the Dotted Line<\/h2>\n<p>You\u2019ve selected an application. Congratulations! You might be tired, but you aren\u2019t finished yet. You still need to work with the vendor to define the scope of the engagement, and an agreement that will cover you in case of problems. A good contract clearly articulates and codifies everything that has been discussed to date into a legally binding agreement. If, down the road, the vendor isn\u2019t living up to their promises, or the software can\u2019t do what you were told it would do, then this is your recourse for getting out of an expensive project.<\/p>\n<p>Contract negotiations can take time. It\u2019s far more dangerous to sign a bad contract in the interest of expediency, though, than it is to delay a project while you ensure that both parties\u2014you and the vendor\u2014completely understand each other\u2019s requirements. Don\u2019t start planning the project until the papers have been signed.<\/p>\n<p>A software contract should include a number of parts, including the actual agreement, the license, the scope of work and the RFP.<\/p>\n<h3>The Agreement<\/h3>\n<p>This is the legal document itself, with all of the mumbo jumbo about force majeure and indemnity. The key things to look for here are:<\/p>\n<ul>\n<li><strong>Equal terms and penalties.<\/strong> Are terms and penalties equally assessed? Vendors will write all sorts of terms into contracts that outline what you will do or pay if you don\u2019t live up to your end of the agreement. But they\u2019ll often leave out any equivalent controls on their behavior. You should find every \u201cif this happens, customer will do this\u201d clause and make sure the conditions are acceptable, and that there are complementary terms specified for the vendor\u2019s actions.<\/li>\n<li><strong>Reasonable cancellation penalties. <\/strong>If there are penalties defined for canceling a consulting or integration contract, these should not be exorbitant. It\u2019s reasonable for the vendor to impose a limited penalty to cover expenses incurred in anticipation of scheduled work, such as airfare purchased or materials procured. But unless this is a fixed cost agreement, which is highly unusual, don\u2019t let them impose penalties for work they don\u2019t have to do\u2014for example, for a large percentage of the estimated project cost.<\/li>\n<li><strong>Agreement under the laws of a sensible state<\/strong>. If the vendor is in California, and you\u2019re in California, then the agreement should be covered by California laws rather than some random other state. In particular, Virginia\u2019s laws highly favor software companies and vendors. In most cases, you want the jurisdiction to be where you live, or at least where the vendor\u2019s headquarters actually are.<\/li>\n<\/ul>\n<h3><\/h3>\n<h3>The Software License<\/h3>\n<p>The license specifies the allowed uses of the software you\u2019re purchasing. This, too, can contain some unacceptable conditions.<\/p>\n<ul>\n<li><strong>Use of your data<\/strong>. A software license should not restrict your rights to access or work with your data in any way you see fit. The license agreement will likely contain conditions under which the software warranty would be voided. It\u2019s perfectly acceptable for a commercial software vendor to bar re-engineering their product, but it\u2019s not acceptable for them to void the warranty if you are only modifying the data contained within the system. So conditions that bar the exporting, importing, archiving or mass updating of data should be challenged. If the system is hosted, the vendor should provide full access to your data, and the license should include language providing that client shall have reasonable access for using, copying and backing up all customer information in the database. There should be no language in the contract implying that the vendor owns your data, or that they can use it for any additional purposes.<\/li>\n<li><strong>Responsibility avoidance.<\/strong> Software warranties should not include blanket \u201csoftware provider is not responsible if nothing works\u201d statements. This shouldn\u2019t need to be said, but, sadly, there are often warranty sections in license agreements that say just that.<\/li>\n<li><strong>Back doors<\/strong>. The license should not allow for any post-sale reversals of licensing, such as language stating that the contract will be void if the customer uses the software in perfectly reasonable ways they don\u2019t anticipate. For instance, if you want to use the CRM functions of your donor database to track contacts that aren\u2019t potential donors, you shouldn\u2019t sign a contract limiting use of the software to \u201cfundraising purposes\u201d. Also, there should not be any \u201cback doors\u201d programmed into the application that the vendor can maintain for purposes of disabling the software.<\/li>\n<\/ul>\n<h3><\/h3>\n<h3>The Scope of Work<\/h3>\n<p>The Scope of Work (SOW) describes exactly what the project will consist of. It\u2019s an agreement between the vendor and the customer as to what will happen, when, and how long it will take. Good scopes include estimates of hours and costs by task and\/or stage of the project. The scope should be attached as a governing exhibit to the contract. Usually, this is negotiated prior to receiving the actual contract. By having it attached to the contract, the vendor is now legally obligated to, basically, do what they said they would do.<\/p>\n<h3>The RFP<\/h3>\n<p>Like the Scope of Work, the RFP should also be attached as a governing document that assures that the software does what the vendor claimed it would.<\/p>\n<h3>In Conclusion<\/h3>\n<p>For big ticket purchases, it&#8217;s well worth having an attorney review or assist in negotiations. Keep in mind that the goal is to end up with a contract that equally defends the rights of both parties. True success, of course, is a solid contract that is never revisited after signing. Litigation doesn&#8217;t serve anyone&#8217;s interest.<\/p>\n<h2>Bringing It Home<\/h2>\n<p>There\u2019s a lot of talk and plenty of examples of technology jumpstarting an organization\u2019s effectiveness. But if someone were to do the tally, there would probably be more stories of the reverse. All too often, organizations make decisions about their software based on uninformed recommendations or quick evaluations of the prospective solutions. Decisions are often based more on expediency than educated selection.<\/p>\n<p>Rushing a major investment can be a critical error. Learn about the available options, thoroughly assess their suitability to your needs and prepare your staff to make the most of them. Then, sign a contract that protects you if, after all else is done, the application and\/or vendor fails to live up to the promises. Finding the right application and setting it up to support, not inhibit, your workflow is a matter of finding something that really fits. You can\u2019t do that with your eyes closed.<\/p>\n<p>http:\/\/www.idealware.org\/articles\/purchasing_major_systems.php<\/p>\n","protected":false},"excerpt":{"rendered":"<p>A major software package shouldn&#8217;t be chosen lightly. In this detailed guide, Peter Campbell walks through how to find software options, evaluate them, make a good decision, and then purchase the system in a way that protects you. \u00a0A smart shopper evaluates the item they want to purchase before putting money down. You wouldn\u2019t shop [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_uag_custom_page_level_css":"","site-sidebar-layout":"default","site-content-layout":"default","ast-site-content-layout":"","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"default","adv-header-id-meta":"","stick-header-meta":"default","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[22],"tags":[],"class_list":["post-13","post","type-post","status-publish","format-standard","hentry","category-technology"],"acf":[],"uagb_featured_image_src":{"full":false,"thumbnail":false,"medium":false,"medium_large":false,"large":false,"1536x1536":false,"2048x2048":false},"uagb_author_info":{"display_name":"whatiscrm","author_link":"https:\/\/whatiscrm.net\/author\/whatiscrm\/"},"uagb_comment_info":0,"uagb_excerpt":"A major software package shouldn&#8217;t be chosen lightly. In this detailed guide, Peter Campbell walks through how to find software options, evaluate them, make a good decision, and then purchase the system in a way that protects you. \u00a0A smart shopper evaluates the item they want to purchase before putting money down. You wouldn\u2019t shop&hellip;","_links":{"self":[{"href":"https:\/\/whatiscrm.net\/wp-json\/wp\/v2\/posts\/13","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/whatiscrm.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/whatiscrm.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/whatiscrm.net\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/whatiscrm.net\/wp-json\/wp\/v2\/comments?post=13"}],"version-history":[{"count":2,"href":"https:\/\/whatiscrm.net\/wp-json\/wp\/v2\/posts\/13\/revisions"}],"predecessor-version":[{"id":3892,"href":"https:\/\/whatiscrm.net\/wp-json\/wp\/v2\/posts\/13\/revisions\/3892"}],"wp:attachment":[{"href":"https:\/\/whatiscrm.net\/wp-json\/wp\/v2\/media?parent=13"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/whatiscrm.net\/wp-json\/wp\/v2\/categories?post=13"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/whatiscrm.net\/wp-json\/wp\/v2\/tags?post=13"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}