With an ever increasing choice of apps available for accountants, it can be hard to know how to begin in your search.

We have developed a system for doing and documenting App Research to use in making informed recommendations.

Research is much more purposeful when you already have a clearly defined use-case, which is why proper scoping is incredibly important prior to commencing the research phase.

Once you have your defined use case, it’s then important to document your App Research so that you can come back to it and compare solutions, and potentially use it again in the future. 

Here’s how to do and document your requirements-driven app research

Prepare your research system

This example using ClickUp is easy to create, edit, add to, and collaborate on, which allows other people to contribute to the requirements if you’re working in a team. Here a ‘List’ is used for the requirements, a ‘task’ is used for each requirement area, and ‘sub-tasks’ are used for breaking down the overall task element. Status is used for defining the type of requirement (essential or desirable).

For each app that makes it onto the initial shortlist for investigation, you will need to replicate at least the feature checkbox and notes columns, and name them relating to the app being researched.

ClickUp is not built specifically for this, but it’s flexible setup options make is well suited to this, and at a low-cost.

List & categorise requirements

Make a list of the requirements, and categorise them by whether they are essential or desirable. You will use this to later relate your research back to the requirements.

Provide context

Each of the requirements needs to be well defined, so that if somebody else were to pick it up without prior knowledge, the requirement would be easy to understand. Providing explanations of the context behind the requirement will make this possible.

Structure your list

Structure your list of requirements by breaking down the overall requirement area into smaller elements. This is useful for keyword searches in the research process, as well as making it easier to find and compare feature analysis.

The purpose of this is simply to give you a recorded scope of features you’re looking for, to help you assess and evaluate software.

It also provides a place for you to record information about each software.

Makes it accessible

Accessibility means that anyone that might want to access it in your firm in the future can do so.

All information gleaned through research, including email communications should go into a working document or collaboration tool (as above), saved with shared access, and structured consistently so it is easy to navigate. It is likely that a combination of both a document system (i.e. Google Drive) and a collaboration tool (i.e. ClickUp) would be used, but both can be linked, and email conversations stored against particular features, or the overall

This means that you should avoid documenting the research solely in the body of an email that is either sent to the prospect or client, or to another member of staff. Emails are often not accessible by multiple staff, and information might be spread over multiple emails which makes it harder to consolidate. If the staff member leaves, the knowledge distributed across email will be harder to access and use again.

Any research presented to the client should be done in the form of a research report. A report helps provide value to the content, something that is less achievable within an email.

Makes it reusable

Reusable means that anyone that is accessing the research can understand the use-case behind the research, so they understand the context in which it was created. If you follow the tips in this blog then your research will be reusable.


The App Advisory Approach to Research and Documentation

This approach can be used for each of apps that have passed the initial shortlisting stage.

Pre-Documentation – Initial Shortlisting

At this stage you’re not documenting anything except for the names of the apps that you want to investigate as part of your initial shortlist. As a reminder of how to approach that stage:

Ask for help

What you’ll probably want to do at this point is look for shortcuts. And of course the easiest thing to do is to ask someone else for a recommendation, perhaps on a Facebook group.

Be careful here, because recommendations are only useful if the recommender has understood your requirements. If they haven’t then you could get sidetracked and waste time.

If you submit a FREE support query to us then we will always ask for detailed requirements.

Search for Apps

Search for apps using our App Directory or App Stack tool. When you’re using the tool you’ll be able to filter to get to a shortlist of potentially relevant apps.

We have filters including:

  • Sector
  • Category
  • Integrations (accounting and non-accounting)

We also have a filter for price, but I would not recommend using this immediately, this is something to consider after assessing features.


Initial Research – Checkbox documentation + some notes/links

At this stage you will begin using the checkbox feature to quickly record any indication that a feature is present in the software, as well as recording any notes/links where you found the information. Here’s a reminder of how to approach that:

Search for App Information

The aim of this element is to further shorten the shortlist, by reviewing key information, including key features, without spending extensive time on research. This can be done using a combination of the app’s directory listing, website, and help centre articles.

The app directory listing will provide a quick overview of the product, key info, and key features. Aside from functionality it’s important to review things like support channels and availability, plus implementation support.

Usually apps are reasonably good at presenting high level features on their main website as well. However for some apps it is their strategy not to show these in much detail so that you have to book in a demo or take out a trial – something to move you into their sales pipeline. You might have to try key-phrase searches in their help centre or blogs to identify some features. If you can’t find information about a feature, it’s reasonable to presume it doesn’t exist.

Compare Apps

Use our comparison tool to compare features of apps.

At the end of this stage you will be able to compare the checks for each app to help you decide which to evaluate. We would suggest evaluating the top 3 as a starting point.


Evaluation Stage

At this stage you’re committing yourself to evaluate features and functionality in detail. This is going to be more time-intensive. In this stage you are going to be using the other features of the documentation system, including:

  1. Does it have a workaround – Evaluation Only
    It’s unlikely that the solutions you consider will meet your exact requirements in full, but workarounds can often be good compromises that are worth considering. These might not be obvious until investigating in more detail, such as through a demonstration or trial.
  2. Notes on the feature (text box), including links to source information
    This is used throughout the research process, but considerably more during the evaluation stage.
  3. Feature image, help centre article, and feature video – Final Shortlisting and Evaluation
    These are helpful to be able to quickly return to the information that helped you to be able to decide why the feature got a tick, or not. It also helps others to reach that same conclusion, and will make it easier to compare for evaluation purposes.
  4. How good is the feature (rating) – Evaluation Only
    This is completed when you’re evaluating the feature in more detail. You only need to do this for apps that you’re reviewing in more detail (top 3 from the initial checkbox research).

In addition to more in depth research of the app’s Help Centre, at this stage you would also:

Get a Demo

Reach out to the app and arrange a demo, providing the salesperson with your list of requirements so they understand what you want to cover. This will typically last between 30 minutes and 2 hours.

If they skirt around your requirements then it’s likely the software won’t meet them as you want, but there may be some compromises or workarounds, so be open to those – it’s unlikely the software will do everything you want, in exactly the way you want to do it.

Take out a trial

If you’re happy with what you see and hear, take out a trial and play around with the software to test out the functionality and integrations. Then go back with any questions you might have.


What next?

Once you’ve got your research and evaluation documented then you’re ready to present your findings as part of a report.

Get started with one of our customisable, white-labelled, App Stack Report templates.

  • Create your App Stack
  • Choose your Report Template from 4 options, differing in complexity
  • Add your branding, and your client’s 
  • Customise the report content 
  • Monetise your App Research

Checkout this example report.

Create a free account

Leave a Reply