11–20 of 34 posts
How does this compare to Retool?
In my experience, many teams have already established flows and homebrew solutions that are working "just fine". With your solution in place, how do you convince these type of customers to migrate? Why they should spend time on integrating with your application that offers just fancy manual triage of tasks? You list numerous use-cases which I would say are mission critical (onboarding of customers, triage of risk transactions, etc.) and your solution doesn't really help the operators (=humans) to resolve the problem faster. In my experience, the operators often times have to deal with so called "alarm/alert fatigue", how does your solution helps companies do more with less?
Looks brilliant!! Have signed up with https://aidem.network as this is perfect for us and potential my sister company. Was going to use Orchestra by B12 but this is a much better package for us + no code
Looks brilliant!! Have signed up with https://aidem.network as this is perfect for us and potential my sister company. Was going to use Orchestra by B12 but this is a much better package for us + no code
Thanks for signing up! We tried reaching out but the email bounced. Can you message me directly at nick flowdash com?
How does this compare to Retool?
Seems like it provides a business logic backend, which Retool does not, and less customizability on the frontend. You could conceivably use Retool to build a frontend to a backend powered here. e.g. in their demo video instead of a Rails app, you could use Retool for the GUI and API calls instead.
Retool can do pretty much everything this thing can do and more. I'm definitely keeping my Retool instance.
How does this compare to Retool?
Congratulations on the launch. You are definitely tackling an interesting problem, but I will play a devil's advocate here, because I've spent some time researching similar use-cases for dealing mainly with triage of security & abuse incidents. From the demo, the application seems to be pretty basic, you accept an input and allow users to set actions, take actions, and move tasks through the tasks' life-cycle. You ar…
> but is that really the real added value of your solution for a customer?
It's two-fold: 1/ On the engineering side, there's immediate value in freeing up time that can be used elsewhere. Also, because we've built a lot of the features operations teams would need as they scale (e.g. task assignment, analytics, common integrations), we expect a lot less "feature requests" to make their way back to engineering. 2/ Operators are arguably benefitting even more from Flowdash, as they're able to update how they work on their own. Many operators we've chatted with expressed frustrations from being unable to change their workflow, or having to wait 6+ months for engineering to make simple updates to their tools.
> how do you convince these type of customers to migrate?
Short answer is, it depends. If the current process works well, has no pain points, and requires no new features for the foreseeable future -- why change? However, if business is evolving (or team is growing), that's where the maintenance cost of these tools starts to grow quickly. Companies may find themselves building basic task assignment at first. Then, some sort of audit log for debugging issues. Before you know, you need notes for team collaboration. The team grows a bit more and you have to build analytics, and so on... Our goal is to partner with companies throughout their growth with the features they'll need to keep the business running efficiently.
> your solution doesn't really help the operators (=humans) to resolve the problem faster
In the demo video, it's not immediately clear how we help operators resolve their problem faster as the API simply talks back to the core application. However, actions can be setup to automate many of the more mundane tasks that operators have to do (e.g. sending email, triggering alerts, generate documents).
> so called "alarm/alert fatigue", how does your solution helps companies do more with less?
Alert fatigue is real, I'm glad you brought that up. I know it's cliché to say we're the one tool that hopes to bring all the others in a single place... but that's what we're trying to do. For operators, "Work" can originate from many places such as email, slack alerts, another person in the organisation, and so on. Keeping track of all those places makes it hard to be efficient, and also causes things to fall through the cracks. By making it easy to push data into Flowdash from various sources, we want to become the single place where operators have to work from. There's a lot of work to get to that ideal, but that's the vision :)