Read-only vs. full access: what actually changes

Most tradespeople don't think about permission levels until something goes wrong. A scheduling app double-books a slot. A phone tool sends a text to a customer you were about to call yourself. An entry in your CRM changes and you don't know why. At that point, someone asks: what did we actually give this software permission to do?

The answer almost always comes down to two categories: read-only and full access. They sound self-explanatory, but the practical difference — what can happen to your schedule, your customer records, your phone line — is worth walking through before you connect any tool, not after.

What read-only access actually means

Read-only means the software can look but not touch. It can pull information from your system — see what's on your calendar, check whether a time slot is open, read a customer's address or job history — but it cannot write anything back.

For a home-services business, that's useful in a limited way. A reporting dashboard that reads your job data and shows you revenue by week is a good example. It needs to see your numbers but has no reason to change them. A tool that checks your calendar availability to tell a customer 'Tuesday at 2 is open' without actually placing the booking is another.

The ceiling with read-only is that the software can inform but not act. If you want a tool to confirm an appointment, send a confirmation text, or drop a new job onto your schedule, read-only won't get it there.

What full access actually means

Full access means the software can read and write. It can create records, modify existing ones, delete entries, send messages, and in some cases manage settings. For scheduling software, that means it can place a booking, reschedule it, or cancel it. For a phone tool, it might mean it can send outbound texts on your behalf, log call notes to a customer record, or update a job status.

This is what makes automation actually work. A tool that can only see your calendar can tell someone a slot is open. A tool with full access can hold that slot, send the customer a confirmation, and put the job on your board, without you lifting a finger.

The trade-off is obvious: more capability means more that can go wrong if the tool misbehaves, has a bug, or if the credentials fall into the wrong hands.

The specific risks for a trades business

An HVAC company's calendar is its revenue plan for the day. If a software tool with full access misfires, duplicates a booking, cancels an appointment, or sends a customer the wrong address, that's a truck rolling to the wrong place or a customer waiting on someone who isn't coming.

For a locksmith or garage door company running on urgent calls, the margin for scheduling errors is close to zero. A customer locked out at 9 p.m. who gets a confirmation for the wrong time slot doesn't wait around. They call the next name on the list.

Customer records carry a different kind of risk. A plumbing or appliance repair shop that's been running for years has a customer list with names, addresses, phone numbers, and job history. Full access to that list, in the wrong hands, means that data can be read, exported, or altered. Read-only limits the damage but doesn't eliminate it, a tool that can read your entire customer database is still handling sensitive information.

When read-only is the right call

If you're evaluating a tool and it's asking for more access than its function requires, that's a signal worth paying attention to. A tool that only needs to check your availability has no business asking to write to your calendar. A reporting tool has no reason to need the ability to send texts.

Read-only is also the right starting point when you're testing something new. You can watch how the software behaves, what it reads, how often it polls your data, whether it surfaces information accurately, before you hand it the keys to make changes.

Some integrations are built explicitly as read-only for this reason. They're designed to inform a human who then takes action, rather than acting autonomously. That's a reasonable design choice for tools where errors are costly and hard to reverse.

When full access is necessary

Automation that actually saves you time requires full access. There's no way around it. If you want a phone tool to book a job while you're on a roof, it has to be able to write to your calendar. If you want a text-back system to confirm an appointment without you reviewing each one, it needs to be able to send that message.

The question isn't whether to grant full access, for many tools it's the whole point, but whether the vendor has earned it. That means looking at how they store credentials, whether they use OAuth tokens rather than asking for your actual password, what their data handling policy says, and whether other tradespeople in similar businesses have used them without incident.

A vendor that asks for your Google or Outlook password directly, rather than connecting through an authorization flow, is asking for more than they need and handling it in a way that's harder to revoke if something goes wrong.

How cheaply handles this

Cheaply connects to your existing phone line through call forwarding, no new number, no access to your phone carrier account. When it comes to scheduling, it works with the calendar you already use to find open slots and place bookings. That requires write access to your calendar, which is what lets it actually confirm jobs rather than just check availability.

The setup is designed so you're granting access through a standard authorization flow, not handing over a password. And because it operates in your business's name, answering calls as your company, texting back as your company, the customer experience stays consistent whether you picked up or the AI did.

If you're evaluating any phone or scheduling tool, ask specifically: what access does this require, what does it do with that access, and how do I revoke it if I need to? Those three questions will tell you most of what you need to know.

A practical checklist before you connect anything

Before granting any software access to your calendar, CRM, or phone systems, run through a short set of checks. Does the tool explain clearly what permissions it's requesting and why? Does it use an authorization flow rather than asking for your credentials directly? Can you revoke access in a few clicks if you decide to stop using it?

For full-access tools, also ask: what happens if there's a conflict, say the tool books a slot that was already taken? Does it have a conflict-resolution process, or does it just overwrite? For a solo electrician running three jobs a day, a double-booking isn't a minor inconvenience. It's a broken promise to a customer and a scramble to fix it.

Read-only and full access aren't good and bad. They're different tools for different jobs. The tradespeople who have the fewest problems with software integrations are the ones who matched the permission level to the actual function, and asked the right questions before clicking connect.