The 360-degree view: Why an integrated CRM platform is important in growing a museum’s membership program

Diana Pan, The Museum of Modern Art, USA


In 2011, the Museum of Modern Art (MoMA) in New York implemented a cloud-based customer relationship management (CRM) solution, Salesforce, to help manage and track its vast member and donor population, past and present. Since its initial implementation, additional data from other Museum systems have been integrated into the CRM platform, such as a member’s retail purchase history, e-commerce online activity, and visitation history, thereby enabling the Museum to have a 360-degree view of every Museum member and donor. This view represents a holistic and multichannel perspective of a member’s lifetime online and on-site journey through all of the Museum’s offerings. This integrated CRM platform has enabled the Museum to provide more-informed customer service, retain and grow its member and donor population, increase engagement with its donors, and enhance its lobby operations through the use of mobile technologies. In the summer of 2014, the Museum launched a new mobile application utilizing the integrated CRM data, with a goal of optimizing the member and visitor experience in the Museum lobby. This application has transformed the operations in the Museum’s lobby and beyond, offering new possibilities for membership renewals and conversions. This paper and the subsequent presentation look at the technology and business challenges in implementing an integrated CRM platform. We will look at both the concepts and ideas that led to the Museum’s successes, and also those that did not produce the expected results. We will review upcoming plans for further changes to the CRM platform, such as tighter integration with the Museum’s website and simplifying the Museum's outreach for traveling exhibitions. Finally, we will describe how the Museum has moved a core operational system from a costly and cumbersome internal application to a scalable cloud-based solution, enabling more agile development and easier integration with current technologies.

Keywords: CRM, 360-degree view of the customer, membership, members, customer data integration

1. Introduction and background

Before the existence of Google and social networks; before smartphones, tablets, and PDAs; before the Pentium processor or the Apple Macintosh; perhaps around the time of the very first IBM PC, came the first version of the New York Museum of Modern Art’s (MoMA) own customer relationship management (CRM) application. Very early on in MoMA’s membership program, the Museum realized the value of managing its member and donor base in a systematic and centralized manner. MoMA’s first CRM application utilized IBM’s System 38 servers. In the early 1990s, it was migrated to the then state-of-the-art AS/400, with many custom programs. Over time, however, this system became bloated, with numerous features added on over the years and force-fitted onto an increasingly outdated platform. Users lacked proper training and found the “green screens” too difficult to use. Important data, such as research profiles of potential donors, could not be entered through the AS/400. Users began to apply workarounds through the use of spreadsheets. Information entered in the AS/400 was regularly exported and merged with data captured in spreadsheets. Spreadsheets were not connected with a centralized database, so information was not being shared, synchronized, and analyzed consistently. Critical data and processes were tied to spreadsheets, thus putting the business at great risk, as spreadsheets could crash and cause permanent data loss. It became extremely time consuming simply to identify the most current data set. Any integration of member and donor information back to other areas of the Museum, such as its retail business, was complex, as there wasn’t a holistic view of the member or donor. Customer service processes were hampered because of issues with data accuracy, and marketing and cultivation of new donors took significantly more time and caused unnecessary confusion, with donors sometimes receiving multiple fundraising appeals.

By 2011, MoMA was ripe for change and ready to replace its more than thirty-year-old system. The landscape of CRM solutions had had more than a decade to evolve and was at its peak. In 2010, Forrester reported eighteen players in the CRM space. By 2015, this number has dropped to nine, though the leaders have remained about the same. The convergence and maturity of many newish technologies made it possible for the Museum to contemplate a cloud-based solution with an open architecture allowing for ease of integration with other systems and a robust real-time reporting tool., a leader in cloud computing, had been one of the first companies to offer an enterprise application accessible through a Web browser. Its cloud-based CRM product already had more than ten years to develop and stabilize, and was selected for MoMA as it prepared itself for a next-generation CRM solution.

2. Goals

Business goals

The initial goals of the new CRM platform were simple, but sweeping, and focused primarily on its fundraising possibilities:

  • Increase contact management to support the membership program and fundraising efforts
  • Create a 360-degree view of the member and donor
  • Increase membership and development revenue

