CRM Requirements Document

2 Introduction
This document is intended to provide a high level view of the key requirements for the new CRM. It is
not:

A complete and/or detailed representation of every requirement for the project

Prescriptive

The intention is to provide enough information for you to put forward a recommendation based on the
best possible fit for our needs. We fully expect to define the detail within the project itself where it can
be based on requirements gathering in-depth planning and use-case development.

It’s important to note that we do not have a preferred system for this project – we are equally at home
with open source and commercial offerings, and do not shy away from bespoke development when it
can be demonstrated to deliver the right benefits. That said, we are conscious of the frequency of
change that a typical CRM will undergo during its lifetime, and would need to be convinced that any
‘from scratch’ bespoke development was capable of not only adapting and growing with us, but also
of being maintained internally by our teams or potentially by other partners in the future.

2.1 Background
We are looking to launch an internal CRM to allow them to better manage a range of disconnected,
often manual contact and enquiry processes. It is also envisaged that the CRM be able to integrate
with other systems, both current and future, to maximise data sharing and reporting.

Due to our nature as a levy-funded industry body, we have absolute requirements to be able to
demonstrate the value we provide. The CRM will be a crucial tool in being able to efficiently manage
client contact, communication and reporting.
3 Project Overview
3.1 Key Technical Objectives
The key objectives of this project are to:

Provide a single view of all contact and business information to all of users, both internal and
remote;
Provide extensive reporting and management capabilities of activities and interactions with
contacts;
Provide access to partners e.g. Seafood Scotland, 3rd party marketing companies under contract;
Provide a centralised system that can integrate with other systems in the future, bringing in and
sharing back data;
Provide a system that can be easily modified and grown in the future without requiring extensive re-
configuration or development.

These objectives can and will be after further developed during the project scoping stage once a
tender is accepted.

3.2 Expectations
We expect that any solution proposed to us will:

Easy to use, intuitive, user friendly

Have a clearly identified support and maintenance structure;
Have a clearly identified roadmap for future updates and development;
Come with the ability to be extended, modified and integrated in the future without reliance on a
single company or team;
Have clearly identified licensing model and defined ownership rights regarding any custom
development;
Come with fully bespoke training manuals and structured training sessions for various levels of
staff;
Come with detailed technical and functional specifications;
Work with our internal hosting infrastructure, or have a compelling and just reason to be hosted
independently.
4 Key Requirements
4.1 Software and Technology
We are looking for a new CRM. The proposed solution should be:

Flexible enough at time of configuration to allow for customisation to exact requirements;

Adaptable enough to allow changes to that configuration in the future;
Able to be delivered against future requirements;
Able to deliver continued return on investment through an identifiable development roadmap as well
as additional modules and features.

It is envisaged that, due to the project timeframe and the on-going support requirements (detailed
below), an off-the-shelf solution would be most suitable; however we are open to any potential
solution that delivers against the requirements, and every proposal will be judged according to its
relative merits.

The solution should also be adaptable enough to allow for multiple points of integration with existing
and new systems, not all of which will be hosted close to, or built on the same software stack as, the
new CRM. We have detailed our known integration requirements later in this document.

4.2 Planning and Process

Whilst our current processes – those being replaced by the new CRM – are well known, we are fully
accepting that it is inefficient and often detrimental to be too specific with requirements at this stage.
With that in mind, we are looking to source a system that is as adaptable as possible to our current
and future needs, and a supplier who can demonstrate the in-depth knowledge of their proposed
solution required to ensure the best possible deployment, backed up by a project process that means
we’ll be able to work collaboratively to research, define and agree the final requirements and
deliverables.

We do not see this project as an ‘out of the box’ delivery, and your response should allow for
adequate requirements gathering and confirmation of scope.

4.3 Data Management

As a non-departmental public body (as well as a responsible organisation), we have an obligation to
ensure that the data we collect and store on our partners, stakeholders and contacts is done so
according to legislation and best practice.
With that in mind, any solution you propose must be compliant with UK data protection laws. We
would require you to confirm the rule and regulations that would be applicable in this instance, but
generally speaking we would expect that:

