Key information sat in a task board, an issue tracker and several layers of folders in a shared drive. To get what a project needed, a team member searched, then opened a messaging tool to ask about what the search had not found. Errors and duplicates were frequent.
The brief stopped getting lost between the tools
A video-tour production company replaced customer data spread across three tools, projects organised by hand and hand-offs done over chat with one connected system where every project step is triggered automatically and every adjustment lives on the project record.
This is one of Jestor's earlier cases. It was recorded in April 2022. The company's product line and focus have changed since, by the founder's own public profile. Whether the system described here still runs is not known to us. Everything below describes the operation as it was at the time of the case.
A video-tour company whose bottleneck was finding the brief, not winning the work.
Tour.Video produces video tours for properties and facilities. Demand was there. What the team lacked was a place where the project and everything about it lived together.
Video-tour production
2021Went through Y Combinator (S21)
MichiganCame out of the University of Michigan
Video toursFor properties and facilities
2022Year the case was recorded
15 minTime saved per project, at least, by the company's own estimateThe published case; no measurement method, volume or period is given.
3Channels the case names as integrated to drive the process: Slack, Gmail, Google CalendarThe "After" section of the published case; the count is the source's list.
1Kanban view on which all editing projects runThe published case's own description.
2021Year the company went through Y Combinator (S21)The company's own material and founder's public profile.
“Jestor gets a 11/10 on ease of use. I would be very disappointed if Jestor somehow disappeared, and I could no longer use it. In fact, I would be so disappointed that I would create another Jestor, just to replicate that experience.”
Amulya ParmarFounder
BeforeAfter
- Customer data across a task board, an issue tracker and nested drive foldersOne set of linked records, from sale to onboarding
- Searching for the brief, references and files per projectMaterial attached to the project record
- Messaging to ask what the next step isThe system sends a task or email when a step is due, with context attached
- Spreadsheets as workflow, rules not followedA defined workflow with steps in the software, followed because the software runs them
- Editing projects organised by handOne kanban view for all editing projects
- Adjustments discussed in chatAdjustments, changes and notifications on the project record
- Onboarding new hires through outdated, asynchronous toolsNew hires onboarded into the workflow through the system
What was not replaced. Slack, Gmail and Google Calendar stayed; they are now the endpoints of automations rather than the places where the process lives. The editing work and the product stayed. The company evaluated other database-style and documentation tools before choosing; the case reports the team's view that a documentation tool was strong for documentation and weaker for running work, which is a description of fit, not of quality.
The bottleneck was operational, not commercial
Tour.Video produces video tours for properties and facilities: universities, luxury residential, large office space, student and multifamily housing, senior living. The company came out of the University of Michigan, went through Y Combinator in the summer 2021 batch, and sold its product to property management companies alongside a sister product for lead capture. At the time of this case it was growing fast and hiring constantly.
A video tour is a media project, and media projects accumulate material: briefing notes, reference footage, drafts, adjustment requests, delivery links. All of it is necessary and all of it is easy to lose. The client's promise, high-quality production delivered quickly, depends on the team finding the right material and the right person at each step without a search.
That is why the bottleneck was operational and not commercial. Demand was there. What the team lacked was a place where the project and everything about it lived together, and a mechanism for the next step to start without a message asking for it.
The process lived in people and messages
“Jestor gets a 11/10 on ease of use. I would be very disappointed if Jestor somehow disappeared, and I could no longer use it. In fact, I would be so disappointed that I would create another Jestor, just to replicate that experience.”
There was no consistent, scalable process. Input and retrieval rules existed but were not followed; data fell out of sync; the team readjusted by hand and still lost consistency.
Actionable steps were not automated, so each hand-off was a message, a wait and a reply. Ordinary workflows were hard to implement because every step depended on someone remembering to trigger it.
Finding URLs and video files, messaging the right editor, awaiting a response, discussing adjustments in chat: every project paid the same overhead before any editing happened.
The pattern: the process lived in people and messages, and the tools held fragments of it. Nothing was broken. But a company hiring constantly could not onboard people into a process that was not written down anywhere, and every new project paid the full search-and-message cost again.
Item by item, what did each job before and what does it today
| What did this before | What does it today |
|---|---|
| Customer data across a task board, an issue tracker and nested drive folders | One set of linked records, from sale to onboarding |
| Searching for the brief, references and files per project | Material attached to the project record |
| Messaging to ask what the next step is | The system sends a task or email when a step is due, with context attached |
| Spreadsheets as workflow, rules not followed | A defined workflow with steps in the software, followed because the software runs them |
| Editing projects organised by hand | One kanban view for all editing projects |
| Adjustments discussed in chat | Adjustments, changes and notifications on the project record |
| Onboarding new hires through outdated, asynchronous tools | New hires onboarded into the workflow through the system |
What was not replaced. Slack, Gmail and Google Calendar stayed; they are now the endpoints of automations rather than the places where the process lives. The editing work and the product stayed. The company evaluated other database-style and documentation tools before choosing; the case reports the team's view that a documentation tool was strong for documentation and weaker for running work, which is a description of fit, not of quality.
The chain, end to end, for one video tour
- 1A sale closes and the customer record is createdPerson
With property, brief and reference material.
- 2A project record is created on the editing kanban, linked to the customerAutomated
The project inherits the brief and files already attached to the customer.
- 3The assigned editor receives a task or email with the URLs and files attachedAutomated
The next person does not have to search for the material.
- 4The editor produces the draft and moves the project to the next phasePerson
The editing work itself stayed; what changed is how it is handed off.
- 5The reviewer, and where relevant the customer, is notified through Slack or emailAutomated
Through the channels people already work in.
- 6Adjustment requests are logged on the project recordPerson
Not said in chat.
- 7Each logged adjustment creates a task for the editorAutomated
With the change attached to the same project.
- 8Delivery is marked, the customer is notified and the calendar event is setAutomated
And the customer receives the video through the channels they already use.
The hard links are 1 and 6. The project is only as complete as the brief someone attached at the start, and adjustments only reach the editor if they are logged on the record instead of said in chat. The design accepts both and makes them the cheapest version of themselves: one record to fill at the sale, one field to write the change in. Everything between is automatic because the two human steps are small enough to be done every time.
Every change, with the basis beside it
| Indicator | Result | Where it comes from |
|---|---|---|
| Finding project material | From crawling three tools to material on the project record | Published case, "Before" and "After" sections |
| Hand-offs | From a message, a wait and a reply per step to an automatic task or email per step | Published case |
| Data consistency | From frequent errors and duplicates to linked records with no duplication | Published case; the "no duplication" claim is the team's |
| Onboarding | From outdated asynchronous tools to onboarding through the workflow itself | Published case |
| Time per project | At least 15 minutes faster per project, by the company's estimate | Published case; no method, volume or period |
The 15 minutes is an estimate, and the extrapolation is not adopted. The case states that each project is at least 15 minutes faster and then multiplies it into "hundreds and thousands of hours" over months. The per-project figure is the team's own estimate with no method given. The multiplied figure requires a project volume that the case does not state, so this write-up does not repeat it.
"Fully automated" describes the triggers, not the work. The case says every actionable step is fully automated. What is automated is the hand-off: the task or email that tells the next person what to do and gives them the material. The editing, the review and the adjustment are still people.
No company-scale figure exists in the source. The case published no client count, project volume, revenue or team size.
What this case does not measure
Worth naming, because it is usually what gets inflated.
Every description and the founder's quote come from the company as published. No process was independently observed or timed.
Projects per month, hours per project before and after, delivery time to the customer, error rate: none appear in the source. The single time figure is an estimate with no method.
The case was published in April 2022. The company's product line and focus have changed since, by the founder's own public profile. Whether the system described here still runs is not known to us.
The case carried no header numbers, which is why the numbers table above uses counts from the case's own text.
The original case names the tools replaced and two alternatives the team evaluated. This write-up names only the three channels kept as integrations, and describes the others by category.
The name and title appear in Jestor's case and match the founder's public profile; no other team member is quoted.
The cost of a scattered process is paid in switches, not in software
| Indicator | Number | Source |
|---|---|---|
| Times a knowledge worker toggles between applications and websites per day | About 1,200 | Murty, Dadlani and Das, Harvard Business Review, August 2022; 137 users, 20 teams, 3 large companies, up to 5 weeks |
| Time spent per week reorienting after toggles | Just under 4 hours, about 9% of working time | Same study |
| Share of switches followed by another switch within 11 seconds | 65% | Same study |
| SaaS applications in use at the average company | 305 | Zylo, 2026 SaaS Management Index |
Four hours a week is the reorientation tax in a study of large, well-tooled companies. A small team with its process split across a task board, a tracker, a drive and a chat app pays the same tax per person. The case's "at least 15 minutes per project" is a rough, unmeasured version of the same finding.
Two thirds of switches in the study were followed by another within eleven seconds. That is the profile of someone searching for the thing they need across tools, which is exactly the before-state this case describes. Putting the material on the record removes the search, and the switches with it.
The 1,200-toggles number comes from one study of 137 people at three companies in 2022. It is widely repeated as a universal average. It is a good indication of scale and a poor basis for a business case; a team's own count is the right number to use.
The system is built to fit, and responsibility for it stays with us
Tour.Video's old setup was not unusual. It was a task board, a tracker, a shared drive and a chat app, each good at its job and none of them holding the process. The question a bespoke system has to answer is what happens in year two: a workflow system nobody can change becomes the new task board 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, editors, reviewers and new hires all touch the same records.
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 the founder's quote come from the case study Jestor published in April 2022, written from interviews with the company. They are the company's own account and were not audited. The quote is used in full.
Client segments and product description from the published case and the company's own material. University origin and accelerator batch from the founder's public profile and a 2021 business-school publication.
Murty, Dadlani and Das, "How Much Time and Energy Do We Waste Toggling Between Applications?", Harvard Business Review, August 2022. Zylo, 2026 SaaS Management Index.
The "hundreds and thousands of hours" extrapolation in the original case is not repeated, because the project volume it depends on is not stated. No delivery time, error rate or customer-satisfaction figure is claimed, because none was measured.