The goal of a 360-degree view would be achieved through integration of data into the CRM platform from many different Museum channels, such as a member’s visitation history or e-commerce activity. This would give us a more holistic view of a donor’s activity, allowing one to view data on an individual or in aggregate form, such as:

  • Detailed view of giving history (e.g., lifetime giving, largest gift, year-to-date giving, first transaction amount)
  • Effectiveness of marketing campaign and tracking donations by campaign
  • View of relationships among donors
  • Special events ticket purchases
  • Participation in MoMA educational programs
  • MoMA and MoMA PS1 visitation history
  • Retail transactions (both on site and online)
  • Individual and aggregate personal preferences and interests
  • Gifts and loans of art made to the Museum

An integrated CRM platform would also enable increased transparency among internal MoMA departments on cultivation of donors or prospects. Collaboration between departments on marketing campaigns, and tracking the effectiveness of those campaigns, would become possible.

As benefits began to manifest after the initial rollout of the CRM platform in 2011, it became clear that a subsequent goal would be to expand its use beyond MoMA’s membership and fundraising programs. Specifically, the CRM platform would integrate every person who transacted with the Museum from any channel. A philosophy that every person could become a donor or lifetime member of the Museum was adopted. The CRM platform would help enable this by, for example, integrating an online shopper as a prospect. Through integration of their information into the CRM platform, one would be able to see their shopping history and patterns, along with their Museum visitation history. This would allow the Museum to create targeted marketing campaigns specific toward converting them to a member. Once a member, they would be tracked through our membership renewal program and, depending on their donation activity, could be funneled through other fundraising campaigns. Such holistic tracking would not have been possible without an integrated CRM platform.

In April 2010, Apple’s first version of the iPad became generally available. As MoMA’s CRM platform stabilized in 2011, the seemingly widespread adoption of this new type of tablet became apparent. MoMA’s own laptops used in the Museum lobby to support on-site membership conversions were reaching their end of life. It was realized immediately that this was another opportunity driven by convergence of many technology factors all packaged within the iPad, such as longer battery life, constant connection to the Internet, lightweight enough to support true mobility, and fast user adoption driven by the popularity of the iPod and the iPhone. Salesforce’s open architecture also made it possible for the Museum to contemplate development of a custom iOS mobile application with a Salesforce back end. It became clear that the next goal for MoMA was to replace the old laptops with a mobile point-of-sales device that communicated directly with the new Salesforce CRM platform. True mobility would allow the Museum to increase or shrink, as needed, the number of devices that supported membership conversion within the Museum and offered new possibilities for membership conversion and donor cultivation outside of the Museum premises.

Technology goals

While selection of a new CRM platform was critically important to the Museum’s business, of equal importance was the ability to adequately support this new technology and leverage its capabilities fully. It was also important to MoMA that this new technology platform align with MoMA’s own IT cloud strategy. A number of technology goals were established:

  1. Improved availability, reliability, performance, and scalability. By selecting a cloud solution, the business no longer needed to rely on MoMA’s internal network and servers and could utilize the services of a hosted environment requiring Internet access only. While this is a shared multi-tenant environment, the established controls, restrictions, and SLAs ensured a high level of reliability and performance, with organized, planned outage periods.
  1. Lower cost of ownership. A cloud solution also eliminates the need for internal MoMA hardware and everything associated with it, such as regular service, maintenance, patches, and upgrades for both hardware and the operating system.
  1. Improved time to market to support industry changes and standards. A well-managed and well-supported cloud application will always be one step ahead in implementing industry changes, such as support of new standards for PCI or security or integration of new technologies that become mainstream, such as Web 2.0 and support for mobile devices.
  1. Open architecture for ease of integration and customizations. During the more than thirty years of MoMA’s membership program, many applications to support the Museum’s other businesses evolved within MoMA’s IT ecosystem, almost all of which had some integration to the membership system. This included the online website and the e-commerce website, the retail systems (such as the point-of-sales application used by the retail business), homegrown customer service tools, and the ticketing systems. A minimal integration would include a basic read-only lookup of a member during, for example, a ticket purchase. More complex integrations involved purchase of memberships in support of new memberships, renewals, or gift memberships. While the Museum had multiple channels for entry, it had not solved the omni-channel problem for customer experience. Sometimes, a purchase of a new membership in the store on 53rd Street required that a member wait twenty-four to forty-eight hours before using the membership information online, as the new data was not synchronized in real time across multiple Museum systems. The customer service team was also made less efficient as it often had to access multiple systems to determine the most current state of a membership. As the Museum began implementing a new CRM platform, it became clear that the CRM solution needed to have an open architecture that would enable us to build different integration options (e.g., support batch processing for non-critical data, but also support an API call for processing critical data updates in near real time).
  1. Evolved community and a developer network. One of the biggest challenges of a homegrown application is ongoing support. Because MoMA’s legacy membership system evolved over decades, the number of people who could adequately support all of the custom code could be counted on the fingers of one hand. As MoMA looked to implement a new CRM platform, an important element in the new solution was an established developer network, which would allow for easier sharing of ideas and faster resolution of issues.
  1. Centralized data repository. A centralized data repository that also has a user-friendly and flexible front end and a robust reporting tool would eliminate the need for users to export and modify the data in spreadsheets. This would help preserve the integrity of the data, and such repository would be the authoritative source without question. This would prevent all of the issues associated with multiple users having different versions of the same data locally in spreadsheets.