All data collected and stored is done so on servers based in the United Kingdom;
All data processed, analysed or shared in any way with any centralised systems does not leave the
boundaries of the United Kingdom, directly or by an intermediary partner;
The system(s) proposed have been subjected to robust, current and proven penetration and
security testing to minimise as much as possible the risk of intrusion.

A great amount of emphasis is required when it comes to Terms of Use for the data we’re collecting.
We need to be able to display evidence when dealing with Stakeholders, specifically external
communications like mailshotting.

4.4 Training & Supporting Documentation

At an absolute minimum, we require:

Full project documentation, including database and entity relationship diagrams;

Full training manual, bespoke to the project configuration;
Full training manual, bespoke for the end user (not IT staff to include videos where required);
Full on-site training at our Grimsby and Edinburgh offices for multiple end users;
Full on-site training at our Grimsby offices for a ‘train the trainer’ session;
Full on-site technical overview, training and handover for our IS team;
Detailed functional and technical specifications detailing the configuration of the project
deliverables.

It is envisaged that typical day to day maintenance and modifications (such as adding new fields to
customer records) will be carried out by our internal IS team; as such, the relevant training and
documentation is essential to ensure that such work is possible without putting the solution at risk.

4.5 Future-proof
To us, future-proofing takes two key forms:

1. The ability for any system we invest in to adapt and change without requiring a fundamental re-
write. In the context of a CRM, this would include:
a. Adding additional reporting capabilities
b. Adding and changing the fields and data stored against a record
c. Being able to integrate with external data sources and systems in the future
d. Being able to add new record types and relationships
e. Flexibility to add other modules that will rely on the core CRM system.
2. The ability to maintain the system internally and/or with a partner other than those who delivered
the project for us. This is purely to ensure that we are not dependent on a single supplier.

Any system you propose should be able to demonstrate how the above requirements can be met.

4.6 Ongoing Support and Maintenance

As part for this tender process we expect a minimum of 12 months support and maintenance for the
delivered system.

This will need to include:

Support on software upgrades throughout the period
further customisation to existing systems, which are deemed not to be additional functionality
Support with work flow, GUI and reporting systems
Technical advice to IT team
5 Outlined Technical Requirements
5.1 The System
The new CRM will replace a largely disconnected set of systems built in tools such as Excel and
Access; inefficient at the best of times but made more so by the fact that we are spread across
multiple offices and have many team members who work remotely.

Because this is a digitisation of existing processes, it’s important that – whilst logical and efficient
process changes will be accepted – the underlying concepts and way of working that we currently use
do not change: Any proposed solution should be adaptable to specific workflows rather than dictating
data organisation and user journeys.

We have invested heavily in our internal infrastructure and would prefer a system that can be hosted
within our Grimsby office; however we are open to alternative suggestions where the benefits are
clearly demonstrated.

We have detailed each of our key functional requirements below.

5.1.1 General Requirements

The following general requirements should be considered:

The ability to archive information without deletion, to allow for a clean ‘live’ dataset whilst
maintaining historical reporting and data access;
The ability to maintain versions of records, with auditing, workflow and roll-back as appropriate;
The ability to record activity against individual users for auditing and process;
The ability to ‘soft delete’ data – removing it from view without actually removing the record from the
database;
The ability to ‘hard delete’ – as required, and by specific users only, the ability to permanently and
cleanly remove data from the system. We would be interested to see how such deletion is
managed from a reporting point of view (i.e., does data become anonymised and summarised
or simply deleted?);
The ability to accurately control data access, workflow and editorial control based on user
permissions, as fed from Active Directory.

5.1.2 Authentication
We maintain an Active Directory server, and any solution should integrate completely with this,
allowing users to authenticate against their central details. It is envisaged that Active Directory will
also maintain user permissions and active status.
5.1.3 Permission led visibility
We may require that Seafood Scotland (and potentially other partners) have access to our new CRM
and the functionality it delivers, but only access their own information. Similarly, whilst we would
maintain complete data access, it should be very clear in all aspects of data access when we are
accessing our own data and that of Seafood Scotland (or any other partner that we include in the
future).

The system should be able to allow multiple partners to maintain complete operational independence
on the CRM (relating to their data access) and for to be able to selectively access or deny access to
that data by our own reports and staff as required.

This does not mean that specific Terms of Use details cannot be shared with our partners.

