Products
RecUmi Service
Not publicly releasedRecUmi Service — repair and installation requests from the first contact to the result. A standalone product of the RecUmi ecosystem for service companies and technicians: take a request, assign an assignee, make the visit, record the result with photos and keep the history of work per customer. The product is in development: there are no dates and no download button yet.
Some functions — repair requests from enquiries, installation, service records, hints from conversations — are implemented in the internal system of the company Time Rec and are being tested; the other functions on this page are planned. This is not a live RecUmi service.
When a customer calls again, it often turns out that the previous technician is busy and only they know what exactly was done. You have to ask again over the phone or go in blind. Service gathers every request, visit and result into one history that stays with the company. RecUmi Service is servicing and repair of what has already been done: for the technician, the dispatcher and the head of service. It gathers requests from calls, installation for a request and service records into one history.
Sees the task, the address and past work at the customer's before the visit, and afterwards marks the result from the phone.
Takes requests, distributes them among technicians and sees which requests are waiting.
Understands technicians' workload and completion times without phoning round.
If an employee leaves, the customers' service history stays with the company.
From a customer's contact — a call, a message or an employee's request — an employee creates a request with a description, an address and a contact.
The dispatcher chooses a technician and a time; the technician gets the request in their list.
Statuses from “received” to “closed”: assigned, visit, done. Every change is saved.
The technician opens the request on site, marks the start and end of work and writes the outcome.
Before and after pictures and a description of what was done — right in the request.
All requests and visits for a customer — in one feed.
The customer learns that the request is received, a technician is assigned and the work is done.
A document about completed work is prepared in RecUmi Docs from the request data.
From the conversation the system suggests creating a repair; an employee confirms and creates the request — with a visit date, a state and a link to the customer.
Installation is assigned for a request; completion is confirmed.
A measurement stores the date, the problem, what was done and the amount.
The system determines the topic of the enquiry and its stage by set rules and suggests a clear next step, for example "agree a technician's visit". The employee decides.
All requests and work at a site (address) as a separate picture.
A separate mobile workplace for the technician is an idea that needs confirmation.
Five steps of a request — from contact to closing.
Important. These actions are implemented and verified in the internal system of the company Time Rec; in the separate RecUmi Service product they have not yet been released to users. This is a description of how the function works, not a user guide.
Service works on its own, and together with other products it receives customer data and passes the result on.
Planned Links between Service and CRM, Measure and Docs will appear together with the release of the products and the shared RecUmi Core foundation.
"Implemented, in testing" means the feature is implemented in a test or internal version and has not yet been made available to users as a finished public product. Where: in the technical version built on the internal system of the company Time Rec; the other RecUmi Service functions are planned. This is not a live RecUmi service.
There are no dates: the order is a concept, not a commitment.
Service is designed as a separate after-sales workflow on the shared RecUmi Core foundation; the link with CRM and Docs will appear together with their release.
No. The product is in development; there is no download button. We do not name dates.
No. Service is designed as a standalone product; it will exchange data with CRM and Docs if you use them.
Yes, that is the idea: a customer's requests are collected in their history for each address. This is a planned capability.
Yes, photos and the result of the work in a request are part of the product idea.
For repair and installation on site visits: appliances, doors and gates, utility systems, household services — anywhere there is a request, an assignee and a result.
The idea is that a technician sees what is needed for their requests. Permissions will be set through the shared RecUmi Core foundation.
A technician's workplace on a phone is an idea that needs confirmation. We do not promise it for now.
Yes, this is how it works in the internal system of the company Time Rec: the system suggests a repair and an employee creates the request. It has not yet been released in the separate RecUmi Service product.
This is a planned capability. For now service records are stored inside a measurement.
Service is designed as a standalone product; it exchanges data with CRM, Measure and Docs if you use them.
Want to tell us about your service and its tasks? Write to us — it will help us make the product more useful.