Every business we talk to wants the same thing from AI: for it to stop living in a separate tab and start touching the systems that actually run the business. Calendar, email, the CRM, the board where the work lives. Then the second thought arrives. What if it does something we didn’t ask for? What if it sees something it shouldn’t?
That fear is reasonable.
This post covers how we handled it: what a connector actually is, the process we went through to get comfortable, and the checklist we only wrote down after we’d already lived through it. There’s a full session recording below if you’d rather watch, but the post stands on its own.
What a connector actually is
A connector is what lets Claude reach into an app you already use, Google Drive, Gmail, Slack, Monday.com, Notion, and read from it or act in it during a conversation. Without one, Claude only knows what you type or paste in. With one, it can go and check your calendar, pull a document, or update a board item on its own, without you leaving the chat.
Claude doesn’t get its own login to do this. It inherits whatever permission you already have in that tool. If you can’t see a file or a channel, connecting Claude doesn’t change that. And every connector has its own dial: some things it can only read, some things it can read and act on, and for anything that writes or sends, you decide whether that happens automatically or needs your approval every time.
Why we didn’t start inside our own systems
A year ago this was mostly a developer thing, reached through code. Then it got easier, and the horror stories arrived with it: AI tools wiping hard drives, wiping accounts, the kind of thing that makes “chaos robots” a genuinely useful phrase for describing the fear rather than an exaggeration of it.
We didn’t ignore that fear and we didn’t let it stop us either. What we actually did was experiment away from the business first. Personal machines, sometimes machines signed into nothing at all, testing what these tools could do before we let them anywhere near a live system. Internally we kept using AI in isolation for a good while, custom setups with no connections at all, while we built up the confidence to go further. It took about six or seven months to go from that to fully wired into the stack. Slow on purpose.
That gradual approach turned out to matter more than the tools themselves. The efficiency case for connecting things is genuinely hard to argue with, so the temptation is always to switch everything on at once. Resisting that, and doing it in a order we could actually manage, is most of what made this safe.
Permissions aren’t one switch, they’re several
The instinct is to think of a connector as on or off. It isn’t. There are layers, and understanding them is most of what separates a safe rollout from a risky one.
First, there’s the organisation layer. On a Teams plan, an admin decides which apps and connections are allowed into the account at all. Individuals then choose, from that approved list, which ones they personally connect. So you’re setting the ceiling once, centrally, and letting people opt into what actually helps their own work.
Second, there’s the action layer, inside each connector. When you connect something, Claude shows you specifically what it can see and do, and you can restrict further from there. As a default, we run “ask permission” rather than “always allow” almost everywhere. Ask-every-time is doing two jobs at once: it stops something happening without you noticing, and it shows you how often a permission actually gets used, which tells you whether it’s genuinely useful or whether you should be questioning why it’s switched on at all.
Third, there’s email specifically, because it’s the one people worry about most. We never let Claude send on our behalf. It can go and fetch an email into a chat, draft a reply once you’ve dictated what you want said, and put that draft back in Gmail. You read it one more time and send it yourself. The send step stays entirely outside the connector’s permissions, not because we don’t trust the drafting, but because that’s the one action with no undo.
None of this is about distrust of the tools. It’s about starting from a position of locked, and having a clear reason before you open anything up. Anyone on the team can come and make the case for switching something on. That’s not a barrier, it’s just where the conversation starts.
The checklist we only wrote down afterwards
When we sat down to plan this session, what came out wasn’t a plan we’d followed from the start. It was a retrospective, the steps we’d actually gone through without realising we’d built a process at all.
Start read-only. Every connection begins with the least it can do, not the most. Connect only what you need, when you have an actual reason to need it, rather than switching everything on because it’s available. Know what each connector can see, because the settings screen tells you exactly what you’re granting, and reading it properly is good general security practice on its own. Test on low-stakes work first, so you can build confidence somewhere that doesn’t matter before you touch anything that does. And review and revoke whenever, because the interface makes it genuinely easy to switch things off, and doing that regularly is how you catch the experiment from six months ago that’s still quietly switched on.
That last one is worth taking seriously as a habit rather than a one-off. Reconnecting periodically forces the question: do I actually still need this? Sometimes the honest answer is no, and that’s the whole point of asking.
The smallest thing you can do this week
If you haven’t connected anything yet, don’t start with the CRM. Connect your calendar, read-only, and see what happens. That’s the equivalent of giving a colleague view access to your diary, nothing more. It’s low-lift enough that there’s no real decision to agonise over, and it opens up genuinely useful questions almost immediately: how much of your week is meetings, where the gaps actually are, what your real working pattern looks like once you can see it laid out.
Small, low-stakes steps like this are how you build the muscle for everything else. You don’t need a business-critical automation to make this worth doing. You need to get comfortable with a new way of working, one low-risk connection at a time.
AI & Automation Level 4 Apprenticeship
Government-funded. Built for SMEs. 12 months, structured around real workplace projects.
AI Tools for Small Businesses
A practical short course for small business owners and their teams. No technical background needed.
Want a second opinion on your own setup?
Internally we use a version of this same process before we connect anything new: a short conversation that weighs up the gain against the risk, then logs the decision so we can show our working later. If you want to run your own connectors through something similar rather than relying on this post alone, our team can talk it through with you and give you a written view of where the risk actually sits.
Talk to us about your team's AI Training
Not sure which route is right? Book a free discovery call and we’ll point you in the right direction
Francesca Roberts
Head of Commercial
Worth reading if you want more detail
Anthropic’s own guide to connectors covers the permission types in more depth than we have room for here, including how “always allow”, “needs approval”, and read/write categories work across different connectors.
Follow me on LinkedIn
I post about this stuff regularly, tools, what’s working, things worth knowing. DMs are open if you want to chat about any of it. If you want to stay across it, the easiest place is LinkedIn.
Questions from the session
We had a good set of questions come through in the Q&A. A few worth sharing here.
What’s actually stopping most people from connecting Claude to the tools they already use? Mostly named fears rather than specific ones: data breaches, prompt injection, the general sense that something could go wrong and you wouldn’t know until it had. Naming the fear specifically is the useful first step, because most of it turns out to be manageable once you’re looking at it directly rather than avoiding it.
My connector for Monday.com is connected but it doesn’t seem to be doing anything. What’s going on? Monday recently moved third-party connector permissions into their AI settings area, so if that’s switched off internally, the connection looks live but doesn’t actually do anything. Worth checking your Monday AI settings specifically, not just the Claude side.
We’re worried about exposing something sensitive, like a full client list, to Claude. How do you actually handle that? The same way you’d handle it for a new employee: control what they can see before you worry about what they might do with it. In practice that can mean creating a specific view-only user for a tool, or moving the sensitive data somewhere separate before you connect anything to it. The instruction isn’t “don’t look at the sensitive stuff”, it’s making sure the sensitive stuff isn’t reachable in the first place.
How do you decide whether something should be “always allow” or “ask every time”? We default to ask-every-time for almost everything, because it does two jobs. It stops anything happening without you noticing, and over a few weeks it shows you exactly how often that permission actually gets used. That usage pattern is the real evidence for whether something’s earned “always allow” or whether it shouldn’t be connected at all.
Does this slow down how quickly you can actually use these tools? Less than you’d think. Locking things down by default doesn’t stop anyone experimenting, it just means the default state is off rather than on. Anyone can make the case for switching something on when they’ve found a genuine use for it, and that conversation is usually quick once the actual risk is on the table rather than a vague worry about it.
The rest of this series
This session builds on the ones before it, and sets up the one after.
Sessions already available on the site:
- Getting your team to actually use AI – people, process, tools, in that order
- Building a Claude assistant that knows your business – context engineering, Projects, Skills, and where to start
Coming up:
- The automation loop we couldn’t have built without Claude – the multi-connector workflow behind our own monthly reporting, and what it took to get there
- Claude Design – building a style guide Claude can use to draft on-brand slides, documents, and print materials
- Setting up Claude for your whole team – projects, shared context, and getting everyone working from the same foundation
- Intro to Claude Cowork – a first look at automating real tasks with no code involved
Sign up for all upcoming sessions in one place:
Join our free AI webinars
Practical AI topics, no jargon, free to attend. New topic every couple of weeks – always something you can actually use.
[00:00:12] Rob Brighton Good afternoon and welcome to today’s session on connecting Claude. We’re co-hosting today, Crispin and I. As always, we’ll have Francesca in the LinkedIn comments fielding your questions. We’ll have a little bit of time at the end to run through any of your questions, and we’ll be posing some throughout the session. I’ll take the opportunity now to welcome Crispin into the session. Take it away.
[00:00:44] Crispin Read Thanks very much, Rob. Yes, today, it’s hot today, isn’t it? We’re all a bit too hot and we can’t have our fans on because it interferes with the mic. So today: connecting Claude to the tools you use every day. I think this is one of the things we get asked about a lot, and one of the things people are most scared about, maybe rightly so. What we’ll do today is show you how we actually run it, what our process was to get comfortable with the things we’re connecting, and hopefully there are some learnings for you in that.
First off, a little bit about who we are. Hello, I’m Crispin. I’m the CEO of The Coders Guild. Twenty years in software and digital transformation. I led the R&D on the Level 4 standard for AI and Automation, so drop a comment if you’re interested in the funded route, government funding to pay for training of this nature in your company. I base that on our own experience, but also on the dozens of businesses I spoke to about this last year, so we’ve got a good idea of what works, what doesn’t, and where people need help.
Rob is here with me, so we’re tag-teaming today, and I think what’s important about that is it reflects our team dynamic, our relationship working together. I’m like the eager beaver with an appetite for risk who just wants to connect everything, experiment and innovate, whereas Rob, as an operational person, is more sensible, and he’s also our DPO. So as we talk through our story, you’ll see how that played out, and how it was actually an advantage for us.
[Brief technical hiccup — slides not advancing, some cross-talk about the heat in the room]
[00:03:42] Crispin Read So, firstly, and I think this is important: what we’d like you to do right now is drop something in the comments to tell us what’s stopping you from connecting Claude, or whatever LLM you use, to your tools already. There are legitimate concerns out there — things like prompt injection, data breaches, chaos robots.
[00:04:11] Rob Brighton Yeah, so many. But I think an important thing for us to do, as a first point in getting over a fear of something, is to name it. When we talk about our story, that’s what we were doing — naming what we’re worried about and what we do about it. So please do drop some stuff in the comments and we’ll come back to it at the end if you have a specific question. We’ve also got a resource to share at the end where we can run you through a diagnostic process to estimate your risk for connecting the things you work with.
[Brief technical hiccup — slides going blank, a little back-and-forth about it]
[00:05:22] Crispin Read Talking about the early days of what we were doing, this time last year, that was when the connectors, the MCP, the ways you can connect different things to large language models, first showed up, and mostly they were only accessible through code. Open Claw came about and was incredibly popular, but also incredibly frightening. There were lots of horror stories — Claude, or Open Claw, wiping someone’s hard drive, wiping someone’s bank account. Those were the kinds of things we were talking about, but we still did experiments, because the efficiency gains from using these things are pretty irresistible.
Me and Rob talked about what we could do safely. For the most part, what we ended up doing was a lot of experiments not on Coders Guild machines. We’d use our own machines, sometimes machines that weren’t signed into anything, just to test things out and get comfortable with what was clearly the evolution of the operating model for business. We did things cautiously. In the beginning we were connecting our main systems, or versions of them, just not inside the Coders Guild workspace, because there was too much to risk.
[00:07:11] Rob Brighton Yeah, if I jump in there from an organisational perspective — we were still very much using ChatGPT internally for the projects we’d created and the custom GPTs, but that was acting in isolation from any connections. It wasn’t until late last year, early this year, that we started setting up our own personal experiments and validating Crispin’s wild theories that this was going to be the future. Here we are, six or seven months into the journey, and it’s fully integrated into the stack now. It’s been a gradual, careful, considered process, but as educators in the AI space, it’s something we have to do, to be able to advise and educate at the same time. We’ll give you a bit more insight into the kind of things we use it with in the next few slides.
So, this is something we’ve hinted at before: an idea of where we’re using connectors in workflows at the moment. This is one of the more complex workflows we’ve got going, where we take sources of information from siloed apps and pull them together using Claude to enrich a process that we couldn’t before, or that required a lot of manual steps to bring together.
We’ve got a number of bits of feedback from different sources when we run a session, in calendar. The feedback gets pulled into Drive, some into Monday, and Claude takes the calendar event, the Drive information and the Monday information, processes all of that, and writes back the updated report into the particular item in Monday, then fires a Slack report out to us, so we can keep track of the sessions that happen that day. In the long term we’ve got feedback on sessions, so when we come to run them next time we know what worked, what didn’t, and what we need to carve out. There’s loads more we can do with that, but that’s just pure connectors and Claude. I’m probably giving away too much here.
[00:10:07] Crispin Read Well, I think the thing is, our next webinar is basically about this whole process, because I feel like this is the main process we started on knowing we could make more efficient, and then in the working out of how to make it more efficient, we actually realised how much further we could go with the tools we now had access to. It becomes an AI-native process, which I think is what you can see across the business — things start with an efficiency gain, then they become an AI-native thing, which is the next level, beyond efficiency, it’s the new operating model.
One of the things I think about: is Google Workspace the centre of our operations? What’s the main digital tool? Historically it would have been something like Word or 365, then it becomes Monday, or Asana or something, when we started doing more automations, those businessy processes. Now I feel like Claude is our central tool and all the others are the peripheries. So, I’ve gone on now, we could talk about this all day. Come to our five-hour webinar where we just talk about our favourite thing.
[00:11:41] Rob Brighton It’s not really. Sorry.
[00:11:44] Crispin Read Thanks, Rob. I want to do a callback to our last webinar, when we talked about the VA skill, because that relies heavily on connectors too. What that VA skill is able to do off the back of a pretty off-hand voice note is down to connectors, but also down to the permissions those connectors have. So the way I want to work isn’t just described to Claude in the skill, in the knowledge it has about me in memory — it’s also in what these connectors are allowed to do, how far they’re allowed to go.
When we look at what it can read and update in Drive, it can do the same in Notion. I’m quite free with Notion because that’s an isolated space for me, personal notes, so it’s not really impacting the team, there’s no real risk because it’s just my personal stuff. Getting things in and out of Monday and Slack is really important for that to work. So I can just say, for example, go and find the email chain from the chat I’m having with the DWP about the software dev Level 3 thing, and it’ll bring that into the chat for me to respond to.
But thinking about the permissions part — email in particular is a good one, because I’m quite fussy about it. I don’t really let Claude write my emails for me, Gemini is desperate to write every single email for me, and I never use that. Generally I’ll ask Claude to go and get an email and bring it into the chat, then I’ll dictate: “take a letter, Claude”, and I’ve got a voice skill that says when Crispin says he’s dictating, it means dictate. It doesn’t mean be humble and excited and unnecessarily flamboyant with the language, it means just tidy this up, take the ums out, make me sound a bit more professional. Those drafts happen in Claude, and when I’m happy with them I can say “add that as a draft back in Gmail”, then I’ll go and read it through one more time in Gmail and send it myself. I never let the send happen — that’s shut off completely from the permissions.
Which is a good transition to our next bit, a demo for setting up a normal connection and looking at the levels of permissions and access you get to grant. Normally we’d do a live demo, but it’s too hot for live demos today, so at the eleventh hour we’ve opted for screenshots. This could go one of two ways.
[00:15:02] Rob Brighton But, with my DPO hat on, it’s also better not to expose login information and things like that. Did we sanitise your Claude history?
[00:15:18] Crispin Read Oh, probably not. I think we did, okay — — for the camping weekend.
[00:15:26] Rob Brighton Excellent. I don’t think that’s a problem or anything, that’s fine. So, I’ll walk you through it. You head over to Customise — that’s the same for Claude Code and Cowork. That opens the settings. You jump down to Connectors, hit Add to add a new connector, and you can search available connectors. Especially when you’re starting your connectors journey, you want to go for existing connectors from the actual company you’re connecting with, confirm its legitimacy, in the same way you’d double-check an app is actually made by the company it appears to be from.
Then, based on organisational admin privileges on Crispin’s account, you hit “add to your account or team” depending on what tier you’re on, and it shows up in your connectors, and you can connect it. In this instance we’re demoing connecting to HubSpot. For the most part you’ll get to see the specific connector permissions when you’re connecting it, which gives you an opportunity to research a bit deeper and restrict what you need to restrict from the connector side, from the supplier, from HubSpot. Then you’ve got the permissions internally within Claude. As a default, we tend to have “ask permission”, we don’t tend to have “always allow”. If you’re an organisational admin, or doing this for your personal setup, you want to start off as locked down as possible, then add the bits you need.
From our perspective, we’re on a Teams tier, so we have an organisation where we invite team members, and the admins can pick which apps and connections are allowable into the account, and then the individual can choose from that allowable list to connect their individual account to their Claude. So you set organisational defaults on permissions, and then confirm with your team which apps would be best suited to their workflow. We’ve introduced that into our process: one of the tools we have to try and keep things safe and compliant is a skill that, when we’re looking to bring on a new connector, we have a conversation in Claude, pull together a few questions, and it gives us advice on how we should set up and approach that connector, then we log it, so it shows we’ve done our due diligence and taken the time to make sure what we’re connecting, and how we’re setting permissions, is safe.
[00:19:20] Crispin Read Sorry, the other thing we don’t want to do is stifle innovation. Just because we’ve locked these things down, we’re starting from a position of “locked”, but everyone can see what connectors they can have and research them. If we’ve locked something down, it’s not because we don’t trust it forever, there has to be a reason to switch it on, and it’s easy to have a good reason, but we start from a position of off. So anyone can message Rob and say, “I’ve found a use case for switching on this bit of this connector, it would help me do this”, and then, like Rob says, we can run it through the skill and be aware of the risks, then decide whether we do that as “always allow”, or “ask every time”. The “ask every time” option is really useful too, because it shows you how often you’re using that thing, which can tell you one of two things: that it’s super useful and safe, or that you should be thinking about whether you’re allowing this thing in this state, on this occasion.
[00:20:35] Rob Brighton Yeah. Does that make sense?
[00:20:36] Crispin Read I agree. And, not wanting to stifle innovation — these are all tools we’re using anyway, it’s a matter of bringing them together so we can make ourselves a bit more efficient. It’s definitely not about that, it’s about managing that risk effectively within the business.
So this is kind of our checklist — a retrospective one really, because when Rob and I were discussing what we’d do for this webinar, it’s the steps we went through, which becomes the road map, if you like.
Like I said, you always start read-only. We’re only connecting the things we actually need, we’re not just going in and switching everything on. We do everything on a needs basis: we look for the need, then we do the connection. It’s a bit like my bugbear about software dictating what people do — this gives us much more freedom than ever before. Historically you might buy a piece of software, a CRM or something, and along the road you change your process because of how that software works. We don’t need to do that now. When we want to do a thing, we think about the thing, then we do it.
You’re being really mindful about what each connector can see, there are so many levels of permissions. One of the things I like about the interface, as Rob walked through with HubSpot as the example, is how clear it is about what you’re connecting, what’s available to you, what you have to do, and what’s available in future. That also makes you think, “well, I wouldn’t want that to happen”. That’s good general security awareness too. As we said, when people come to Rob with an idea, they’ll have done that research, had that back-and-forth with Claude to investigate the gains against the risks. Low-stakes work first, practice, not on the business-critical things. That was really good for us — you tend to be a lot more free when you reduce the risk, you allow yourself to innovate more, and the way you start thinking about things is: “I’ll do this here”, and then, “ah, that’s what I’ll do in this other situation, at a greater scale.” Little experiments are really important, you don’t need a 2000% efficiency-gain, mega business-critical process to make it worth doing, you just need to get comfortable thinking about this new way of operating as people in business.
And the last bit is review and revoke. I like the interface for just switching things off, it’s really easy. If you’re a parent, you’ll know what it’s like adjusting permissions for kids across a Minecraft account, Microsoft, Mojang, your own internet connection — that isn’t the case here. It feels really plain, what’s happening is surfaced well. It’s easy to go and switch things off: “why is that on? What’s the reason for that? Oh, that’s the experiment I did six months ago, switch it off then.”
[00:24:48] Rob Brighton Yeah, and I think review and revoke is an important thing. The built-in need to reconnect regularly forces that thought process — why am I reconnecting this, do I need it? Sometimes you find the connection has elapsed, you haven’t used it in a while, and going to use it again is just that prompt to think, do I still need this on the account, let alone for this particular chat?
[00:25:22] Crispin Read And, of course, you can just ask Claude what connections are on, that we could switch off.
[00:25:28] Rob Brighton Yeah, and that’s a routine I run every week.
[00:25:33] Crispin Read Awesome. So lastly, a bit of a call to action: if you haven’t connected anything yet, what’s a super low-risk, low-lift thing you can do? The example I have is, if you just connect your calendar read-only, that’s the same as me giving Rob view access to my calendar. That’s low-lift, but it starts to open things up: how many meetings could I avoid? What are my hours in meetings versus out of meetings? What does my week look like? There are things you can start doing that open up the opportunities and ideas for what happens next.
[Brief technical hiccup — slides not showing]
[00:28:44] Crispin Read So, do we have any questions, Rob?
[00:28:46] Rob Brighton We’ve got a few, yeah, a few concerns. Security and data protection are the two that came in. Security and token consumption. I think token consumption is more about the model you’re using with the connector rather than —
[00:27:20] Crispin Read Yeah, I’d say so too, and you’ve got that locked down pretty well with the tokens — for “Rob, please can I have some more pocket money” —
[00:27:31] Rob Brighton Yes.
[00:27:33] Crispin Read I think Fable 5 hasn’t helped with that at all, so we’ve got —
[00:27:37] Rob Brighton We’ve got Sam saying he’s connected to Monday but it never seems to work, which, personally, I haven’t found — I think Claude’s made Monday a lot more useful within our organisation. It might be worth a follow-up with you, Sam, to find out exactly what you were trying to do with Monday that didn’t quite work.
[00:28:02] Crispin Read Yeah, Sam, DM us and we can have a chat about that, because Monday — there was some early stuff when we first started connecting that was a bit glitchy, but it’s been absolutely fine for the past three or four months, would you say?
[00:28:20] Rob Brighton Yeah, there was a blip a few weeks ago when they put the third-party connectors into the AI settings, wrapped it up in there, and that might be what’s blocking you — we’ve had to turn on the Monday AI settings internally, which is a bit of a UI nightmare when we’re not using the AI features other than to have Claude hooked into it. But that’s probably what might be blocking you. Get in touch.
[00:28:57] Crispin Read It’s made me think, actually. Is there another question, because I’ve got a new question in my head.
[00:29:01] Rob Brighton Well, if you’ve got the question, say it, because we do have one or two more.
[00:29:08] Crispin Read Okay, well, whilst you’re looking for another one — there’s a lot of stuff we’ve done in this work, having Claude as the central business tool, that’s surfaced outside of Claude entirely. Not for Claude’s benefit, just things like, “why do we have the shared drive structure like this? It would be loads more secure if this bit of the drive was its own thing, and we moved those things to an archive.” So we’re doing stuff now that’s being surfaced, not because we’re trying to make Claude work, but because we’ve realised we don’t actually want that section of Drive going into Cowork at all — actually we don’t want that section of Drive there at all, it should go somewhere completely different. There are a few other examples too, aren’t there, Rob, where we’ve changed what we’re doing because things about our own data security and ways of working have just improved.
[00:29:56] Rob Brighton Yeah, and I think things like embedding things into your skills, which make it only look at one specific Drive subfolder or one specific board, so you can be very laser-focused about what you want it to do, and use the skill to tell it where to go.
Right, we’re running out of time. Joel said data security and trust, exposing Claude to a client list, which is their IP, is quite an interesting one.
[00:30:58] Crispin Read Yeah, I don’t know the exact nature of your stuff, but that’s similar to what I was talking about — what do I want Claude to see. Actually, another thing: the dashboarding stuff we’ve built, that should probably be another webinar, Claude Code and dashboarding. We’ve moved stuff around, created specific users for Monday.com, for example, a specific user who only has view access to certain things, and moved data around to make that more secure, and locked down other systems so the stuff we want to surface in the dashboard, which sits in the same areas as personal information, is done through a mechanism that’s locked down. Not just “hey Claude, don’t look at the secret stuff”, more like, “this is your helper to access this stuff”, and we control what it can view, read and write.
[00:32:13] Rob Brighton Right, a little bit about the connector risk call. Earlier we mentioned we have a tool internally, a skill we use to validate our connector requests, and this is a genuine tool we use inside the business. We’re allowing people to get in touch and run through a version of that skill, if you want to double-check your queries, questions and security concerns, with Francesca, and we can provide you a report tailored to your specific needs at the end of the call. Please take a screen grab, follow the link and book in a call with Francesca to run through that skill for your connectors, if you’re still a bit unsure, if we haven’t convinced you fully in the last half hour.
Of course, this stuff is also covered in the course we have running, AI Tools for Team Leaders, all of this covered across six weeks with practical learning and things you can do in your business, coached through that process yourself. If you want to do this in earnest with a bunch of other team leaders, we’ll put the link in the comments for that too.
Great — I’m not sure whether we can see the final slide, which talks about our upcoming webinars. Oh yeah, let me do it, I’m going to have to do a special manoeuvre to make it happen. Okay, so upcoming, we’ve got, which was hinted today, the automation loop that we couldn’t have done without Claude. If you’re interested in that multi-connector skilled workflow we’ve got set up, come and have a more in-depth look. We’ve had a few comments on the quality of the image, not being able to read the text, so we’ll have a live board so we can zoom into the individual components for the next one. Then after that, in August, Crispin’s going to run you through how we set up our style guide in Claude Design.
[00:34:36] Crispin Read Yeah, so that’s taking our PDF style rules and logos and building a style guide that sits in GitHub, in code, so Claude Design can pull all of that with SVGs and everything is super accurate.
[00:34:57] Rob Brighton Excellent, PDFs and all sorts. We ran a little bit over time, but I’m sure that’s fine. Thanks very much, Crispin, it was really good to have a chat with you today. I’ll resume my co-hosting duties.
[00:35:06] Crispin Read Have a lovely weekend everyone, see you again soon.
[00:35:09] Rob Brighton Thanks a lot. Bye.