5.1.4 Taxonomy
Taxonomy will play a large part in our new CRM, allowing us to accurately categorise and organise
our data. We would require not only the ability to add new parents and child to any taxonomy
delivered at launch, but also add new taxonomies in the future, with the ability to easily update any
and all records to make use of that new taxonomy.

Such taxonomy should also then be available within any reports that the CRM can produce, allowing
us to continuously adapt and improve our categorisation and data segmentation as the CRM
develops.

Below is a list of areas that will require this facility, but this is by no means an exhaustive list:
Contact job roles
Contact business sector
Enquiry type
Risk rating
Enquiry urgency
Business type
Sub-business type (based around site)
Levy payer

5.2 Hosting
Whilst we would prefer an internally hosted system, we are open to recommendations around cloud-
based solutions. We are equally open to subscription-based models.
For each option you intend to propose, we would require a clear demonstration of how your solution
would deal with connectivity outages, SLAs, upgrades, custom development, the ability to refuse
upgrades to new versions (when proposing a SaaS model), and support & maintenance.

A staging environment will be required for pre and post deployment of the system. This is to ensure
that future developments can be tested without potentially corrupting the main system. This will allow
modules to be designed, tested, used and upgraded.

5.3 Users
We currently have between 80 and 100 users who would require access to the system at any given
time. This should change moderately over time, and we would prefer a system that allowed us
maximum flexibility over our user licensing.

5.4 Email Marketing

We require that the new CRM be able to generate detailed and highly targeted e-mailshots, and to
manage the subscription preferences around those mailshots.

We require the ability for third parties – such as our marketing partners – to be able to generate and
report on mailshots.

Full tracking of any emails sent is vital to monitor such things as bounce rate, open and read rates as
well as click-through. The ability to categorise and filter respondees based on their click-through and
reads will be beneficial to allow for more targeted emailing in the future.

Recipients should be able to manage their preferences, including the ability to subscribe to new
mailing lists, ideally from embeddable forms that we can then include on our website and other
external online presences. We should be able to retain contact with contacts for key service
information and manage multiple lists, from which contacts can remove themselves from one, some
or all without hassle.

Reporting on email campaigns is essential, including but not limited to:

Viewing numbers sent by month over a given time;

Viewing comparative success rates in terms of open and click-through;
Reporting on bounces and un-subscriptions.

The new CRM should enable users to modify email templates and content to suit their requirements.
5.5 Terms of Use
Within the new CRM, users will be categorised as varying types of business and end user, each of
which having a different set of terms and conditions regarding how they may or may not be contacted
or their details used within company and our partners.

Additionally, users will be able to manage their own contact settings, such as contact and marketing
preferences; both at time of sign-up and during contact from a member of the our team.

It’s therefore vital that a terms of use system be built into the CRM to allow us easily assign different
terms of service to each user type; and to manage individual preferences ongoing. It’s also vital that
the rules around these settings are honoured in every area of the CRM, for example to ensure that a
registered user is not contacted for marketing purposes when they have requested not to be.

5.6 Data Types

Our new CRM is intended to manage several data types, detailed below; however this list is not
exhaustive and we would expect to confirm all requirements around data and relationships with the
successful supplier through a process of requirements gathering and definition.

5.6.1 Stakeholders
Anyone we interact with. Can be an individual, organisation and/or business. “Stakeholder” is the
generic term we use for capturing all our external interactions/relations.

5.6.2 Businesses
Businesses we support within the industry. These can vary from individual fishermen through to multi-
site, multinational corporations. They can also include trade and industry representative associations,
government departments and agencies, newspapers/newspaper groups etc. They may be UK or
internationally based. They will contain typical information: address (es), contact details etc., as well
as data specific to us. The data we collect about a business will change over time.
5.6.3 Contacts
Contacts are wide reaching, classed as individuals in any capacity within our CRM. They can be
attached to a business or stakeholder as an employee or associated third party (such as a marketing
agent from a third party agency who is the primary contact for a business we support); they could be
the details of an individual who has logged an enquiry with us but is not yet associated with, or
identified as, belonging to a business. Can be singular or repeat contacts.
The breadth of our contact database will only ever grow, and your proposed system must be able to
demonstrate how new fields and relationships can be maintained to allow this growth, and deliver
reporting capabilities accordingly.
5.7 Diarising visits and meetings
By using technically we require the CRM system to be the central repository for holding information on
visitation to stakeholders. Users need to ability to track/trace visitations made by any/all members of
They will require either one-way or two-way communication between the CRM and MS
Exchange/Outlook to all users seamless updates with the CRM system.