3. Implementation

How does one approach the replacement of a thirty-year-old system? It’s a daunting task—not just because there is new technology and business processes that all of the staff will need to learn, but also because the decisions of what to migrate, what to discard, and what to change require significant planning and a focused team to outline a feasible plan that could span multiple years. In this section, we will describe MoMA’s overall approach, the teams involved, the technical solution, and the implementation challenges that occurred along the way.


With any large project, one technique for managing risk is to divide the project into smaller, more manageable releases. MoMA approached this by first identifying all of the consumers of the membership and donation data. This included internal staff users, external visitors, and system interfaces. Once these were identified, it became possible to structure a phased implementation and rollout process that focused primarily on each set of users.

Release Data consumer
1 Back-office users and customer service
2 Automated processes such as the bank lockbox; integration of other member data such as retail history, visitation history, education course history, gifts, and loans of art; consumers who perform read-only data lookup (e.g., member verification only)
3 On-site membership and donation sales, mobile sales
4 Website integration from and

Table 1: implementation approach based on multiple releases

Because Release 1 represented Version 1 on the new platform, the scope of this release had to be carefully managed. With a focus on who the initial Release 1 users would be, the team was able to write requirements documents specific to the bare minimum that would allow this first set of users to be 85 percent transitioned onto the new CRM platform, and with very little need to access the legacy AS/400 application.

In addition to the needs of this first group of users, the second major aspect of Release 1 was the migration of thirty years’ worth of membership and donor data. The value of MoMA’s membership system is in its data, so a separate track was identified for Release 1 to map the old data structure to the new, and a migration approach through use of an intermediary database was established. In addition, a migration strategy for many of the externally managed spreadsheets by different MoMA business users was established so they would be merged into the new CRM platform as well.

The final major aspect of the Release 1 implementation was that, in approaching the project in releases, it became clear that until the completion of all releases, there will be a period, possibly spanning years, where the legacy AS/400 application and the new Salesforce platform must coexist, both running in parallel, each servicing a different set of users. Eventually, all users will move to the new platform, but until then, the AS/400 legacy system and the new Salesforce platform would need to be kept synchronized.

The completion of Release 1 paved the way for the subsequent releases. Each release brought another major set of end users on to the new CRM platform. At the time of this writing, the only users that still point to the legacy AS/400 application are a subset of online website features. These will be migrated in the spring of 2016 as part of a broader website redesign effort.

Team structure

Once the decision to go to Salesforce was made, it was determined that the project must be led jointly by a member of the MoMA business team from the Membership and Development department and a member of the technical/IT team. Joint leadership ensured equal partnership between MoMA internal teams. The IT owner would ensure that the application was built properly, and the business owner would champion the adoption of the new platform with the end users. Leadership from within MoMA also helped keep all external consulting parties in check.

The next step was to determine the composition and structure of the implementation team. MoMA’s technical team did not have the skill set to take on the new technologies of the CRM platform. As a result, a US-based consulting group was engaged to perform almost the entire initial release. The project phases were identified with key owners:

