Does this App Belong in my Ecosystem?

Yes? 

No?

Maybe?

All of the above.

But how do we know? We encounter too many scenarios with our clients where they are looking for a cut and dry response that we cannot provide for them. Just like nearly every other question when it comes to apps, accounting and taxation - it depends.

What does the app do?

We all know the phrase - there's an app for that! But what, exactly, is that? Is your app a time tracker, a payroll add-on with time tracking, a POS, a POS with time tracking, an inventory manager, an inventory manger with POS, an inventory manager with POS and time tracking, blah blah blah? There are a million different things that your app could be capable of, and the first thing that you need to know is exactly what the capabilities and limitations are. Once you know what your app can and cannot do, you can decide on the next question.

What is the app's role in the Ecosystem?

Many of us have taken the term 'Appify' and ran with it. Some of us ran the course, and some have gone off-roading... The biggest problem I see are app stacks instead of app systems (no relation to AppStack mobile site builder). Piling one app on top of another on top of another and so one just creates a huge mess. Many times an app will be integrated and later you find out that it is missing a feature, so you get another add on to fill that need and you end up with a million apps that no one can keep track of. There are plenty of awesome ecosystems that involve a strand of apps working together, and knowing each role and result in depth will help you decide which ones qualify as a system and which ones just make a crap pile. 

Stack vs. System
When we are designing an ecosystem for a client, we look at multiple options for each process that requires a solution. A good saying here would be 'if you fail to plan you are planning to fail'. Let's compare two examples of a landscaping company:

A: Implements When I Work with GPS for time, Zen Payroll for processing, and SalesForce for appointments while using QBO for back-end accounting. 

When I Work > Zen Payroll > QB Online < Sales Force

B: Implements Jobber for time/appointments/field management and QBO with payroll for back-end accounting.

Jobber > < QBO/QBOP

(If you are not sure which of these is a stack and which is a system, please send me a private email for a consulting session...)

The moral of the story is that both of these examples fill the need, but they are not created equally. You need to know your end goal and choose the apps that work together effectively to make the most streamlined system.

How much control do you need/want over the data?
I have overheard waaaay to much whining that all app data needs to 'sync seamlessly into QuickBooks' to be perfect. I say NO WAY!!! One of the BIGGEST benefits I see to appification is that you can choose an app based on its ability to feed information into your back-end accounting system. We all have 'that client' that no matter how much we train them, they will always mess up their books. I love that I have platform options so that I can put 'that guy' on the POS that allows me to look at their beautiful reports and post them as journal entries (rather than automatically sending every erroneous transaction into QB for me to clean out). I believe that the best apps are those that give you options on how you retrieve your data.

What does your data look like once it is in the back-end system?
My answer to this: who cares? As long as it is accurate and not redundant, I prefer ONE posting from the app to summarize the information. Most people ask my why I would not want every transaction to come through... Well, if I wanted every transaction spelled out in QuickBooks then why the heck did I buy the app??? Of course the expectations for import will vary depending the goal you are trying to achieve, and if you have completed the proper ecosystem engineering process then you should be able to assess the part quite simply. Just remember that you are looking for a streamlined system, not a redundant stack.

Would you be interested in a course on this subject? 

Tell us on Twitter @PetersonBizSvcs

contact@petersonbusinessservices.com

twitter.com/petersonbizsvcs

facebook.com/petersonbusinessservices

The Pro-Apptive Approach to Working with Developers.

I have been hearing a lot of talk and questions from my peers about apps. What they love and what they hate, but mostly what they wonder... There is always a question of why... Why don't you have this, why does this do that, why does this import, why doesn't that export... In my opinion, many of these whys aren't really whys at all, they are When's. What we really want to know is when will it do this, when will that fixed, when can I use this app the way I want too? Basically, we suck at explaining ourselves to developers. I was given some great opportunities to speak with developers at multiple companies this week. Aside from being able to communicate my ideas to them, I was able to learn how they need to receive information I order for it to have any value to their teams.

They don't know what you're saying because it doesn't make sense.

Draw a picture, compare a competitor, remind them that you don't speak their language. I am constantly reminding developers that I have no idea what they have to do on the back end to make my dream come true, and encourage them to re-direct my thoughts according to technical feasibility. Most of the time when we are trying to explain something we are looking at it from a 1-client view or an 'I want' perspective. The most effective way to validate your suggestion is to prove that your 'want' adds value not just to you, but to the platform as a whole. Paint them a picture not just of the what, but also of the why. The how is up to them.

We give input without implementation experience.

Many times we turn away from a product due to the 'feature lack' that we see in a demo. We may not implement that product because of one little thing that is missing, therefore our only experience is the demo. Once we have made the decision NOT to try a product, we need to accept that since we have absolutely no working experience with the program, we have no place discrediting it's application. For example I wanted to integrate Lettuce for a client but I needed a more robust sales tax module, so I only demoed it. I know of some other industries it would be great in and I would apply it in a heart beat. The fact that I implemented Vend instead of Lettuce does not make Vend a better app, it makes it a better app for that client. We need to quit pretending like every industry should have a shoe box solution and work on becoming educated ecosystem engineers.

When you divorce a vendor, forget the no contact order.

I'm sure ALL of us have had bad experiences with apps... Spending hours fixing things that we can't bill for because it was our dumb@$$ that suggested the implementation. I have divorced many an app (I even took a year off from QBO once), but we need to remember to be civil. You are much better off leaving amicably so that you can keep yourself educated on any new things that may put that app ahead. We need to forgive developers of their past mistakes so that we can take advantage of their future triumphs.

Fool me once, shame on you. Fool me twice, shame on me.

When I demo a product I usually go in super excited about where I want to use it and the clients that I'll put on it. By the end of the demo I generally have a huge paradigm shift and realize that it is not what I thought it was at all. If they fool you once with their sales rep, email, or misleading advertisement, then shame on them for not being clear. I always look at this thankfully with a 'crisis-averted' attitude and throw the app in my toolbox for future use. Now if you choose to implement the product anyway because it's pretty or cheap or whatever, and it turns out not be the right fit, that is YOUR OWN fault. If you have demoed a product thoroughly and asked  all of the right questions then there should be nothing that they told you that you did not verify before implementation. Test Test Test!! It is up to you to be the expert.

What's your opinion? Feel free to post, tweet or email your thoughts on the matter.

contact@petersonbusinessservices.com

twitter.com/petersonbizsvcs

facebook.com/petersonbusinessservices