5.7.1 Enquiries (Ticket System)

Enquiries cover any interaction we have with a contact, be it email, phone or in person. Every enquiry
should effectively present an auditable trail of communications and actions, allowing us to review and
respond to every client query in the most effective manner, as well as reporting on both the interaction
and the result.

5.7.2 Future Types

Whilst not required for this development, we would foresee the following additional record types being
included in the future. Please note, these may or may not be developed as external systems, but the
data produced will need to be reported on within the CRM regardless.
Levy Information (Levy DB) (Processing companies)
Project Management
Training course data (fisherman and vessels) which includes NI numbers
Marine Services auditing and tracking
Internal Management & Reporting system
RFS / Responsible Fishing Scheme (revolves around fishing vessels)

5.8 Database / Relationship Requirements

The way that we originate and handle data can be somewhat convoluted, with the possibility for an
initially anonymous enquiry (new contact) later turn into a stakeholder, or be revealed as already part
of an existing stakeholder.

It’s possible that contacts can be associated with multiple stakeholders; that stakeholders will have
multiple addresses; even that a contact might have a different role at the same stakeholder depending
on which office they are associated with.

It’s possible that contacts will make frequent changes between stakeholders within the industry, and
that several contacts from the same company may register or place an enquiry with us without
knowing that others are doing so.
What happens when a user requests their information is permanently deleted; when a contact is
registered as the primary contact by one user and secondary by another user?

Such situations are a prime source of duplicated or incorrect data, and one of the primary objectives
of the new CRM is to remove, as much as possible, the potential for unclean information. It’s therefore
vital that your proposed solution be able to accurately manage data relationships.

5.8.1 Cleansing
Because a CRM is only as effective as the quality of data it has to play with, we frequently run our
data through external cleansing partners in order to ensure we have complete data such as phone
numbers and addresses, as well as keeping our overall contact relationship up to date.

From experience, exporting and re-importing our data from systems can prove problematic and time-
consuming, often requiring effective data freezes on the live system which such cleansing is taking
place. We would welcome your thoughts on how we can either:

Efficiently export and re-import data, with appropriate validation, without risking the integrity of the
resulting information or requiring downtime;
Give our chosen cleansing partners a view on the data they require directly within the CRM without
exposing any non-related functionality or information.

5.9 Browser Support

Because of the diversity of our potential user base, both internally and remotely, and the need to allow
access to the CRM by users outside of our internal software policies, the CRM should be fully
operational in as many browsers and on as many operating systems and devices as possible.

As a minimum, we would expect:

Desktop Applications
o Latest Chrome and Chromium
o Latest Firefox
o I.E 9 and above
o Safari 6.0
o
Mobile & Tablet
o iOS7 Safari
o iOS7 Third Party Browsers (Chrome and Firefox)
o Android 4.0 Chrome and default browsers and above
6 Functional Requirements
6.1 Enquiry Log (Ticketing System)
The CRM will play a crucial part in managing our day to day contact with the industry and our
stakeholders. As such, every communication and enquiry should be automatically logged in the CRM,
stored against the individual contact(s) and company(s) involved and the activity being undertaken.

Every communication or enquiry should work much like a ticketing system, whereby each instance is
automatically assigned a unique reference which can then be used to transparently group each email
and call log against a specific enquiry. All email replies by users and contacts should be picked up by
the CRM using this method.

A large part of what we offer to our clients is industry-wide knowledge and support. As part of this
remit, we are frequently contacted by individual with specific technical questions e.g. a fisherman
asking about catch, storage and supply, to which we respond accordingly, frequently over multiple
messages and calls from both sides.

It is essential that every enquiry, from initial contact (be it email or phone) is logged and grouped for
audit purposes. Every email to and from the client should be associated with the initial enquiry, and
multiple enquiries should be able to be maintained with the client contact at the same time with
automated identification as to the correct enquiry to log against.

6.2 Value For Money Index