Project phase Team(s)
Project leadership Jointly led by a senior MoMA business analyst and MoMA technical architect/lead.
Planning and requirements Led by MoMA business analyst, with guidance from Salesforce subject-matter expert.
Technical design Led by implementation consulting group, with MoMA technical team minimally involved.
Development Led by implementation consulting group.
System testing Jointly led by implementation consulting group and MoMA technical team. System testing allowed the MoMA team time to knowledge transfer.
User acceptance testing (UAT) Led by MoMA business analyst and MoMA business users.
Launch sequence Led by implementation consulting group.
Post-production support Jointly led by MoMA business analyst and MoMA IT lead for prioritization of issues. Implementation done by the consulting group.

Table 2: project team structure for Release 1

In the team structure outlined above, the internal MoMA team members accounted for about 30 percent of the total resources and tasks for this initial release. Their primary role, because they lacked the CRM platform expertise and also still needed to support the existing production environment, was limited to knowledge transfer during the requirements. Eventually, the MoMA team, augmented with team members from an offshore development company, took over the development of all subsequent releases.

The solution

The technical solution for the new CRM platform comprised several layers. At its lowest level was the base Salesforce application, on top of which customizations specific to MoMA were made, and several managed packages were then layered on top to support specific and additional functionality. Access to the data and functionality in Salesforce was enabled through a flexible integration layer made up of custom REST API Web services, use of a middleware product called IBM CastIron, and direct data access through Salesforce’s own query language of SOQL and SOSL (for search across large datasets). This solution is shown below.


Figure 1: high-level solution architecture

A robust Web service API layer was essential to the flexibility of the solution, allowing any external source to communicate and access MoMA’s membership data in a standard and secure manner. This API layer was the foundation of the solution, from which other releases of the project were leveraged, such as during the development of the mobile point-of-sales solution and other integration efforts.

4. Implementation lessons learned

This section outlines some lessons learned from the initial CRM platform implementation and subsequent releases. While these represent both successes and challenges that were experienced during the CRM integration, most of the concepts apply to any major new system implementation.

Phase Lessons learned
  • Acknowledge that Version 1 will be the most difficult one. Keep scope to the bare minimum.
  • If you are planning a migration from an old system, acknowledge that there may be a short period where both old and new systems must run simultaneously.
  • Prioritize requirements based on user needs: how do we get as many people onto the new system as quickly as possible?
  • If you are planning a migration, think early on about what data to keep, what to discard, and what needs cleansing.
  • IT and Business teams must work closely on all data mapping and data definition sessions.
  • Think about reporting early on; this will help drive the data design sessions.
  • Think about roles early on (who has access to which data and how).
  • Identify external data sources early on and plan a phased integration approach. Look for middleware products that are tried and true (don’t reinvent the wheel; there are a lot of good tools out there). Build a reusable integration layer (e.g., Web service layer for common integrations from different systems).
  • Look for developer community application exchanges for pre-built packages before investing in significant customization efforts.
  • If data needs to be migrated, outsource the data migration script development because these are usually one-time throwaway works. Keep in-house staff for development on the new platform so they grow and learn the new toolset.
  • IT and Business teams should meet every day to discuss design issues that surface during development.
  • Scope should be revisited and reconfirmed every day.
  • IT and Business teams should meet every day to review design changes or enhancements that surface during testing.
  • Enforce a code freeze period to allow for the new system to have a period of stability during testing.
  • Allocate enough time for user acceptance testing. This will help with overall adoption.
  • Provide organized training sessions, customized to your business. Include training that is specific to the user and role type. Adequate training is essential towards successful adoption.
