
Collections Management RFP Questions & Answers
This page has the Five Colleges, Incorporated Request for Proposals for Collections Management System vendor questions and our responses. We have organized our responses to vendor questions thematically for transparency and to ensure equitable distribution of information. Please note that our “wish list” items are not requirements. Because we are a large consortium with many different stakeholders and needs, we don’t anticipate that any solution will check every box. We are open to learning about creative solutions to our collections’ needs based on a holistic consideration of the environment and expectations described in the RFP.
Accessibility
Q: Our solution is 508 compliant for the portal (access point for the public as well as for staff who have read-only access), but our solution is not 508 compliant for the main staff interface where the data is managed. Is this acceptable? Or does this exclude our solution from your consideration?
A: This does not exclude the solution from consideration. Accessibility is important to us, so we would like all potential vendors to describe your efforts to be compliant with WCAG 2.0 level AA, Section 508, and the Americans with Disabilities Act. Are there improvements in accessibility you hope to make or that are in production? What is your company’s long-term mission or commitment to accessibility?
Budget + Timeline
Q: Is there a determined budget, and if yes, how is it allocated? ie. Project vs. Ongoing costs. Is there an expected contract length?
A: We consider this RFP process central to solidifying a budget and timeline that fully reflects the scope and needs of our specific CMS Project given the included criteria. Please respond with a proposed cost and timeline based on the needs and requirements presented in the RFP.
Q: For a project of this scale the expected project completion date appears ambitious. Is FCI open to modifications on this timeline by the vendor, also keeping in mind the deadline for current system sunsetting?
A: We are open to adjusting the timeline based on the vendor’s considerations.
Q: Can you provide further detail on the evaluation rubric?
A: The evaluation rubric will incorporate a weighted score for each project component as described in the RFP. This will include a completeness score for the various project components (Y/N) and a score relating how each proposal component meets user needs (1-10). During the demonstration period, potential users will have the opportunity to complete a qualitative evaluation (where they describe how the specific functions of the proposed solutions meet their individual museum’s needs).
Q: Is it possible to have a deadline extension granted for submission?
A: Due to the nature of our budget cycles and collaboration across multiple institutions, it is not possible to extend the deadline at this time. If you have concerns about meeting the deadline for specific elements of this proposal, please email museums-cms@fivecolleges.edu.
Configuration
Q: Would you like confirmation of capabilities of essential & wish list items addressed in this RFP or is this more of an FYI for vendors?
A: More of an FYI. We understand that each system, vendor proposal, and implementation may be a little different, and we are open to creative solutions that make our work lives easier! The lists in Appendix C represent either current database functionality the museums wish to preserve, or envisioned solutions to problems posed by current implementation and/or workflow. If the proposed solutions address the listed functions, great! If they do not, that is by no means disqualifying. We are looking to make our workflows more efficient, simple, and transparent, and recognize that newer systems may interact with data in different and new ways.
Q: Can FCI confirm the total number of concurrent licenses required for the CMS?
A: This may be dependent on per-license fees and breakpoint discounts. If possible, please share any licensing fees that may be relevant. It would also be helpful to know whether we are “locked” into a certain number of licenses on contract signing, or if we can add as needed.
Our highest to date number of concurrent users is 15, but we expect that with an easier-to-use system, more museum staff will participate in various aspects of database interaction. Therefore, we anticipate needing at least 30 licenses.
Q: Can you share a bit more about the current security controls in the partitioning of the records?
A: A special numeric field in some tables (RECORD_VIEW) limits users with the matching view to only see "their" museum’s records. This affects objects, people, facilities, and any activities related to these modules (location, acquisition, etc.). We also have a number of user “roles” at each museum, but these are consistent across record views.
Q: Can more information be provided on what is needed to provide field definitions? Our solution does offer configurable help text, and fields can be configured for adding descriptions of images, etc. Is that what you are referring to?
A: Our current system offers configurable help text that is accessible either through a series of clicks or knowledge of keyboard shortcuts. As a result, many of our users have trouble finding the help text. We are hoping that a new solution will offer configurable help text/field definitions (editable by the administrator), and potentially provide default language for new or added fields. Importantly, these need to be straightforward for our users to access! One possible suggestion we heard from users is a pop-up help text that appears when hovering over a field.
Q: Can you provide more information on what parts of your collection require the hierarchical record structure of Collections, sub-collections, file, item-level?
A: Each archive within the Five Colleges Consortium manages its own collection, with some sharing an instance of ArchivesSpace and others maintaining separate instances. All of these are separate from the museums' collections management system.
Each museum maintains its separate collections of objects, many of which are supported by museum records, some of which include archival material. For example, SCMA has a collection of exhibition records and related correspondence which are held by the museum rather than the college archives, but which are related to holdings in the Smith College Special Collections.
One area where hierarchical description is especially important is in the cases where there is a discrete collection of works within a museum collection, which should be facetable/searchable. For instance, the UMCA’s collection includes a sub-collection of Works Progress Administration prints. Or, the collection of historic powder horns within the collection of Historic Deerfield.
Importantly, all of our museums could benefit from hierarchical, parent-child options for cataloging multi-part objects or sets of objects, such as portfolios or tea sets. Going down to the file level is less important than going to the item level, but the availability of file-level description might be helpful for museums to catalog certain aspects of their collections records.
Q: In our solution security settings can restrict staff from seeing specific fields and/or specific records that belong to other sites (including location of objects); however, if they have permission to edit location information, we cannot restrict accessing the FCI’s list of all possible locations. For example, a staff member from AC could be restricted from seeing objects from HC, and/or restricted from seeing locations of objects, but if a staff member from AC has permission to see/edit locations and was selecting a location for an object, they would have access to the full list of FCI locations, including possible locations at AC and HC, etc. Is this acceptable? Or does this exclude our solution from your consideration?
A: This does not exclude the solution from consideration. But our preference is to maintain separate locations that are not visible to colleagues at other museums for security reasons.
Q: Will there be a single individual overseeing the entire CMS (all data and configurations), or will the CMS be managed by the site managers for each museum? a. How will decision about shared data and configurations be managed in either scenario?
A: We envision a combined approach to maintain the integrity of each museums’ control over separate data while collaborating where it is more efficient. Given the staffing limitations at each museum, it is assumed that a single, shared database administrator will be largely responsible for data governance, maintaining and configuring fields, auditing/performing data cleanup and maintenance, and administering lists in shared authorities.
Ideally, site managers at each museum would be able to: make minor configurations to data entry screens (rearrange fields, for example, or hide certain fields from view). Site managers should be able to edit or propose changes to any local controlled lists (e.g. “pop-up” or “dropdown”) for their own collections or site-specific fields. They should also be able to connect with vendor tech support; bulk ingest/export data from a template; and make tweaks to the formatting of reports.
If some or all of the functions above are only achievable through a single-admin model, please describe this in the RFP. We have spent the last two years developing a robust data governance model accommodating a single admin. Decisions about changes to data structure, configurations, core/shared data definitions, standards, shared data that will affect discovery, authority files, or lists, and configurations affecting the whole database (not just by user roles/views) are made at a monthly governance meeting and implemented by the FCI administrator. Each site may elect to make its own decisions about adding data to local lists, etc. and the single administrator may either facilitate or execute this process.
Q: Separate logins to one shared systems or separate instances altogether? If there is a desire for a shared instance or even syncing across instances, do you envision having identical fields or distinct profiles with fields relevant to the collections of the institution using the system (art vs history will have different needs, for example)? For our purposes, a list of which procedures (from page 14) would ideally be shared would be helpful.
A: One shared system (i.e., separate logins) is the current model. See the information on partitioning for more information about how this works. We are interested in retaining this model but believe we can improve on it! Generally speaking, in our current system, we share a set of “core” fields for object records and have implemented a data governance process for the museums to make changes to fields, configurations, and lists. Historically, every museum shared an identical set of modules, fields, and field configurations, and drop-down lists, but because this was a very rigid model, most museums developed workarounds and implemented the use of free-text fields to meet their data entry practitioner needs. We believe that a more flexible model, such as the template model with profiles for each museum, user role, or object type, can serve our individual museums better while continuing to collaborate on the core information that is integral to shared access for our audiences.
Q: Can FCI provide a data export from each museum for the purposes of analysis of tables/fields?
A: Yes, upon request, please email museums-cms@fivecolleges.edu.
Q: Can FCI provide report samples of what must be included in the new CMS? [Reports – pg. 22]
A: Yes, upon request. Please email museums-cms@fivecolleges.edu.
Collaboration + Vision
Q: How does FCI envision collaboration between museums?
A: As each museum within the consortium is managed separately, with largely separate staffing, resources, branding, and strategic plans, it’s important for the museums to retain the individual management of collections objects. The museums have small staffs, particularly in collections management. So, we envision collaboration where there is work within each of the individual museums that might cross collection boundaries – where it is more efficient to work together than individually, and where collaboration can lead to shared discovery.
One example of areas where we find labor and/or research overlap are artist names and dates. We also find that multiple museums within the consortium have acquired examples of the same portfolios, and would like to be able to easily find out about these cases to avoid redundancy future. Another example is where three or four museums may be mentioned within the same catalogue raisonne, but each museum maintains their own record of the publication. However, we want to make sure that as collaboration happens, each museum can retain as much control over their own collections objects, description, and curatorial needs as possible.
Q: Can FCI clarify the expected behaviour of site-level privacy with catalogue records that are visible across institutions? [Location management – pg. 20]
A: Museum users should be able to view (not edit) each other's catalogue records, excluding only potentially-sensitive information like valuation and location.
Q: Our biggest point of clarification is getting a better idea of how you envision this solution as a collaborative environment for the six institutions that will be using it. I’m seeing that there’s a desire to still maintain a degree of security even between institutions. Correct me if I’m wrong but how I’m interpreting it is that you’d like objects to be editable only by the collecting institution but perhaps some or all visible to the other consortia members to be pulled into buckets for projects like exhibitions or other conceptual groupings. You’d like to share some “person records” like artists but not donors; some authority grouping shared but some restricted.
A: This is correct. See other responses in this section for further details, but the museums should be able to view/search each other’s separately managed objects and share authority information where it promotes efficiency and discovery.
Q: The RFP mentions that partitioning impedes collaboration. Do the colleges want to remain separated as they are now with zero access to each other's collections? It would be great to have clarification about what type of collaboration is desired that is currently being impeded by the current system[...].
A: Ideally, museums should be able to view and search for (not edit) objects in each other's collections, excluding sensitive information like valuations, locations, indigenous knowledge or objects, or contact information. Where information is shared, museums want to be able to limit their searches to all collections (a universal search) or just their own museum.
It would be ideal if loan requests, and exhibitions using objects from multiple collections could be organized from within the CMS (for example, the Mead may have an exhibition with objects loaned in from both SCMA and UMCA, so a single exhibition record could be easily created by the Mead as the hosting institution with SCMA and UMCA objects attached).
The current setup is too restrictive and inflexible. Each museum has separate agent/entity records, for example, which results in 6x duplication of cataloging effort, if each collection includes works by the same artist. The same is true of other modules, such as places and publications – each museum enters their own data, resulting in duplicated effort.
Below is a table representing the current modules/functions in use and whether the museums wish to keep these shared or separate:
Module |
Module Description |
Data Separation/Collaboration Preferences |
Objects |
Catalog |
|
Media |
Digital surrogates, related images and media |
|
Events (Classroom visits) |
Authority file |
|
Facilities/Locations |
Authority file |
|
People |
Authority file |
|
Places |
Authority file |
|
Subjects |
Authority file |
|
Publications |
Authority file |
|
Terms (AAT) |
Authority file |
|
Acquisition |
Action |
|
Entry |
Action |
|
Loan |
Action |
|
Exhibition |
Action |
|
Audit (inventory) |
Action |
|
Condition |
Action |
|
Conservation |
Action |
|
Damage |
Action |
|
Dispatch |
Action |
|
Disposal |
Action |
|
Groups |
Action |
|
Hazard |
Action |
|
Insurance |
Action |
|
Loss |
Action |
|
Repro Request |
Action |
|
Rights/Permits |
Action |
|
Valuation |
Action |
|
Q: What modules/data are to be shared amongst all museums?
A: See Table Here
Q: How should separate modules that include shared data be handled? (I.E inter organizational loans/exhibits)
A: Generally, we would like the six museums to be able to incorporate consortium museums’ collection objects through workflows, not by editing each other's objects or process activities.
For example, loans should be kept separate – we would love to see a solution where registrars or curators at Museum A could “request” or “approve” a loan from Museum B from within the shared catalog. If approved, the object or loan-out data from Museum A could transfer into a loan-in record at Museum B. Staff at the organizing museum should retain control over adding objects to exhibitions, but could request loans from other museums.
Q: How should the CMS manage Person Records which have roles in both FCI’s separated and shared categories? [Agent Management – pg. 16] a. Example: A single individual (Artist) donates a work of art and holds the roles of both creator and donor.
A: We can think of a few different acceptable scenarios, such as: 1. donors managed in a separate list from creators (ex. Local list of donors vs. Authority file based on ULAN) data or 2. donors managed in the same list as creators with visibility to each based on role.
Donors managed in a separate list from creators would potentially create some duplication, but certainly not as much duplication as each of the six museums creating and maintaining individual artist records does. In our shared system, we have only 400 records where the source is noted to be the same as the artist. By contrast, we have about 24,000 agent records total, many of which are duplicates which have been entered individually by each museum.
Q: Can FCI expand on the method(s) required for data entry approval workflows? [Cataloguing - pg. 16] a. Do these differ between museums?
A: Each museum’s desired approval and data entry workflows are dependent on the staffing levels and roles at each museum. Generally, at each museum, the collections manager or registrar (site manager) should have ultimate approval for edits to catalog records and the publication of new records. For museums with more curatorial staff, curators and collections managers may wish to determine more specifically which roles can approve edits to certain fields (for example, curators may wish to approve edits to materials made by interns, while registrars may wish to approve preliminary entries for objects to be acquired or loans out). Ideally, the method would be something like: edited records could go into a “queue” and changes to records would be approved or rejected by the relevant user.
Q: Can FCI describe the workflows and approvals process for nonauthoritative keywords? [ Thesauri – pg. 26]
A: Anyone may suggest tags to their site manager. Site managers add suggestions to the controlled list via a google form. Before suggesting new tags, we ask users to make sure the tag is not already represented in the controlled list of terms. We ask contributors to source suggestions from the Getty vocabularies whenever possible, followed by simple Library of Congress authorized headings. We ask users to suggest local terms only when the tag is not found in either of these. Suggestions are reviewed as an agenda item on a monthly basis and the FCI database admin adds them to the database.
Data Exchange + Integrations
Q: “Compatibility with a variety of metadata schema and standards used in library, archives, and museum cataloging”...Later on page 21 there is reference to particular formats as “Flexibly support various data import and export formats (excel, csv, htm, pdf, doc) and schema (MODS, XML, EADS,MARC).” We support some but not all of these formats for import/export in our solution. Is this acceptable? Or does this exclude our solution from your consideration?
A: This does not exclude the solution from consideration. It would be helpful to describe which formats are supported in import/export in your solution.
Q: “Integration with a variety of digital asset and content management systems”: Please specify whether there are specific DAM and content management systems FCI is planning to integrate with and whether vendors should provide estimates for consulting or programming for these integrations during the initial project or future.
A: Each museum either has implemented, or is planning to adopt, a digital asset management system. All museums link media files hosted on a single, shared on-prem server at one of the colleges to the current CMS.
Museum |
DAMS |
Open to vendor DAMS solution or estimate? |
Mead Art Museum at Amherst College |
None |
Yes |
Hampshire College Art Gallery |
None |
Yes |
Historic Deerfield |
None |
Yes |
Mt. Holyoke College Art Museum |
ResourceSpace |
Yes |
SCMA |
ResourceSpace |
Yes |
UMCA |
None |
Yes |
Q: Exhibitions: “Integration with sketchup or other exhibition planning/3D rendering software” Are any of the institutions currently using exhibition planning software? Would it be of interest for the vendor to provide recommendations?
A: Currently, at least three of our museums (MHCAM, SCMA, and UMCA) use Sketchup and 3D rendering software for object viewing, exhibition planning, and virtual tours. It would be of interest for the vendor to provide recommendations about exhibition planning software.
Q: What third party integrations with CMS are required (DAMS/Content Management Systems/ Digital preservation systems etc)?
a. Same across all museums or do they differ?
A: Different. Each museum maintains separate DAMS and imaging workflows (see list), one museum uses Preservica, and may use Drupal, Wordpress, or other content management systems on individual museum and class websites.
b. What type of integrations (I.E Push, pull or both)?
A: DAMS: both; Digital Preservation: both; Content Management: push
c. Are any of these systems to be provided by vendor as part of the proposal? A: A vendor provided API for the CMS is required, but third party integrations are not. However, we welcome creative suggestions, solutions, or estimates (please separate estimates from the main CMS system).
Q: For the purposes of the data migration, is Mimsy XG the only data source that required migration?
A: The vast majority of our data is in MimsyXG. We also have minimal data in Mobius, our current public portal (a separate MySQL database), which will be important to retain in a future discovery interface (ex. statements relating to ongoing research, a Museum Repository field).
Q: How much media storage is required? (# of GB or TB) a. How many media storage locations are currently being used? b. What are they? (Cloud storage/ Network drives / DAMS etc) c. Do these differ between each museum?
A: Currently all museums are sharing space on a network drive and using ~110GB. Media attached to the database are linked from this shared drive, though individual museums maintain different systems and workflows–some use this shared network drive as their primary image storage, while others do not.
Q: [End-user/Collaboration/Web – pg. 18] 14. Can FCI provide the library, digital collection and archive systems that need to be integrated with the CMS?
A: We would like to explore possibilities for integrating our discovery systems in the following priority order: First, exchanging our data with the EBSCO Discovery Service (for discovery of works of art alongside books, serials, and special collections). Second, we would like to explore exchanging our data with the campuses’ digital collections platforms which run on Islandora 2 and Archipelago. Third, we would like to explore the integration of work and media metadata for inclusion within JSTOR’s Art Image collections. We are glad to consider solutions which address these systems directly or which provide a data exchange API or OAI-PMH protocol.
Q: Can FCI provide details on the schema and standards used by library, archive, and museum cataloging for compatibility requirements?
A: Interoperability with library and archives is a wish list item, rather than a requirement, but shared discovery is a long-term strategic goal. The Five College Libraries use RDA and MARC21 for cataloging bibliographic records, and for discovery, the platform (EDS) uses MARCXML. Ideally, the new system would provide an API and OAI-PMH service connections, so that we could push information to the library discovery system. Archives standards may differ, but the digital collections use a modified MODS schema for publication to the shared platform. The museums historically have tried to adhere to the CCO and CDWA standards when cataloging, but these have been modified to meet the discovery system’s compatibility. In terms of data exchange compatibility, it would be ideal if the new system could produce standardized XML that can be mapped to MARC, MODS, and VRA Core.
Q: Can FCI expand on “integrate results from linked databases alongside results from the collection database”? [Retrieval, search & find – pg. 24] a. Can an example be provided? b. Is this function required through the CMS or public portal?
A: This is more of a wish list item that refers to a solution for more shareable, collaborative discovery as described in our desired integrations with EDS, Five College Compass, and/or JSTOR. We are especially interested in solutions that can provide a method for “linking” to external related resources in the discovery interface and/or provide an API that would allow for future development of shared discovery in concert with our colleagues in libraries and archives.
For example, a student searching for a print by Barry Moser in one of the museum collections could find articles in the library database (EDS), archival collections related to Barry Moser, and digital images of other works by Moser on Five College compass. This is a public portal concern, but if the CMS solution can integrate or accommodate basic cross-collection linking via permalinks without a heavy lift, that would be great!
Q: Can FCI list the multiple schemas requiring support? [Digital asset/media management – pg. 18]
A: See above.
Q: [Integrations – pg. 19 / Platform system – pg. 22] Please elaborate on the linked information required, including metadata.
We need the existing answer to be deleted and replaced with:
A: We would like to exchange core object information (repository, title, dates, creators, work type, etc.) with the libraries to surface works in EDS (it would not be necessary to surface all library works in the museum system). If possible, we would like to exchange media information with digital and image collections on our campuses as described elsewhere in this Q+A.
For image/media metadata, we would primarily want to be able to push to other platforms, either a modified DublinCore or VRACore depending on platform. It would be great for the new system to generate standardized XML that can be mapped to MARC, MODS, or VRA Core.
Q: When “cross-reference” is mentioned, does this refer to a link between records being formed or something else? [Pg 16]
A: Yes, “cross-reference” in this case refers to connections between tables. For example, an object may be connected to an agent record, related object or related agent records, or media records.
Q: Can FCI identify what “course management system” is referring to? [Groups/lists – pg. 19] a. What information is required for the export? b. What format is required for the export?
A: Course management systems refer to learning platforms like Blackboard or Moodle. We would like faculty to be able to access and use museum content in their curricula, but this is a wish list item rather than a requirement. This could look like an export of permalinks to the public website, images, and/or tombstone data to post on an art history courses’ website, for example. It could also look like a posted report (pdf) or a gallery slideshow of images. We welcome creative ideas and proposals for how the CMS and portal could be accessed by faculty and students!
Q: Which external data sources are required for validation by the CMS? [Thesauri – pg25]
A: Ideally, we would be able to flexibly incorporate or retrieve data from multiple external vocabularies (ex. specialized sources available as linked data, like terms from the Homosaurus). At a minimum, we would like to validate against: the Getty Vocabularies (ULAN, AAT, and TGN), and Nomenclature. It is also important that current work being undertaken through the NEH grant to assign Library of Congress subjects is incorporated into the Thesaurus or something like a “Concepts” authority file. Further, we would like the flexibility to add terms manually and in bulk into the thesaurus from other sources as needed, with a field to link to otherwise identify the data source.
Q: You state you’d like “Integration with a variety of digital asset and content management systems and procedures.” What are those systems that are currently in use?
A: See above.
Other Features
Q: On page 20: “Generate random lists for spot checks.” While we do have the capability of creating lists based on many different criteria to use for inventory and spot checks, including options that would gather an assortment of records, we do not have a feature for creating a truly “random” list (input of criteria for a list is required). Is this acceptable? Or does this exclude our solution from your consideration?
A: This does not exclude the solution from consideration. As long as we can export our data easily, random lists can be generated outside of the software, but it can be a handy time-saving feature.
Q: Does FCI require exporting from CMS solution or from web platform?
A: We do require the ability to export from the CMS for admin purposes (full data – we should be able to easily retrieve our data at any time) as well as simple exports of tombstone data for end users from the web platform for classroom or researcher use.
Q: Can FCI describe the desired integration with environmental monitoring software? [Location management – pg. 20] a. Which software? b. Is API documentation available? c. What type of integrations (I.E Push, pull or both)?
A: This is a wish list item – meaning that it may or may not be on the market and is not a requirement. Examples given by our community members typically express that it would be great to know more about the light levels or relative humidity in a certain gallery or storage area when moving objects into a new facility. Users expressed that a notification of improper storage conditions for certain objects would be helpful. The museums all use different software for this – systems in use include E-climate notebook, Automated Logic, Lascar Dataloggers, Easylog Cloud System, Conserv, and Metasys at Johnson Controls. None of our users expect that these systems should be able to “talk” to the new CMS, but it might be helpful for the new CMS to include fields for some environmental monitoring data about storage and gallery facilities.
Q: What data points are required for “Area to document instructions”? [Location management – pg. 21]
A: Fields or data elements within object, location, or movement records that specify: environmental standards for movement; who needs to authorize movements; risks identified and how to handle; instructions for transport or packing; instructions on who to contact including insurance should anything go wrong; who wrote any instructions and when.
Q: Can FCI expand on the “variety of access and use policies” required by the CMS and public portal? [Research and use – pg. 23] a. Can use cases be provided?
This pertains to access for researchers and classroom or study room access to objects, although in future we might also wish to accommodate restrictions or policies related to the photography or other use of objects. The current access restriction statements are:
- “Currently out for conservation”
- “Currently unavailable. Please contact museum.”
- “Offsite - unavailable”
- Null (assumed available for researcher access, museum must be contacted)
Users + User Support
Q: How many database administrators do you anticipate having?
A: Exact staffing levels to be determined, but at least 1 FTE to manage systems configurations, users, and vendor communications. Certain administrative functions, such as data entry field configurations for views at each museum or additions to local-only controlled lists, could ideally be performed by site managers (that is, the primary database user at each museum, usually a collections manager or registrar).
Q: Do you envision training in-person or remotely and how many people would you anticipate attending?
A: Given the complex environment and number of stakeholders, we anticipate a mixed-methods approach to training. Certainly, we hope there will be onboarding training for users of all roles. Given our different locations, this could be a virtual training. We anticipate 1-6 registrars from each museum, as well as approximately 1-4 curators, and 1-4 educators or other staff members from each museum will attend a preliminary training. Role-specific training on important functions would be beneficial. If available and applicable, please provide a fee schedule for virtual or in-person meetings, as well as breakpoints for the number of attendees.
As staff turnover naturally occurs across the six different museums using this system, ongoing support, communication, community, and availability of documentation and training materials is very important to us. This may look like continuing training opportunities available online in the form of documentation, webinars, asynchronous instructional videos, or other content. Ongoing training and site-specific support can be provided in concert or collaboration with the Museum Database Coordinator.