In line with our need to demonstrate value both to our clients and our stakeholders, we assign a
standard Value for Money (VFM) value to each enquiry, allowing us to monitor the value of the advice,
support and guidance provided.

In the future, this functionality will potentially be integrated with other parts of the CRM or even
external systems, so it should be deployed as a standalone module that integrates into the ticketing
system. We expect to work through the practicalities of this with the successful provider during the
project’s scoping stage.

This VFM number is calculated externally and the ability to update an enquiry with this data, possibly
through the integration of an external system, is essential.

6.3 Contact Management

Core to every interaction on the new CRM will be our contacts database, made up of individuals, roles
and businesses.
Whilst very much subject to definition and confirmation, the following rules and requirements apply:

Businesses should exist as a single overarching entity, with capabilities to detect duplication at time
of entry;
those businesses can have multiple offices, addresses or sub-companies;
multiple contacts can be assigned to one or more businesses, and to offices or sub-companies
within;
Contacts can maintain one or more roles, potentially specific to a particular business or office;
Contacts will move between businesses, offices or roles;
De-duplication of business, address and contact information is essential and a key KPI of the new
CRM;
multiple ‘key contacts’ will exist within a business depending on the type of relationship required –
may maintain key contacts for several different teams or departments;
There is a potential requirement for workflow and approval requirements when creating or editing
business and/or contact information – this should be able to be defined at user level and within a
workflow manager;
It will not always be possible to collect all ‘required’ information at time of entry – the CRM should
be capable of allowing partial entry and include a mechanism for that to be flagged and dealt with
appropriately;
There should be the ability to tag enquiries to existing businesses and contacts, and to create a
new business or contact as appropriate at the time of enquiry;
Contacts will potentially be allocated to specific teams or partners, not all of whom will be able to
access or interact with the data from another team or partner. It would be interesting to hear about
how potential duplication would be dealt with in this instance.

Within these listed requirements, we are keen to realise operational efficiency and would look to work
with the successful supplier to ensure that we are finding the right balance between tightly defined
rules and the ability of users to actually perform their desired tasks.

6.4 Reporting
The new CRM should be capable of delivering both pre-defined and bespoke reports, ideally on any
type of data held within the system. Aspirationally, the CRM will allow appropriated trained users to
simply drag and drop fields from the available dataset, with both spreadsheet and graphical reports
generated quickly and easily; at the very least, it should be reasonably simple for trained internal
administrators with a solid grasp of the underlying technology to create reports for end users on
request.

We would like to see both detailed individual reports and the ability to create default and user-defined
dashboard reports, showing high level information which can then be clicked through to the individual
item. Such views are essential to provide us with the capability to keep an eye on efficiency, reactivity
and ultimately accountability.
Reporting is a key part of ensuring we can demonstrate the value we return to the industry,
and is therefore a major consideration regarding the choice of CRM solution.

6.4.1 Stakeholder / Individual Reporting

Individual users will have reporting requirements specific to their function. Ideally, these reports will be
user-defined and saved for repeated access; if required, it could be that they are defined and
configured at system build with additional reporting requiring advanced training and/or the use of
support and maintenance allotted hours.

Typical reports for this would be:

Recent activity for the last email campaign

Enquiries open, closed, initiated over the last xx days
Comparative performance ratios (value added reports; enquiries dealt with; contacts made etc)

It is envisaged that the true nature of reporting and the value it can add to the investment in the new
CRM will ultimately be realised as the product is more defined and relationships identified. This will
happen over time as future developments are designed and implemented; as such, reporting
capabilities should form an important part of the project requirements gathering exercise.

6.4.2 Standard Reporting

The system will also require more standardised reporting, such as:

The ability to view related data from a contact, such as the number of enquiries made by that
contact, or others within the same business;
The ability to see related tags and results from records;

The new CRM should be able to quickly cross-reference related data to allow users to logically find
other information in accordance with the relationships defined.

6.4.3 External Reporting

Aspirationally, the CRM will be able to present data to the outside world, for example to display
efficiency reports onto the website or provide a bespoke view of interactions and results to partners,
stakeholders or even individual businesses.
This is not a fundamental requirement, but would be potentially highly beneficial to our future
accountability and as such, we would welcome any suggestions on how this may be achieved, if not
for launch then in the future.