Production rollout
  • As the QA testing effort finishes, start work early on with the production rollout task checklist. Be detailed with each task rollout and owner.
  • If possible, perform a dry run of the checklist in a full sandbox environment. For Version 1 releases, this may be necessary for many reasons, such as to determine how long each task will take. Some data migrations may take many hours, requiring the old production system to be frozen while migration occurs.
  • Make sure to have a clear rollback plan if rollout is a (gasp!) failure.
  • Allocate time in the schedule, money, and resources for post-production support.
  • Acknowledge that the post-production support period for Version 1 may require 75 percent of the team, which means it will be difficult to start new work immediately after release.
  • The rate of incoming issues after release may seem overwhelming at times. IT and Business teams should meet every day to prioritize issues that should get fixed.
  • There is light at the end of the tunnel! Plan very regular incremental releases, to both fix issues and roll out additional features. This gives users more confidence in the new application.
  • After the initial training, plan subsequent training sessions. Train the users to train each other so the task is shared between many people.
  • As Version 1 stabilizes, look toward the planning of the subsequent major phases. Ensure that the prioritization of those phases still makes sense, and approach them as major projects to keep up the momentum and keep the team focused.
  • If Phase 1 included a significant data migration effort, accept that data cleansing will be an ongoing effort for potentially years to come.

Table 3: implementation – lessons learned

Results and outcome: The 360-degree view

The Museum of Modern Art has multiple ways in which individuals may interact with the institution, from visiting the Museum to joining a membership program to purchasing items from the MoMA retail stores. Prior to our CRM platform implementation, this analysis for our visitors and donors was disjointed and based on only one dimension to drive business strategy.

Membership and retail improvements

After implementing an integrated CRM platform, the Museum was able to look holistically at members and donors to more accurately gauge their interaction. Certain business questions that spanned data silos could now be answered. For instance, what days are most profitable to run sales specifically for members? What is the optimal number of days for such sale periods? This requires detailed retail shopping data as well as member information. The following describes some important results found after using the data in the new CRM system.

An analysis of member shopping information revealed the last day of the sales, driven primarily by e-mail marketing, account for the largest spike in sales. This also revealed the effectiveness of the e-mail marketing campaign on the final days of the sale, reinforcing click-through rate data. In addition, sale periods of varying lengths were analyzed: one day , three days, five days, ten days, and eleven days. It was determined that one- and five-day sale periods drive the most additional sales based on average revenue per day, compared to average revenue on a non-sale day. One-day sales generally result in more than four times the revenue of an average non-sale day, and each day of a five-day sale period yield almost two times the revenue of the average non-sale day. Using these results, the Museum adjusted some of the planned member sale periods to either one- or five-day sale periods to maximize average revenue per day.


Figure 2: member shopping sales: analysis of optimal length of sale periods

Channel shopping

The Museum runs a main retail location within the Museum, smaller bookstore also within the Museum, design store across the street from the Museum, and location in the SoHo neighborhood of New York. Members can also make purchases online at or by calling a toll-free hotline. The latter two shopping channels are collectively referred to as the “direct” channel. This multichannel shopping opportunity poses the question of where members are shopping. How should the Museum most effectively market special member shopping sale periods for each channel?


Figure 3: member shopping patterns based on channel

An assumption may be that members tend to visit the Museum regularly, and seeing items in person would naturally lead to more impulse shopping and a higher rate of sales versus members who shop online and through calling in orders. However, a channel analysis reveals that members tend to spend more dollars per year via the direct channel than in-person shopping at the stores. Further, the price of the average item via direct is roughly 75 percent higher than the average item purchased in stores.

Seeing these results, it is clear that in order to increase revenue, the Museum must emphasize sales online or over the phone—the direct channels. Also, as previously shown, the largest spike in sales is on the last day of the sale. So by shifting the sales to end on Mondays, members will more likely shop on Mondays rather than on Sundays, the previous last sale day, when they would be shopping in person in stores.

Combining these data silos created not just a wide view of members and donors, but also an in-depth view for other departments within the Museum. For instance, the retail department may see a membership discount was applied. However, their understanding of whether that member lives locally, is a high-level donor, is a long time member, or visits the museum weekly was opaque. Likewise, the membership team had basic access to retail systems, and it was difficult to tie this data back to specific members. While they may have reports on total member shopping, they were unable to segment specific members, such as currently lapsed members, who were high online retail purchasers. With an in-depth view of both data silos, the membership team is able to create targeted campaigns for members to renew where the membership discount on retail items would exceed the cost of a membership purchase, thereby paying for itself. For example, if a lapsed member purchased a $1,000 retail item and had also been a member of the Museum, he would have received a 10 percent discount of $100. The cost of an individual membership is $85, making this advantageous. The membership and retail departments can now run reports and create specific marketing campaigns targeting such retail purchasers, thereby increasing the Museum’s membership conversion.

