Types of projects we do
Our conversation agents are automated, "intelligent" chatbots; intelligent, in the sense that they can derive some meaning from the text written by the user and give an appropriate response. Many basic chatbots will
expect specific phrases to answer something. For example, "Hello", to start a conversation, whereas our agents use something called NLP (Natural Language Processing) to allow for variations on a theme, so to start a conversation,
our agents can understand not only "Hello", but also "Good morning", "Hi" and "Good afternoon".
That same logic applies throughout the agent design, and we can use it to obtain information from the user, or to answer back requested information, for example, by querying an external database. We are even capable of
having the agent take actions on the user's behalf, like making a reservation, calling a taxi, or sending a text message, as a few examples. And all of these things can happen from within the chat interface, either through Facebook, Skype
or your website, without the need for the user to install anything.
We design our agents with the final users in mind. What will they ask? How will the conversation flow? That's an important topic. Whereas a website is something like a brochure, an agent represents an actual conversation,
and is modeled after the interaction between two people, the user and salesperson, for example, or the user and guide, depending on the use case we are addressing.
- + NLP based processing.
- + Access through Web, Facebook and Skype.
- + Interface with external apps and databases.
- + Directly capture user information if needed.
- + The Agent can take action based on the user answers.
- + Customer support.
- + Consumer facing operations.
+ Alternative to web and mobile apps.
- + Both gather and disburse information to users.
- + Knowledge bases, FAQ's and searches.
Try out YUMEKO, a conversational agent we created for Japanese hotels. Yumeko is a virtual receptionist that can answer questions about the hotel in English.
Visit Yumeko's website by using the button below, and once there, click on the pink button on the right corner to open the web chat interface.
Software Requirements Specification (SRS)
By the time you reach us with the idea to engage our services to solve a technological problem, or achieve a certain outcome with software, you will, of course, already know fairly well the issues you're dealing with, but in order for us to actually translate those needs into a functional app, there's an extra, formal step to take: defining the "requirements".
Over the decades, there have been many approaches taken by the industry to produce a clear set of functional, achievable, clear and measurable objectives for a software project, like "use cases" and "user stories", but regardless of the methodology, this is a very important step, which if we fail to execute correctly, might endanger your whole project.
In particular, it's very important that we make sure we're addressing real needs, or automating an already proven manual process. Often, businesses have inaccuracies or inefficiencies in their operation design, accrued over years of changing conditions, personnel, or unsuitable tools, and a new software project affords the opportunity to correct course where needed.
Another important aspect, is that the resulting document, called the SRS, is the basis for the work contract with us: it contains what we are supposed to deliver you, with sufficient level of detail.
The incremental approach
In short, this means to break up a large goal into sub-component goals, meaningful objectives by themselves, that can be completed with less effort and allow us a pause to assess the current situation before proceeding further. Like chapters of a book, each stage should convey a sense of completion by itself, even if it is part of a larger story.
In particular, we want to avoid the trap of building too much, without properly vetting it by real-life use. Often, there's a disparity between what we humans think it's best, and what reality shows us, so the strategy here is to take smaller steps and immediately send the results for real world validation, thus correcting course as needed with the findings.
To be clear, this is not about building independent parts of the overall solution, but rather, building complete mini-solutions while heading to the final goal.
The rollout phase
So for each one of our previously achieved development stages, we will consider, depending on the app, the client, the users and the overall strategic situation, to get the app into the hands of its real, final users. The important thing here, is that even if we are 100% confident on the quality and suitability of the job we'd done together with the client, we still need an incremental approach to rollout.
The rationale behind this is to limit our risk exposure by avoiding the possiblity of letting an undetected problem pass, and reach 100% of our users, which will then be affected by whatever it is. So instead of assuming us to be fool-proof, we'll instead assume that there will be issues, and we'll let into the app only a handful of users at first, then carefully observe and monitor the situation, before allowing a larger number of users in, and so on.
You should know that all of our development work comes with a 3 month warranty against programming defects, that they will get corrected at no extra cost, once reported. A "defect" is a deviation from the functionality stated in the SRS or a badly performing one, technically speaking. For example, "The app will return the number of customers active within the year specified in the search field" but in actuality, you discover, after 1 month, that the search in question returns ALL customers, regardless of the year that they were active. So, this is a "programming defect" and you can report it for correction.
The warranty DOES NOT cover changes in external circumstances, new business goals on the part of the client, or issues outside of our control. For all of those cases, as well as the situation when a problem is discovered after a lot of time has passed, we will remain available to assist you by any of our support options available at the time.
For now, the important take away for you, as our client, is that we'll remain committed to deliver you working solutions, and we'll stay reachable afterwards to help you with whatever new developments might arise in the future.
Evaluate, to plan for next steps
We firmly believe that the path to success is one of continuous improvement, and in that sense, what worked yesterday, might not be the best fit for tomorrow, therefore, actionable knowledge is critical to future performance.
Once we're satisfied with our current results, it'll be time to think about implementing monitoring strategies to track key metrics related to the original goals of the project. In this way, we will be better able to advice you on the path to take with a follow-up, or even a completely new project; either way, supported by evidence as much as possible, instead of only intuition.
Focus on key metrics
There are many things to track, but the idea here is to engage resources to track first the things that are likely to have the biggest impact on our goals.
We will assist you not only in obtaining relevant numbers but in deriving well thought and evidence-based, documented conclusions from them, to enable proper and justified future decisions.