6.5 Integration
6.5.1 Internal Systems
We expect at an absolute minimum for the new CRM to integrate with:

Active Directory – to deliver full user access from authentication to profile images, email addresses
and permissions

Outlook / MS Office / Exchange Server (2010 and above) – full integration of calendar and email to
pick up on all emails sent to and received from clients, synchronise diary entries and events from the
CRM and individual user calendars etc.

6.5.2 Third Party Systems

We maintain, or are in the process of commissioning, several external systems all of which will play a
vital role in our overall service offering. Our ideal is that in time some of these systems could be
delivered directly within the new CRM solution, although none are in the scope of this initial project.
To that end any system which cannot easily be integrated with other systems will score poorly against
those which make such connectivity possible. For clarity and further guidance, we have included an
overview of our currently planned integration of systems in Appendix 1.

Regardless of these systems being potentially developed within this project, there will always be the
requirement be able to integrate other systems into the CRM. Sometimes, it will simply be to provide a
click-out from the CRM to the other system, which may include some level of single sign-on or shared
authentication. Other times, it could be that the CRM captures information from, or shares it with, a
third party system, either LIVE or on a timed basis.

The exact requirements are not known and will always be subject to change as we brings new
systems and services online to react to the needs of our partners and stakeholders. It’s therefore
essential that any CRM we put in place is as flexible as possible when it comes to integrating and
sharing information with other systems.
Regarding this requirement, we are open to any method which is secure, robust and capable of
maintaining data integrity: Systems which can be extended in a modular fashion (and for which
integration modules are widely available or easily created) would be ideal; a standards-based API
would allow similar flexibility. We are also open to such practices as direct database connectivity if
said solution can be demonstrated to be secure and reliable.
7 Project Delivery Overview
Please confirm your approach to each of the below.

7.1 Project Commencement

Detailed meetings and discussions to confirm high level requirements, any questions we have
following the tender process, timeline, roles and responsibilities and contractual items.

We would like to confirm a high level scope, and any resulting cost, scope or time amendments
required based on that, as quickly as possible regarding this project. Unless our requirements
fundamentally change, we do not expect there to be any change of cost, scope or time from your
submitted proposal.

7.2 Requirements Gathering and Scope Confirmation

We understand that the detail around our requirements is missing from this document – this is
intentional as we would very much look to the successful supplier to guide us on best practise in
terms of working methods, data relationship management and ultimately the exact configuration of the
chosen CRM solution.

With that in mind, we require extensive requirements gathering and analysis take place through
research and user workshops to ensure that our requirements are fully understood, enabling a
detailed and suitable scope to be put together.

7.3 Detailed Delivery Plan

Because of the time pressures of this project, we would require a detailed project timeline be
maintained, capturing not just your development time but also the requirements on our time. Given
the sometimes busy schedules our staff maintain, it’s vital that we know when our time will be
required for meetings, review and feedback; and that we always have an up to date timeline from
which we can report and monitor progress.

7.4 Specifications
We will require both functional and technical specifications for this project, as well as technical and
user training manuals written specifically for our configuration.

The specifications are intended for us to agree that configuration before the commencement of build,
and to test against once build has been delivered back to us; the technical specification is intended to
capture the specifics around that configuration so that we may support the system in the future
without dependence on any one supplier.
7.5 User Acceptance Testing
We believe in thorough and frequent testing, and will make available to you the resources to conduct
testing at any time within the project. At the very least, we would expect to conduct extensive user
acceptance testing following the completion of development and configuration, but we would also like
to test throughout the project if possible.
8 Your Response
In putting your response together, we would like you to demonstrate your response to the below.
Please note, these requirements are in addition to any requirements from our tender documentation
as a whole.

8.1 Delivery Process

Please define the process you will take, from kick-off meeting to deployment, to ensure that you fully
understand our requirements and how you will deploy the your solution to meet those requirements.

In particular, we would like to see how you will deliver a system capable of growth with your chosen
solution, ideally through demonstration of proof of concept delivery resulting in best practice
configuration within the software.

8.2 Overview of the system

Please provide an overview of your proposed solution, including heritage, current usage and USPs
compared with other solutions in reference to our requirement.