Interdepartmental communication improvements

It has been shown how an integrated CRM solution can give the Museum a more holistic view of its visitors, thereby offering visitors a better experience and increasing the Museum’s overall revenue. But it is equally important to note how a singular system of record promotes cross-departmental communication and collaboration. In the previous examples, membership and retail were discussed as areas of opportunity due to cross-pollination. The overlap among these groups, though, may be less than other combined datasets such as membership and development. Prior to the new system, departments had their own databases and spreadsheets and could edit the data and contact their lists as they needed. This required little interaction between departments. Now that an individual’s record contains both membership and development donations, groups are forced to work closely together when pulling lists and editing a specific record.

Furthermore, the call center and lobby front desk now utilize the same system so that they can make comments and view the same important information about members and donors as needed. The 360-degree view in Salesforce has become a platform between groups to convey information regarding individuals or organizations. It functions as the one system of record in which all departments reference and communicate key information.

New opportunities: Mobile membership lobby application

A cloud-based central repository with readily available REST APIs for easier systems integration opens up possibilities for accessing this information through custom external sources. Currently, MoMA’s main lobby consists of a ticketing desk, membership desk, and information desk for miscellaneous ticketing requests. Each desk had been capable only of serving specific needs and selling certain tickets because of limitations of the applications on the workstation at each desk. A visitor waiting in line for tickets, who then wishes to purchase a membership, must then exit the queue and wait in a different queue rather than being helped immediately. It was not uncommon for a visitor to wait in several lines before all transactions were completed. This situation was less than ideal, especially for membership sales, which should be given priority service. Further, the Museum is currently undergoing a major multiyear building expansion project. Introducing a new solution in the lobby today to address some operational inefficiencies must also consider what the lobby could look like tomorrow.

In July 2014, MoMA introduced an iOS-based mobile point-of-sales application, built on top of Salesforce, to support membership sales. This allowed for a solution that would work at any current desk, any future layout of the lobby, and also outside of the Museum’s 53rd Street location, as the solution was completely mobile.


Figure 4: MoMA membership lobby application – Home page

This solution communicates in real time to Salesforce and leverages key Salesforce base functionality (e.g., fast searches, account lookups, account modifications) so memberships being purchased on the mobile application could be used immediately in any other channel, without the delays of data synchronization.


Figure 5: MoMA membership lobby application – Sample shopping cart page

Visitors at the Museum can now be helped at any desk, improving overall customer service. This also resulted in dramatic improvements in membership conversion for on-site visitors and helped the Museum reach all-time peak numbers for active membership counts during the 2014 holiday season. During busy days when queues were especially long, it had been daunting to wait in another line just to become a member. In an A/B test of old system versus the new mobile device executed over several months, the new mobile system significantly outperformed the old, with many more memberships sold through the mobile application at peak hours compared to what was sold using the old system. Lastly, the mobile devices are easily scalable to deploy multiple registers and even staff to work the lines.


Figure 6: MoMA membership lobby application – A/B testing results of the new system vs. the old

Interestingly, the mobile device, which allowed different departments access to previously disparate functionality and data (i.e., ticketing, membership, corporate membership, staff ticketing), has led to organizational changes as well. Previously, the lobby staff was organized into those who sold memberships only, those who sold general admissions tickets only, and those who supported other miscellaneous ticketing functions. These roles were completely independent and required their own specific staffing needs. Through the mobile applications, all lobby staff is now able to access all lobby functions equally. An agent who previously sold only general admissions tickets can now also sell memberships, thereby improving a staff member’s knowledge of the Museum’s programs and providing better service to the visitor. While there are still some minor skillset differences required per location, staffing can be much more fluid, enabling the lobby to transition into any state, ready for any change with the building expansion project.

5. Challenges

While there were several successes over the multiyear project, many parts did not yield the expected results or required several revisions.

Adoption and legacy system

