Work and scheduling

What it does

This is the diary and the job list — when you're free, what's booked, what recurs, and who's doing it.

Rufio checks availability against what's actually in the calendar, books supported appointments into it, keeps the calendar and the work records behind it, and handles recurring work so the jobs that come round every quarter don't depend on someone remembering them. Jobs, tasks, projects, and the calendar behind them are the settled part of this page and work from the start. The field-service side specifically — dispatching to someone out on a job, and what they see when they get there — is newer and still being filled in, so expect it to be thinner and to change more than the scheduling it sits on top of.

The work itself is covered alongside the scheduling, because in practice they're the same conversation: tasks and who they're assigned to, project and job work, and the approval routing that decides what needs a sign-off before it proceeds. Moving an appointment and telling the person doing the job are not two separate requests here.

When to use it

• Someone wants to know when you can come. Ask and the answer accounts for what's already booked, rather than a nominal opening you then discover is taken.
• A job needs moving. Ask Rufio to move it and the reschedule, the customer, and the job record are handled together.
• Work comes round on a cycle. Recurring work means the quarterly service doesn't rely on anyone remembering it.
• You want to know what your week looks like. Ask, and you get what's booked and what's still open rather than a calendar to interpret.
• Something needs a sign-off before it goes ahead. Approval routing holds it at the right point and puts it in front of the right person.

Use Customers and sales instead when the work isn't booked yet and the question is about a quote or an enquiry.

How to use it

Ask in a sentence — move a booked appointment to another day, ask when you are next free, ask who is assigned to a job, or set a customer up on a recurring visit. All of those are direct requests.

A single request covers everything that follows from it — you ask once, and the parts that have to move together move together. Where a request would force a choice that's genuinely yours, Rufio stops and puts the choice in front of you rather than resolving it quietly.

Example — moving a booked job:

Request: move a booked appointment to Thursday.

What Rufio does: finds a Thursday slot that holds up against what's already booked, tells the customer, and updates the job so whoever is assigned sees the change — along with the history, the items, and the checklist attached to it.

Where it stops: if Thursday would push another booking, Rufio stops and shows you the conflict rather than choosing between two customers. Deciding which one moves is yours, and Rufio treats it that way rather than picking the tidier answer.

At Suggest, the proposed reschedule waits for your approval before the customer hears anything. You might choose to automate reminders while keeping new bookings and schedule changes at approval. Set each task separately around the way you want your time managed. See Autonomy levels.

Parameters

What Rufio needs from you. Your actual availability, as rules rather than as a one-off answer: what hours you work, how long the common jobs take, how much travel time to leave, which days you don't want booked. Those are the things that make an availability check trustworthy rather than optimistic.

For assignment, who does what. Rufio can route work to a person, but which of your people handles which kind of job is something you tell it.

For approvals, where the gate goes. What needs a sign-off before it proceeds, and whose sign-off, is your decision — Rufio holds the work at the point you name.

For recurring work, the cycle and what it covers. Set once.

Corrections are kept. If you move something Rufio booked because it was the wrong kind of slot, that becomes a rule rather than a correction you make again next month.

What you get back

For an availability question, a real answer — times that hold up against what's already committed, not a first-pass guess you then check by hand.

For a booking or a move, the calendar updated, the customer told, and the job record changed to match, as one piece of work rather than three you chase separately.

For a conflict, the conflict itself, shown to you, with the reschedule stopped. This is the more important half: Rufio surfacing a clash it won't resolve alone is the behavior you want, not a failure to complete the request.

For recurring work, the cycle running without further prompting, inside the rules you set.

Limits

Rufio does not commit you to work without your OK. It can hold a time slot with a caller; confirming the booking follows the rules you set and defaults to asking you. That's a hard limit, not a preference.

It does not choose between two customers. A reschedule that would push someone else stops and shows you the conflict.

It does not decide your working hours, your travel time, or how long a job takes. Those are inputs from you; Rufio applies them rather than inferring them from a pattern and quietly acting on the inference.

It does not add a new scheduling behavior because it spotted an opportunity. New automations are proposed in plain language before they exist.

Related

• Customers and sales — the quotes and enquiries that turn into booked work
• Phone and messages — how a caller asking for a slot is handled
• Automation and reports — recurring and triggered work that runs without being asked each time
• Team and systems — who on your team can be assigned what
• Autonomy levels — why booking and calendar upkeep deserve different levels
• Every capability — the full list, and whether each one is available to you today