Product
Ask Joe
Ask Joe lets your users question their own data in their own words. We built it first for a fee-only insurance portal, where a client gets a personal report and can then ask about it without needing the jargon. It fits any product that hands people a document they can't fully read.
The problem
Your product produces something authoritative and slightly opaque: a personal report, a compliance statement, a financial summary, a diagnostic export. Most recipients read the first page, do not fully understand it, and either accept it or ring someone. The value you generated is sitting unused in a PDF, and your team is answering the same five questions about it every week.
What it does
A conversational layer over the output your system already produces. The user asks in plain language. What does this mean for me? Why is this figure higher than last year? What changes if I do X? They get an answer grounded in their own record. It embeds into your existing product as a widget, or runs behind your own interface through an API. And it needs no change to how the professional producing the report works, which is usually the constraint that decides whether a feature like this ever ships.
How it works
The user's actual record and the relevant explanatory material are retrieved first, and the model is required to answer from those rather than from general knowledge. Where the question cannot be answered from what is on file, it says so and offers a handover instead of producing something plausible. In regulated sectors every conversation is logged for review, which is generally the condition of getting the feature approved at all.
How it fits your software
An embeddable widget for web products, or a plain HTTP API if you would rather build the interface yourself. Both come with an admin console that shows what users asked and, more usefully, what went unanswered. For most clients that turns out to be the best product feedback channel they have.
What that means in practice
- Answers grounded in the user's own record, not general knowledge
- No change required to the workflow of whoever produces the report
- A measured refusal path with handover rather than a plausible guess
- Conversation logging for compliance review where the sector requires it
- Typical integration into an existing product: two to four weeks
Built with
- Python
- Node.js
- React
- PostgreSQL
- AWS
The same stack we build client projects on — which is the point.
Questions we get asked
Does it work with our existing reports, or do we have to change them?
It works with what your system already produces. The conversational layer sits on top of the existing output, which is usually the condition of the feature being approved at all — nobody wants to rework a professional's workflow to add a chat box.
What stops it inventing an answer?
It answers from the user's own record and the explanatory material we index, and where a question is not answerable from what is on file it says so and offers a handover. That refusal path is tuned before launch rather than left to chance.
Can we review what it told a client?
Yes. Every conversation is logged and reviewable. In regulated sectors that is usually mandatory, so it is built in rather than added afterwards.
How long does it take to add to an existing product?
Typically two to four weeks, including indexing, the widget, the admin console and a tuning pass against real questions.
Want Ask Joe in your business?
Tell us how you work today. We will say plainly whether this is the right fit, what it would take to adapt, and when it is not worth doing.
Clear scope. Working reviews. An agreed plan for support.