Sales, KPIs and the status of each customer implementation lived in separate spreadsheets. To know how the company was doing, someone had to open several files and put the picture together by hand, every time.
The process stopped living in people's heads
A conversational AI startup moved sales, customer implementation, recruitment and the handoff to finance off spreadsheets, docs and email, into one connected system where each step is recorded when it happens and the time each step takes is logged automatically.
A conversational AI startup whose processes all touch each other.
A sale changes what finance has to bill, what implementation has to deliver and what the product has to unlock. A churn changes all three again. Recruitment runs beside them, with its own pipeline and its own deadlines.
Conversational AI
2020Founded
450+Client companies, at the time of the case (2022)
2.5 millionEnd users of the company's bots, at the time of the case
2026Became a TOTVS company
2,500,000+End users of the company's botsThe company's own published figure in the case header, at the time of the case (2022). Product scale, not a result of the system.
2.5 billionMessages sent through the productSame source, same date. It describes the product the company sells, and nothing in the source attributes it to the system.
450+Client companiesSame source, same date. The company's own later material reports a much larger client base, so this is a 2022 figure only.
3Operating areas the case names as moved off spreadsheets and docsGrowth, recruitment and finance. The count is the published case's own summary line, not an estimate.
“Adopting Jestor had a clear impact in our bottom-line as a company, since we saved so much time with manual processes by having everything in one place. I don't know of any other tool that can support so many sides of our operations at once and adapt to new processes so quickly.”
Thiago AmaranteCEO, in the 2022 published case
BeforeAfter
- Sales, KPIs and implementations in separate spreadsheetsOne system where these records are linked, so the company picture assembles itself
- Growth tracked by opening several filesKPIs computed continuously from the sales and subscription records
- Emails to finance about each sale or churnAn automation that notifies finance when the balance changes
- Recruitment across documents, a spreadsheet and emailA positions table, a form that updates itself, a pipeline with time per step, and a talent pool
- CVs in inboxes and shared-drive foldersCandidate records with attachments in the pipeline
- Implementation status tracked by handAn implementation pipeline where each phase change writes a time-spent record
- Churn as a line in a spreadsheet, if thatA churn flow with the reason recorded, so causes can be sorted
- Product suggestions in conversations and messagesA suggestions flow from submission to evaluation to implementation, reviewed weekly
- Explanatory emails about tasksTasks attached to the record they concern
- Loaned equipment tracked informallyAn items table and a movements table, with quantities updated automatically
The company's product stayed and now reads subscription tiers from the system. The analytics tool stayed and receives data from the system. Data lakes stayed as the destination for exported records. The weekly product meeting stayed as a meeting. The headline of the original case says the company runs 100% of its operation in the system; the case's own body names at least three external tools it still runs alongside, so this write-up does not repeat the 100% claim.
The bottleneck was operational, not commercial
Chatbot Maker builds Suri, an AI assistant that lets businesses automate customer conversations, learning from each client's own data. At the time of this case the company reported more than 450 client companies, 2.5 million end users and 2.5 billion messages sent. It was founded in 2020, took seed funding from a venture fund in 2021 and 2022, and in late 2025 agreed to be acquired by TOTVS, a listed enterprise-software group. The acquisition closed in early 2026 after regulatory approval. Suri is a TOTVS company.
A software startup at this stage runs on a handful of processes that all touch each other: a sale changes what finance has to bill, what implementation has to deliver and what the product has to unlock; a churn changes all three again. Recruitment runs beside them, with its own pipeline and its own deadlines. None of these processes is complicated on its own. What is hard is keeping them in step when each one lives in a different file and the step from one to the next is a person remembering to send an email.
That is why the bottleneck was operational and not commercial. Customers were coming in. What the team lacked was a way to see the whole company at once, and a way for one team's action to reach the next team without someone typing it out.
The process existed only in the heads of the people running it
“Adopting Jestor had a clear impact in our bottom-line as a company, since we saved so much time with manual processes by having everything in one place. I don't know of any other tool that can support so many sides of our operations at once and adapt to new processes so quickly.”
Job descriptions in documents, candidates in a spreadsheet, outreach in email. With nothing linking them, sending the same candidate the same email twice was a live risk, and CVs ended up scattered across inboxes and shared folders.
A closed deal or a lost customer did not reach the finance team on its own. It had to be written up in an email, which meant it arrived late, or not at all.
The pattern: the process existed only in the heads of the people running it. Spreadsheets and documents hold data; they do not hold steps, and they cannot tell a manager whether a step was skipped or how long it took. Nothing was broken enough to stop the company. Everything was loose enough that it would come apart under growth.
Item by item, what did each job before and what does it today
| What did this before | What does it today |
|---|---|
| Sales, KPIs and implementations in separate spreadsheets | One system where these records are linked, so the company picture assembles itself |
| Growth tracked by opening several files | KPIs computed continuously from the sales and subscription records |
| Emails to finance about each sale or churn | An automation that notifies finance when the balance changes |
| Recruitment across documents, a spreadsheet and email | A positions table, a form that updates itself to match open positions, a pipeline with time per step, and a talent pool |
| CVs in inboxes and shared-drive folders | Candidate records with attachments in the pipeline |
| Implementation status tracked by hand | An implementation pipeline where each phase change writes a time-spent record, feeding dashboards and the data lake |
| Churn as a line in a spreadsheet, if that | A churn flow with the reason recorded, so causes can be sorted |
| Product suggestions in conversations and messages | A suggestions flow from submission to evaluation to implementation, reviewed weekly |
| Explanatory emails about tasks | Tasks attached to the record they concern |
| Loaned equipment tracked informally | An items table and a movements table, with quantities updated automatically |
What was not replaced. The company's product stayed and now reads subscription tiers from the system. The analytics tool stayed and receives data from the system. Data lakes stayed as the destination for exported records. The weekly product meeting stayed as a meeting. The headline of the original case says the company runs 100% of its operation in the system; the case's own body names at least three external tools it still runs alongside, so this write-up does not repeat the 100% claim.
The chain, end to end, for a new customer
- 1A sale closes and is recordedPerson
With its subscription tier and value.
- 2Finance is notified of the balance changeAutomated
The email that used to carry the news is no longer the channel.
- 3An implementation record enters the pipelineAutomated
Customer implementation starts from the same sale record.
- 4The implementation team moves the record through its phasesPerson
As the work is done, not as a later status update.
- 5Each phase change writes a time-spent recordAutomated
The time spent in the previous phase, feeding dashboards and the data lake.
- 6The product reads the subscription tierAutomated
Access is set from the same record, and subscription data reaches the analytics tool.
- 7If the customer later leaves, a churn record is createdPerson
With the reason, so causes can be sorted.
- 8Finance is notified of the churnAutomated
Dashboards and KPIs recompute from the updated records.
The hard links are 1, 4 and 7. A system cannot know a deal closed, a phase ended or a customer left until a person says so. The time-per-phase figure is exactly as accurate as the moment someone moves the card. The design accepts that and makes the human step as small as it can be: one field, one drag, one reason picked from a list. Everything downstream is automatic because the upstream step is cheap enough to be done on time.
“Jestor gave us a much better managerial view of our operations in several areas, including Sales, Growth and Recruitment.”
Every change, with the basis beside it
| Indicator | Result | Where it comes from |
|---|---|---|
| Visibility of company growth | From assembling several spreadsheets by hand to KPIs computed from linked records | Published case, "Before" and "After" sections |
| Sales-to-finance handoff | From manual emails to automatic notification on balance change | Published case; the case says this replaced hundreds of emails and spreadsheet edits, without a period or a count method |
| Recruitment pipeline | From three unconnected tools to one pipeline with time per step and a talent pool | Published case |
| Implementation tracking | From status by hand to time-per-phase records feeding dashboards and the data lake | Published case; no before-and-after cycle time is reported |
| Time on manual work | Described by the CEO as time saved with a clear effect on the bottom line | CEO quote in the published case; no figure is attached to it |
No time or cost figure is claimed here because none was measured. The published case describes what was replaced and quotes the two executives on the effect. It does not report hours per week before and after, hiring cycle time, implementation cycle time, or the size of the effect on the bottom line. A reader who wants those numbers should treat their absence as information.
"Hundreds of emails" is the source's own phrase, not a count. The case says the finance automation replaced hundreds of manual emails and spreadsheet edits. No period and no counting method are given, so the figure is reported as the case's description rather than as a result.
The company-scale figures are not results. Users, messages and client count describe the product the company sells. Nothing in the source attributes any of them to the system, and this case does not either.
What this case does not measure
Worth naming, because it is usually what gets inflated.
Every description of the before and after comes from the company's team as published. No process was independently observed or timed.
Hours saved, hires per month, implementation cycle time, churn rate before and after: none appear in the source. They are the numbers a buyer would want and they were not measured.
The case was published in April 2022. The company has grown several times over since, and in 2025 agreed to be acquired by TOTVS; the deal closed in early 2026. Whether the system described here survived the acquisition, or in what form, is not known to us.
The case's own body names the company's product, an analytics tool and data lakes as systems running alongside. "Most operating processes" is what the source supports.
The COO's quote in the original case continues with a sentence about the team building and modifying processes on the platform itself. Jestor now builds and maintains the system on the customer's behalf, so that sentence describes a working model the company no longer sells and was removed.
The names and titles appear in Jestor's own case and were not confirmed against an independent source here.
The three header figures carry no measurement date and are treated as "at the time of the case."
The stack stopped growing; the cost did not
| Indicator | Number | Source |
|---|---|---|
| SaaS applications in use at the average company | 305 | Zylo, 2026 SaaS Management Index |
| Average annual SaaS spend per organization | USD 55.7 million | Zylo, 2026 SaaS Management Index |
| Organizations that had to cut projects because of unplanned SaaS cost increases | 61% | Zylo, 2026 SaaS Management Index |
| Year-over-year change in application count | Roughly flat (down 0.07%) while spend rose 8% | Zylo, 2026 SaaS Management Index |
For the first time in this index's run, the number of applications per company held flat year over year, while spend still rose. Companies are no longer adding tools; they are paying more for the ones they have, and a majority have cut projects to cover it.
Sales, implementation, recruitment and finance handoffs are specific to how each company runs. Off-the-shelf tools cover each area in isolation and leave the joins, which is where this company's problems lived, to email and memory. A connected system built to the company's own process is the alternative to buying four tools and a fifth to integrate them.
"Average number of apps per company" ranges from about 100 to about 340 depending on who counts and how. Every serious estimate lands in the hundreds, which is the useful point; the exact number should not be built on.
The system is built to fit, and responsibility for it stays with us
Chatbot Maker's old setup was not careless. It was spreadsheets, documents, forms and email, each doing a job well enough until the company needed them to work together. The question a bespoke system has to answer is what happens in year two: an operations system that nobody can change becomes the new spreadsheet in three years, with a login.
One builder owns each request from start to finish, and one is always in execution.
A new flow, a new automation or a new report comes in through the same channel, without becoming a new project.
If what was built is not right, it is rebuilt. Unlimited revisions within the subscription.
Seats are never the billing unit, which matters when sales, implementation, recruiting, finance and product all touch the same operation.
People learn to use their app the way they learn any app, by opening it. Building, configuring and maintaining stays on our side.
Full export at any time, by CSV and API. SOC 2 compliant, no exit fee. Pause in one click and the systems keep running.
Methodology and sources
The before-and-after descriptions and both quotes come from the case study Jestor published in April 2022, written from interviews with the company's team. They are the team's own account and were not audited. The COO's quote was shortened to remove a sentence describing a working model Jestor no longer offers. Names and titles are as published in that case.
Users, messages and client count come from the case header, undated in the text and treated as of publication. Founding year, seed funding and the 2025 acquisition and its 2026 closing come from the acquirer's regulatory filing and business press coverage between November 2025 and March 2026.
Zylo, 2026 SaaS Management Index, as published on the company's site.
TOTVS announced the acquisition in November 2025; it closed in early 2026 after regulatory approval. The case is about the 2022 operation. Whether the system described here survived the acquisition, or in what form, is not known to us.
No time saved, cost saved, cycle time, hire count or bottom-line effect is claimed as a result, because none was measured in the source. The "hundreds of emails" phrase and the "100%" headline appear only with their caveats.