User adoption tends to be a topic of discussion in terms of technology project success. While member and donor data was indeed entered into the new integrated CRM system, it was also true that users did not have much of a choice, making perceived adoption high in certain aspects. However, five years after launch, the legacy system has not been disabled yet, as some channels still write to it first, requiring that data to be synchronized with Salesforce. The legacy system is still referred to at times when there are integration issues. Many business users have two monitors at their desk: one for the new CRM platform and one for the legacy system. It has been tougher and a longer road to kill off the legacy database than anticipated. As there are many channels that integrated into it, it requires each department to buy into updating their system to point to the new Salesforce environment. Doing so may be a project of varying difficulty, and sometimes changes will have to be done only when it can be aligned with another project initiative. For instance, still points to the legacy system, which is then synchronized with Salesforce. In the spring of 2016, plans to redesign the member area of the site, offering new features for members and donors to manage their accounts. Integration with the new CRM platform will also be a part of this project, but in the meantime the legacy system must be kept synchronized until the completion of this project.

While many channels are being integrated into the CRM platform, some channels have had low adoption rates among other departments. For instance, gifts and loans of art has been integrated from the Museum’s collection system, giving users a view of members or donors who have also donated a piece of artwork to the Museum. Initially, this was thought to be useful information when prospecting for new campaigns or for event invite lists. However, this data has rarely been used for any significant prospecting, nor has there been any major improvement to event lists. Moving forward, it may be beneficial to create mock-up reports of siloed data to see if this would improve any current processes. For instance, would an event invite list based off of those who have gifted art to the Museum be more effective and relevant than an event list based off of exhibition funding and previous invite lists? Comparing the two lists and perhaps experimenting with campaigns may yield more information on whether it makes sense to integrate such systems. It is important to note that both implementing and maintaining these integrations requires significant work. It is therefore vital to only pull in data that makes sense, otherwise project costs and ongoing expenses will balloon. Also, giving new users access to massive amounts of data will inundate them and make the system seem daunting and difficult to use. This will affect long-term adoption, overall effectiveness of the enterprise system, and overall budget for ongoing operations.

Another example of failed user adoption was MoMA’s pledges functionality, built into the CRM platform. When a donor makes a pledge for x amount of dollars over y amount of years in writing, this is currently tracked in spreadsheets and in the general ledger. To have a full view of a donor’s giving past and potential, pledges are critical. Customizations in the CRM platform were made to follow business rules for when payments came in above or below the pledged amount and how to handle subsequent installments. However, as a result of staffing changes in the Museum’s development department, and changes in priority of other projects, the pledge portion of the Salesforce project was shelved even though all technical work was complete. This illustrates that having the key business people available is as critical as completing the technical aspect of a project. A beautifully architected technical solution is a failure if no one uses it.

Feature experimentation

With the implementation of the mobile application for membership sales, the team experimented with new business processes. Not all experiments were successful.

One such experiment was an attempt to address long transaction times when selling memberships. Long transaction times lead to a long queue at the membership desk, which could, in turn, discourage visitors from becoming a member. The membership sales process, even at its simplest, requires the agent to ask many questions and enter many details about the visitor—from name, address, phone, e-mail address, membership category, and account preferences—before actually even transacting. This can be a tedious data-entry process and further complicated because of a high percentage of non-English-speaking visitors. In order to keep transaction times to a minimum, every step needed to process a membership was analyzed when building the new iPad membership point-of-sale.


Figure 7: MoMA membership lobby application – Address auto-complete function

The old process required a member to fill out a paper form with their name and address. A membership sales associate would then key in this information into the old system. To improve this process, the new iPad application would allow the new member to key in their information themselves and, using the Google Places address auto-completion, allowed for addresses to be found faster and keyed in only once. This worked well in testing; however, once this was rolled out, many members had difficulty typing in their information. Visitors were also not accustomed to simply typing their address partially and seeing a drop-down list of different addresses to select. The agent also had to instruct the visitor to just type their address, which became very confusing. Some users entered only their street or city information, resulting in addresses not found or incomplete data getting saved. This process was eventually rolled back, so new members now still write their information onto a paper form and then a sales associate keys this into the new application. More in-depth user testing and experimentation will be needed to refine this process in the future.

Other challenges

