Insurance Technology Diary
Episode 51: Proper Turnoffs
Guillaume Bonnissent’s Insurance Technology Diary

Whilst on a train, I flipped open my laptop and launched a new Word document to write this edition of Insurance Technology Diary. My Office 365 package had updated since I last used it, so I was about to experience an AI-enhanced computing experience.
On cue, the new “Office Copilot” asked me to describe, in a handy text box, what I’d like to write. For a shortcut, buttons offered to “Create an outline for”, to “Create a proposal based on File”, or to “Draft document [sic] based on File”.
I typed “turn off copilot” into the ever-present search box on the bottom left (there, near your “ESC” key). That clicked open my newly updated internet browser, which – over the sloooow train WiFi – began to load not one, but two web pages.
With more irony than 10,000 spoons when all you need is a knife, the one that should have delivered my disabling instructions eventually resolved as a blank Bing window, but the other had content. Post update, it was shouting “Congrats! You now have access to Copilot vision.” A web video began to play, with all sorts of noise about “Copilot Vision in Edge”. It was like someone who’s had one too many at lunch: both annoying and embarrassing.
Far from helpful, I personally find Copilot even more infuriating than the smugly winking paper clip that used to pop up everywhere. (Him I just wanted to untwist into a strait line and poke down the hole in the arm of my chair, but that was virtually impossible.)
My message is this. Functionality – whether artificially clever or conventionally just technological – is the critical deliverable of any system. Sadly, unwanted functionality is everywhere. A man once tried to sell me a “smart” clothes dryer which I could control using my phone. I asked him to describe the circumstances where I might wish to turn on my dryer when I wasn’t standing directly in front of it with damp hands, and he showed me to a stupider model.
On another occasion, I couldn’t repair my toaster (the second most basic of kitchen appliances after the kettle) because its chip was blown. I was vaguely relieved; even with the semiconductor, my toaster’s widely variable “Colour” setting in practice delivered only ‘raw’ and ‘burnt’. Whatever functionality the chip provided, it wasn’t to do with toasting. (Cynically I suspect it was a time-delayed obsolescence device.)
And who needs a button to close the boot? I have three children. The sensors always say it’s too full, but manual override (slam!) always gets it closed. I can’t imagine anyone asked for that button, but some engineer somewhere probably earned an ‘innovation bonus’ for that pointless tech.
Functionality in insurance underwriting systems tends to come in two types: unnecessary and desired but absent. This is because users have too little input into the development of the systems they are required to rely upon, and herein lies the moral of the story.
Truly useful technology for insurance will do just what every user needs, and nothing more. That doesn’t mean that everyone’s needs must be the same. It means that:
1) all of all users’ desired functionality must be built in,
2) all the in-built functionality must be useful to someone in the business, and
2) everyone who doesn’t need specific functionality must be able to turn it off easily.
Knowing the functions that everyone needs (or doesn’t need) is a relatively straightforward task, so I am amazed that this knowledge is so rarely ascertained by platform builders. It’s shocking how often a user’s first question about a new system is “How do I get it to… ?”, and the answer is “Uh, it doesn’t do that.”
Here’s how to avoid that dramatically significant yet ever-so-common shortcoming of any system (whether for insurance or any sector). Throughout the build, garner and value the input of end users of every type. Get their feedback at every stage of the development process. This is especially true after the install, when they’re using your new tech in anger. Don’t think it’s finished when it’s in the hands of the punters. Instead, embrace the idea that they will tell you when it’s done, and how to finish it.
That means every system should be built from the start with a flexible user interface that can be tweaked to suit individual user’s needs. (Behind that, it should be designed so that every user has easy access to the data they need, and can amend it as they wish within their authority, but also so they can’t muck up anything else… but that’s another story).
The amount of time wasted daily by the global workforce trying to turn off unwanted applications is surely enough to read Decline and Fall backwards ten times over – including the footnotes. Don’t make them call in IT support. Make it easy. Give each person what they want, but don’t force them to work with the paper clip.
PS: To turn of Copilot In Windows 11 Pro:
– Launch Registry Editor, then go to:
– HKCU\Software\Policies\Microsoft\Windows
– On the left, right click on the Windows folder, go to New > Key, name it “WindowsCopilot”
– Then select WindowsCopilot, on the right, right click and create a DWORD value
– Name it “TurnOffWindowsCopilot”
– Set its value at 1.
– Restart the computer. Copilot should be grounded.
Note: this does not always work, and could irreparably damage your operating system.