8.3 Practical Demonstration

Whilst it is not expected that you provide a demonstration bespoke to our requirements, it would be
beneficial for us to receive a demonstration of the system you intend to deliver and how configuration
and options can be tailored to suit our requirements. This can be in the form of an in-person
demonstration, or a video – we are flexible on this matter.

8.4 Clearly detailed user licensing costs

Where you are proposing a solution with per-seat cost, we require a detailed breakdown of how such
costs accumulate, and where there are opportunities to reduce such costs, for example through bulk
purchasing.

In all circumstances, please explicitly detail any user limitations and associated costs, including if
accounts such as developer and admin accounts are included in such limitations; please also confirm
if any access to staging or development environments provided as part of your solution are included
in the total user count.

8.5 Explanation of workflow configuration and user configuration

Given the nature of our user requirements, especially around the potential for partner access and
auditing, we would like to see how your proposed solution can offer us flexible workflow, data access
and editorial rules.
Please confirm that your solution can work solidly with Active Directory, and list any assumptions or
limitations.

8.6 Explanation of records configuration and relationship management

Please explain how your proposed solution creates, manages and deals with updates to record types.
We would like to see how different record types can be inter-linked, and how such linking can be
monitored, edited and adapted as our requirements change in the future.
Of significant interest here is the work involved in adding new fields and relationships, as well as the
impact of such an action.

8.7 Details of ability for internal management and configuration

Linked with the above, please explain the level to which changes and updates can be managed
internally, and to what level a typical deployment of your solution might require on-going support and
maintenance.
8.8 Details of support and maintenance
Please detail your suggested (or required) support and maintenance package for this contract,
bearing in mind that we require at least 12 months suitable support. Please detail the on-going costs
of any licensing for updates, the potential cost (if any) of applying those updates, and if the software
you propose is available to us only on a licensed basis.

8.9 Details of training material delivery

Please detail the level and range of training material along with delivery mechanisms; ranging from
bespoke installation, train-the-trainer, through to frontline users.

8.10 Details of integration capabilities

Please detail the ability for your proposed solution to integrate with other systems, and the limitations
and assumptions around this. Of particular interest is if your solution comes with cost-effective (or
free) modular plugins to allow integration with other systems, or a standards-based API, or if
integration is only possible through expensive, proprietary development or software purchase.

8.11 Details of the emailing capabilities

Please detail the capabilities of your solution to send and monitor emails, reporting on the user
activities to those emails such as bounce detection, open and read reporting, and click-through.
Please highlight the process through which a user may set up an email campaign, from content
creation to list selection and sending, and the reporting available on the back of that activity.
8.12 Details of how data relationships are maintained over time
Please detail how your proposed solution deals with an organic dataset, where (for example) contacts
may include enquiries and other records on our system spanning multiple years and several
businesses.

8.13 Details of how data is archived, deleted and consequently reported upon
Please detail how your solution deals with archiving data, and what happens to any reports, figures or
larger datasets that include data which is consequently archived or permanently deleted for any
reason (intentionally).

8.14 Overview of any technical, infrastructure or browser requirements

If your solution has any specific requirements, such as a browser plugin or incompatibility with certain
operating systems, please list them.

8.15 Detailed list of any omissions or assumptions

Against our listed requirements, please detail any assumptions you have made as to the depth of that
requirement and any areas that you know you cannot deliver against. Such examples will often lie
around aged data handling, Outlook integration and third party integration, where it is simply not
always possible to deliver everything we request.
By understanding up-front the potential pitfalls and limitations of any solution, we can be sure to weigh
them up properly against the benefits of that system to ensure that we ultimately settle on the best
possible solution for our needs.
9 Appendix 1 – List of Future Integration
This is not a finished, definitive list. Though this does show the expected systems at this current time.

Levy System (Additional out-of-scope projects – but need to be aware)

o Accounting and auditing tool
o Offline access required
o Separate Budget – Not yet agreed
Training Database (Additional out-of-scope projects – but need to be aware)
o Courses records checking
o NI number stored
o User access required
o Training Providers access required
Project Management
o Using Sharepoint – to be built in/around CRM
o Link contacts/businesses to projects
o Document Repository
RFS
o Lookup facility for vessels, skippers and businesses