While the CRM project was generally seen as a major success, there were challenges throughout every phase. Many challenges were typical project management issues regarding budgets, staffing, and scope creep. Working in the non-profit sector, factors can become even more acute. With limited staff and budget, functionality is often cut. This can lead to delivery of a system with less functionality than the legacy system, which can cause user resentment. This was experienced often throughout the project when features such as a bulk membership upload tool were cut due to budget and timelines. The end users received a system that was initially more difficult to use than the previous system. Only after subsequent releases did the new system eventually reach parity.

Another challenge was maintaining production while simultaneously implementing major new features. The business is constantly changing and needing updates, and certain requests from business users require technical assistance or super-user assistance. To handle this, a few measures were taken. First, during implementation of the membership lobby application project, a number of development environments were created. These environments were undergoing considerable change as major updates were being made, so they could not be reliably used for production support. As a result, a separate track of production support environments were created and used exclusively for making isolated production updates. Maintaining multiple environments increased the overall maintenance effort, requiring regular merging and refreshes of both environments throughout the project. Second, when staffing, one must not assume employees will be 100 percent available on the project. Production support must be taken into account. Some IT staff was allocated at only 50 percent, while others at 90 percent. Lastly, business users were made aware of the major project being implemented and that update requests would be slower than usual and only small and critical updates were made. Setting expectations with the business teams was critical.

Another challenge experienced with a 360-degree view and an integrated platform, is the need for constant data cleansing. With data coming in from so many channels, dirty data and duplicate data will make its way into the system. Data, such as addresses, may be clean coming from one channel where it is scrubbed using Google Maps; however, it may contain bad data from mailing lists that have been uploaded. Further, different channels may view “clean data” differently. For instance, Google Maps may insert “United States” for the country field. However, for direct mail, the Museum may want country to be blank whenever it is “United States,” as it does not look ideal to include country when mailing domestically. Business rules must be set up when importing data or using ETL tools; however, with various departments using the system, this can easily get out of hand. Regular monitoring and cleansing is required.

6. Conclusion

The biggest challenge has been realizing organization-wide projects such as this are Sisyphean efforts. There is not an end date where the project is complete and everyone walks away. Constant vigilance is required as technologies are constantly evolving and the business is constantly changing. Technologies will become outdated or unsupported. New business endeavors will be taken. Business rules that were set in stone that would supposedly never change have a funny way of changing once an enterprise system is built to enforce these rules. New staff will join the organization with fresh ideas that challenge the current ways of doing business. The best ways to mitigate these changes are to build systems that are highly configurable with little information and even business rules being hard-coded.

Despite the challenges encountered, the CRM platform implementation has proved to be a successful project, albeit a very long one. It has allowed the Museum to better understand its constituents and hence offer them better experiences and services. Now that all of the Museum’s data is in a central cloud-based repository, one of the next steps is to feed this into a sophisticated analytics tool such as Tableau. A pilot program has already begun with a few power users. Also, a critical next step involves more training for general staff to help them to better analyze the data available to them. While many employees may know data that pertains to their department or job role well, they may be unaware of what information other departments track that is available in the CRM platform. Making sure employees are aware of this will be an ongoing effort as staff turns over.

As the Museum looks ahead, there is still much to accomplish. It is important to approach future projects with the same critical eye used when viewing art. With RFIDs, location beacons, wearables, improved facial recognition software, and a host of other emerging technologies, there are a lot of possibilities to gather even more data. One must gauge new technologies to see if they have the potential to make substantive improvements in the business and determine which will be useful in the long term and which will just be a flash in the pan. There is the overused adage of “a picture is worth a thousand words.” A 360-degree view of a member or donor is selecting which thousand words and creating an accurate picture that is worthy.


This paper represents the immense contributions and collaborative work over five years of several MoMA teams, including many individuals, past and present, of the Membership, Development, Marketing, Information Technology, Digital Media, Retail, Finance, Accounting, and Internal Audit departments. This paper also acknowledges the contributions made by the Appirio and Mindtree teams, who were essential to both the initial implementation and all of the subsequent releases of the CRM platform.


Leggett, K. (2015). “The Forrester Wave™: CRM Suites For Large Organizations, Q1 2015.” Forrester: Kate Leggett’s Blog. March 26, 2015. Available

Cite as:
. "The 360-degree view: Why an integrated CRM platform is important in growing a museum’s membership program." MWA2015: Museums and the Web Asia 2015. Published August 21, 2015. Consulted .