<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:media="http://search.yahoo.com/mrss/"
	>
<channel>
	<title>Simwood</title>
	<atom:link href="https://simwood.com/feed/" rel="self" type="application/rss+xml" />
	<link>https://simwood.com/</link>
	<description>Straight-talking, forward-thinking, telecoms</description>
	<lastBuildDate>Tue, 22 Sep 2026 09:53:00 GMT</lastBuildDate>
	<language>en-GB</language>
	<item>
		<title>One job in sixty years</title>
		<link>https://simwood.com/2026/09/one-job-in-sixty-years/</link>
		<dc:creator><![CDATA[Simon Woodhead]]></dc:creator>
		<pubDate>Tue, 22 Sep 2026 09:53:00 GMT</pubDate>
		<category><![CDATA[conversational-ai]]></category>
		<category><![CDATA[conversational-intelligence]]></category>
		<guid isPermaLink="true">https://simwood.com/2026/09/one-job-in-sixty-years/</guid>
		<description><![CDATA[James Bessen followed 271 US occupations from 1950 to 2010. Automation eliminated exactly one: the elevator operator. Sixty years, one job, and every panic in between. There is no equivalent register for companies, and if there were it would run to volumes.]]></description>
		<media:thumbnail url="https://simwood.com/assets/og/blog-posts-2026-09-one-job-in-sixty-years-93b23c837e.png" width="1200" height="630" />
		<content:encoded><![CDATA[<p>In July I wrote that <a href="https://simwood.com/2026/07/ai-is-an-extinction-level-event/">AI is an extinction-level event</a>, just not for the people everybody assumes. I hung it on the power loom, because the weaving numbers are about as clear as economic history gets: automation stripped 98% of the labour out of a yard of cloth, a single weaver ended up minding eighteen looms, and the number of weavers quadrupled anyway, because cloth got cheap enough that everybody wanted more of it.</p>
<p>The power loom was a British invention. Britain had around 37,000 cotton handloom weavers in 1780 and 240,000 by 1820, because mechanised spinning had made yarn cheap and somebody had to weave it. Then the power loom matured: 2,400 of them in 1812, 100,000 by 1832, 400,000 by 1860, and the share of British cotton cloth woven by power went from 5% to 95% between about 1815 and 1845. By 1860 there were 10,000 handloom weavers left. The trade grew more than sixfold and then all but vanished, in the same century, in the same county. Weaving itself multiplied. The handloom weaver did not survive it.</p>
<p>I have since gone looking for whether that was a one-off, because it is so relevant to where we are today with AI. It is not a one-off.</p>
<p>James Bessen, an economist at Boston University, took the 271 detailed occupations the US Census used in 1950 and followed every one of them through to 2010. Plenty of them disappeared. Boardinghouse keeper went because nobody wanted boardinghouses. Telegraph operator went because the telegraph went. But in exactly one case could the disappearance of an occupation be put down mainly to automation.</p>
<p>One! In sixty years! It was the elevator operator.</p>
<p>Sixty years spanning the mainframe, the minicomputer, the PC, the spreadsheet, the industrial robot, the barcode, the ATM/cash-machine, the internet and the smartphone. Every one of them arrived with a confident, specific, published list of the jobs it was about to erase. The count after six decades is just one.</p>
<p>Bessen's own conclusion is the part worth noting: that period saw enormous automation, and almost all of it was <em>partial</em>. Machines took <em>tasks</em>. They did not take <em>occupations</em>.</p>
<h2>The ATM/cash-machine</h2>
<p>The bank teller was the prediction everyone was most sure about.</p>
<p>A machine that dispenses cash and takes deposits does the visible part of a teller's job, faster, at three in the morning, for no wage. Over 400,000 of them went into the US. The number of tellers employed went <em>up</em>, from roughly 500,000 around 1980 to roughly 550,000 by 2010.</p>
<p>The mechanism is the thing, not the outcome. Bessen measured that the number of tellers needed to run the average urban branch fell from twenty to thirteen between 1988 and 2004. A branch that needs seven fewer people is a branch you can afford to open in places that could never previously carry one, so the banks opened them: urban branches up 43%. More branches needed more tellers in total, and those tellers spent their day on relationships and selling rather than counting notes, which was the part the machine could not touch.</p>
<p>Same arithmetic as the power loom, a century later, in a service industry, which is the harder case. Automation makes a unit of output cheap. Cheap output gets bought in far greater quantity. Greater quantity needs more people, doing the part that was never the bit being automated. The mechanism has a name and it long predates any of this: William Stanley Jevons pointed out in 1865 that every improvement in the efficiency of the steam engine raised Britain's total coal consumption rather than lowering it, because cheaper coal found more uses than the efficiency saved. Jevons paradox is the loom and it is the ATM, and it has been running underneath every automation panic since.</p>
<p>The end of the teller story is less comfortable. The effect ran out. US teller employment peaked around 2007 and is down to roughly 347,000, with another 13% decline forecast to 2034. What finally did it was online and mobile banking, not the ATM: a change in what customers wanted to do at all, rather than a machine doing the same job cheaper. Thirty years of automation grew the job. A change in demand shrank it. Those are different causes and it matters enormously which one you think you are facing.</p>
<p>None of which is American, incidentally. The first cash machine in the world went into the wall of Barclays in Enfield on 27 June 1967, built by De La Rue to John Shepherd-Barron's idea, dispensing £1 notes against a cheque impregnated with carbon 14. By the time the Bank of England reviewed twenty years of the major British banks in 1991, ATMs roughly equalled branches and about 60% of retail deposit withdrawals went through them, and the Bank's own account of what that did to staffing was this: rapid growth in staff numbers over most of the 1970s and 1980s, with investment in technology &quot;helping replace staff in back-office processing tasks, releasing them for front-office sales tasks&quot;. That is Bessen's finding, in the Bank of England's words, a quarter of a century before he published it. The British version differs in one respect. Our branch numbers were already falling while American ones rose, so we got the reallocation without the branch expansion that drove the headcount growth over there. The ending is the same as well: bank and post office clerks are down 83,000 since 2001, and nobody blames the cash machine for that either.</p>
<h2>The jobs are not the same jobs</h2>
<p>So the honest version of what I argued in July is not &quot;your job is safe&quot;.</p>
<p>David Autor and his colleagues at MIT went through eight decades of US occupation data and found that roughly 60% of all employment in 2018 sat in job titles that did not exist in 1940. Among professional occupations it was 74%. Not jobs that had evolved - job titles that had to be invented, because the work had not previously existed to be described.</p>
<p>The British series runs longer and says the same thing. Deloitte's economists went through the census of England and Wales for every decade since 1871 and found agricultural labourers down from 6.6% of the workforce to 0.2%, and 200,000 people washing clothes for a living in 1901 against 35,000 in 2011, in a population that had gone from 32.5 million to 56.1 million. What replaced them was not nothing. Accountants went from 9,832 in 1871 to 215,678. There is now one hairdresser or barber for every 287 people in England and Wales, against one for every 1,793 in 1871. The caring professions went from 1.1% of employment to 12.2%, and the muscle-power trades from 23.7% to 8.3%. Weavers and knitters, since we started there, were down to 4,961 by 2014 from 24,009 in 1992, over a period when total UK employment rose 23%. And after a century and a half of all of that, the ONS puts the three highest employment rates in its entire 1861 to 2018 record in 1872, 1943 and 2018, all at 76% of the working-age population.</p>
<p>The work is safe and expanding. The job description is not.</p>
<p>And before anyone in telecoms takes any comfort from Bessen's number, I should point out that our industry ran the single largest counter-example in the data. Between 1920 and 1940 AT&amp;T automated mechanical switching across more than half of the US telephone network and destroyed the telephone operator, which was then one of the largest occupations open to young women in America. In the cities that cut over, operator employment among 16 to 25 year old women fell by between a half and four fifths.</p>
<p>Feigenbaum and Gross went and looked at what happened to those people. The cohorts that followed were fine: the jobs came back as clerical and service work, including categories of work that had not existed before. The women already doing the job were not fine. A decade later they were disproportionately in lower-paid occupations or out of work altogether.</p>
<p>That is precisely the handloom weaver, and it is the reason I keep saying the technology is not what ruins anybody. Weaving boomed. Telephony boomed beyond anything the operators could have imagined. What got destroyed in both cases was the people and the businesses that kept doing it the old way while the world reorganised around them.</p>
<h2>Where the new work actually comes from</h2>
<p>Which leaves the question nobody in this debate ever asks. If automation keeps making things cheaper, and employment keeps going up, where is the extra work coming from? It cannot all be the same people buying more of the same thing.</p>
<p>Clayton Christensen named it in <em>The Innovator's Solution</em> in 2003: the growth does not come from competing for customers who are already buying. It comes from competing against <strong>non-consumption</strong>. The people who were not in the market at all, because the thing cost too much, took too long, or needed an expert they could not get hold of. Make it cheap and simple enough and an industry appears where there was not one, and that is where the unpredictable new job titles come from. You cannot forecast an occupation that serves a market which does not yet exist.</p>
<p>Which is the bit Jevons does not cover. Jevons is the same good, cheaper, bought in far greater quantity; non-consumption is demand that was never in the market to be counted.</p>
<p>It is also exactly why incumbents read all of this backwards. Christensen's real finding was never about technology. It was that thoroughly competent people, inside a business whose cost base demands a certain margin, will reflexively screen out the low-margin opportunity that creates the new market, and will explain very persuasively why they were right to. &quot;AI is for our customers to build&quot; is that sentence, dressed for work. My colleague Peter has written about <a href="https://simwood.com/2026/06/the-four-ai-strategies-of-our-time/">the four AI strategies currently on display</a> and they are all recognisable from this one insight.</p>
<h2>The non-consumption in our industry is the conversation</h2>
<p>Telecoms is sitting on one of the largest pools of non-consumption I have ever seen, and most of the industry is looking straight past it.</p>
<p>Email is indexed. Chat is logged. The CRM is structured and reportable. And the conversation, which is where customers state what they actually want, where compliance is met or missed, where fraud is attempted and where emergencies are declared, has historically produced a recording nobody ever listened to. Not for want of wanting to. Reviewing an hour of calls costs an hour of a person, so every business on earth reviews a token sample and bins the rest.</p>
<p>That is not a market being served badly. It is a market that has never existed. Almost every conversation your business has ever had went unexamined, and everyone quietly accepted that as the natural order of things.</p>
<p>Make it cheap and you do not get a smaller contact centre. That is the ATM mistake, it is the Klarna mistake, and it is sitting in a lot of board packs right now. What you get is a contact centre doing things it could not previously attempt at all: <a href="https://simwood.com/2026/07/operators-turning-a-call-into-structured-signals-your-systems-can-act-on/">signals that fire while the call is still happening</a>, guidance arriving in a handler's ear mid-conversation, <a href="https://simwood.com/2026/07/introducing-conversation-intelligence-the-carrier-advantage-nobody-else-has/">the conversation becoming a record that compounds</a> rather than a file nobody opens. The handler with an Operator watching their call is not a cheaper handler. They are a better one than they could ever be unaided, and the work that creates is new work, not recovered work.</p>
<p>We built it on that principle and we <a href="https://simwood.com/2026/07/the-ai-accelerated-build-how-this-platform-was-designed-documented-and-shipped/">built it that way ourselves</a>, right down to <a href="https://simwood.com/2026/07/kaizen-that-remembers/">the internal plumbing nobody sees</a>. Amplify the people. Do not replace them.</p>
<h2>What the elevator operator was actually for</h2>
<p>Come back to the one job that did go, because the reason it went is the warning, and it is not the warning people take from it.</p>
<p>The elevator operator did not lose to a cheaper elevator operator. They lost because the entire job <em>was</em> the interface. Their function was to be the human who pressed the button on the passenger's behalf, and the moment the passenger could press it themselves there was nothing underneath. Every other occupation on Bessen's list had judgement wrapped around a task. Automate the task and the judgement is still there, now applied across far more surface area than before, which is what happened to the weaver, to the teller, and to the generation that followed the switchboard.</p>
<p>So the question is not whether AI can do part of what you do. It can, and sixty years of census data says that has never once been enough on its own. The question is whether there is anything underneath. If your whole contribution is standing between a customer and a capability, passing the request along and adding a margin for the service of pressing the button, you are not a business facing disruption. You are an elevator operator, and I have <a href="https://simwood.com/2025/09/the-rise-and-fall-of-the-knuckle-dragger/">written about your customers before</a>.</p>
<p>Which is the point, and the reason July's post said what it said. Sixty years, one occupation eliminated. There is no equivalent register for companies, and if there were it would run to volumes. Automation has been extraordinarily kind to workers and utterly ruthless with firms, and everybody in this industry asking &quot;how many people can this replace&quot; is asking the question that has been reliably wrong since 1950, while ignoring the one that has been reliably right.</p>
<p>The asteroid was never aimed at your staff. It has your slower competitors' names on it, and if you stand still long enough, yours.</p>
<p>So: what is under your button?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Announcing AI pricing</title>
		<link>https://simwood.com/2026/09/announcing-ai-pricing/</link>
		<dc:creator><![CDATA[Simon Woodhead]]></dc:creator>
		<pubDate>Mon, 14 Sep 2026 15:25:00 GMT</pubDate>
		<category><![CDATA[commercial]]></category>
		<guid isPermaLink="true">https://simwood.com/2026/09/announcing-ai-pricing/</guid>
		<description><![CDATA[We are delighted to announce pricing for Conversational AI and Conversation Intelligence. This will apply when they are announced out of beta, which depends on a billing engine upgrade; usage remains free until then.]]></description>
		<media:thumbnail url="https://simwood.com/assets/og/blog-posts-2026-09-announcing-ai-pricing-369487b999.png" width="1200" height="630" />
		<content:encoded><![CDATA[<p>A big thank you to those of you who have been building on our <a href="https://simwood.com/conversational-ai/">Conversational AI</a> (a.k.a. agents) and <a href="https://simwood.com/conversation-intelligence/">Conversation Intelligence</a> (a.k.a. in-call analysis) beta releases. We’re seeing some very interesting use cases and huge enthusiasm, which we love. We can’t wait to see your products in the hands of end-users and making a difference in their lives and business - it is why we do what we do.</p>
<p>To that end, we have one humongous project ongoing in relation to Carrier Services billing. Our call billing is mature and untouched but when it comes to other things, like billing number rentals, trunk charges etc. it is overly simplistic. Not the kind of simplistic that gets marketed as ground-breaking, but simplistic enough to have been a major constraint over the years. It just isn’t right that we can solve technical problems only to be constrained by billing agility and while the early temptation is always to deal with exceptions one-by-one, over time that becomes an unmanageable knot. So, for perhaps the last decade, we’ve just accepted the constraint. No more - newer services have so many moving parts and we need to be able to bill like a software company, not be wedded to the very deep but very narrow paradigm of telephony billing. That means bundles, allowances, multiple meters, bespoke subscriptions and all manner of good stuff. That is an ongoing project whose first outing is AI and WhatsApp (before taking over billing existing services), meaning we have a blank canvas. Yay!</p>
<p>Billing this stuff is complicated and when we first started on this journey a few years ago, we wanted to simplify it. It was so insanely complicated it was nigh on impossible to tell what a service was going to actually cost. That’s fair enough for a hobby project, not for building a business on. Along the way we’ve seen multiple providers dramatically change pricing and either row back or publicly apologise. We’re not even into enshitification yet, they seem to be just trying to optimise what they can grab. That isn’t our style but we’ve come to appreciate that simplification dramatically raises risk and either leads to all customers funding the edge cases, or us taking massive arbitrage risk. Best value comes from us exposing some complexity, offset by that which is eliminated by Simwood’s unique position (the only actual carrier globally offering these services on-net), and pricing in a way that enables our customers to price in a genuinely competitive way against those seeking to underpin a bubble!</p>
<p>So, our pricing has 5 moving parts, well, 6 if you consider the big bit that isn’t there - telephony. You don’t need to deal with a reseller of a carrier and pay 2c a minute for the privilege, because all our services are on-net on calls you already pass, on numbers you already have. You can use <a href="https://simwood.com/byoc/">BYoC</a> if you’re unlucky enough to have numbers locked into a dinocarrier or the mustard morons, but porting to Simwood is within your gift there.</p>
<p>As to the remaining, we’re offering 4 tiers of service and these are available to any production Carrier Services account and are unaffected by service level (Virtual Interconnect, Managed Interconnect, etc.) as the economic benefits of those are exposed through telephony and we want to encourage innovation and growth here. Each tier trades a monthly subscription against consumption economics, but even at the headline lowest commit level, you should be able to compete with any of the bubble-operators. At the top-end, we have completely bespoke pricing for those achieving scale or looking to bring on a 1,000-seat call centre or two. The per minute rate covers all agent and intelligence functions and there is a generous allowance baked into the subscription, the subscription being the cheapest way to buy those minutes. This covers the core functions of our agents: listening, speaking.</p>
<p>The notable exception here is ‘thinking’, i.e. the LLM costs and this is where the real complexity lies. Different models have dramatically different economics, and different customers or end-user profiles have dramatically different consumption patterns - we’ve proved this in the beta. Trying to blend these leads to us overcharging you or taking on significant risk, with fairness being an edge case. So instead, just as you can choose your model, we’re going to be passing on LLM costs at cost. That includes the substantial benefit from LLM-caching, where it is achievable. BYoLLM is on our list but you get the economic benefits of that from day one. The remaining benefit is really operational, e.g. charges at the same rate on your Anthropic bill rather than ours.</p>
<p>There is another critical function which is a huge Simwood USP and that’s ‘remembering’ - storing your knowledgebases for agents or indexing past conversations for state. Other providers are severely limited here, both in terms of functionality and price. ElevenLabs for example will (crudely in our opinion) apply a limit across the entire account - pretty useless - from 2MB up to 1GB on published plans. To access 1GB you’d be spending $990 a month and $0.08 per minute. Twilio is more generous - they’ll charge you $0.018 per GB per hour for as much as you like - so $1,296 for 100GB, before you retrieve any of it at $0.005 per time! We’re storing and indexing on-net, and are not grotesquely greedy, so we’re allowing as much storage as you need with charging storage at a sensible rate, i.e. £0.0018/GB/hour. Furthermore, unlike others, we’ll only charge based on the original document, not the multiple of that after vectorisation!</p>
<p>The final moving part is concurrency and this one is hard. Nobody in the market is overt about their limits and true constraints; it is all fuzzy language and obfuscation. Concurrency risks being incredibly expensive, particularly as we progress to full on-net processing, so we need to find a balance. Accordingly, every tier comes with a small number of included concurrent channels and additional channels can be purchased on top. These are account level limits which you will be able to divide and contend by trunks as you do with other limits on Simwood accounts. They will all be best-effort and have a hard limit, in the interests of fairness. Until POA territory these will be the same rate regardless of subscription level.</p>
<p>So, that’s a subscription which includes minutes, overage at a rate which reflects the subscription, included levels of concurrency increasing with subscription, and the ability to scale that as you need. Oh, and LLM usage at cost - you pick the model and entirely control your own cost profile.</p>
<table>
<thead>
<tr>
<th style="text-align:left">Plan</th>
<th style="text-align:left">Monthly</th>
<th style="text-align:left">Concurrent channels</th>
<th style="text-align:left">Included minutes (Conversational AI / Conversation Intelligence)</th>
<th style="text-align:left">Minutes above that</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:left">Try</td>
<td style="text-align:left">£0</td>
<td style="text-align:left">5</td>
<td style="text-align:left">0</td>
<td style="text-align:left">6.00p</td>
</tr>
<tr>
<td style="text-align:left">Build</td>
<td style="text-align:left">£50</td>
<td style="text-align:left">10</td>
<td style="text-align:left">1,250</td>
<td style="text-align:left">5.00p</td>
</tr>
<tr>
<td style="text-align:left">Run</td>
<td style="text-align:left">£300</td>
<td style="text-align:left">20</td>
<td style="text-align:left">10,000</td>
<td style="text-align:left">4.00p</td>
</tr>
<tr>
<td style="text-align:left">Bespoke</td>
<td style="text-align:left">POA</td>
<td style="text-align:left">POA</td>
<td style="text-align:left">POA</td>
<td style="text-align:left">POA</td>
</tr>
</tbody>
</table>
<p>Additional concurrent channels £5 a month each, same price on every plan. LLM tokens passed through at provider cost on every plan.</p>
<p>While LLM costs will be passed through at cost it is helpful to record what those costs are (at the time of writing) for anyone wanting to benchmark; the tables are at the end of this post. These are in USD so will vary for billing in GBP. For reference, if you’ve been using our services in beta, you will have used Gemini 2.5 Flash, GPT 4.1 or 5 Mini for Conversational AI and Haiku and Sonnet for Conversation Intelligence. Frontier models are available but absolutely not required. E&amp;OE of course, and these <em>will</em> change, not least due to promotions, new models etc. One worth knowing today: Google’s current Gemini 3.x Flash pricing is promotional and doubles on 1 January 2027, and because we pass cost through, that increase reaches you.</p>
<p>Last but by no means least, we need to talk about data residency. Our ultimate aim is for all of this processing to occur on-net and we’re quietly moving towards that. We don’t intend to narrate every element as in all likelihood the transition will require hybrid working, but where this stuff is processed matters to customers and we know some are using it as a selling point. In every case possible, we are electing for UK processing first, EU if the UK is not available. Google don’t allow nomination but their services are anycast so logically we will naturally be using UK and EU instances first. When it comes to T&amp;Cs however, we think it is more important that services work, so we will permit a fall-back to other instances (e.g. the USA) in the event of the preferred instance not being available.</p>
<p>We hope you’ll share our excitement at this and, naturally, look forward to feedback in our Community Slack or via account managers. When comparing, please do look at others like Twilio, ElevenLabs, Vapi, Retell etc. In every case they either can’t provide, or charge separately for, the connectivity, and the basic costs are substantially higher than ours - you guys should be able to compete with any of them on this pricing before we get into bespoke pricing for legitimate scale.</p>
<p>Finally, as regards timing, the billing is the remaining constraint here. As soon as that is done, these products will come out of beta, and we estimate that’ll be this quarter as billing is a Q3 objective and Charles doesn’t miss! Pete on the other hand…</p>
<p>**</p>
<p><strong>LLM pass-through rates</strong></p>
<p>Tokens are passed through at provider cost, so these are costs, not prices. Per 1,000,000 tokens, from each provider’s own pricing page, retrieved 11 September 2026. FX GBP 0.740295 to USD 1.00, ECB reference rates, 11 September 2026, one rate in every row.</p>
<p><strong>Fast, the live turn loop</strong></p>
<table>
<thead>
<tr>
<th style="text-align:left">Model</th>
<th style="text-align:left">Provider</th>
<th style="text-align:left">In $</th>
<th style="text-align:left">Out $</th>
<th style="text-align:left">In £</th>
<th style="text-align:left">Out £</th>
<th style="text-align:left">Cache write $, full cost</th>
<th style="text-align:left">Cache read $</th>
<th style="text-align:left">Min tokens to cache</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:left">GPT-5.6 Luna</td>
<td style="text-align:left">OpenAI</td>
<td style="text-align:left">0.20</td>
<td style="text-align:left">1.20</td>
<td style="text-align:left">0.15</td>
<td style="text-align:left">0.89</td>
<td style="text-align:left">0.25</td>
<td style="text-align:left">0.02</td>
<td style="text-align:left">1,024</td>
</tr>
<tr>
<td style="text-align:left">Gemini 3.1 Flash-Lite</td>
<td style="text-align:left">Google</td>
<td style="text-align:left">0.25</td>
<td style="text-align:left">1.50</td>
<td style="text-align:left">0.19</td>
<td style="text-align:left">1.11</td>
<td style="text-align:left">not available</td>
<td style="text-align:left">not available</td>
<td style="text-align:left">not available</td>
</tr>
<tr>
<td style="text-align:left">Gemini 3.5 Flash-Lite</td>
<td style="text-align:left">Google</td>
<td style="text-align:left">0.30</td>
<td style="text-align:left">2.50</td>
<td style="text-align:left">0.22</td>
<td style="text-align:left">1.85</td>
<td style="text-align:left">not available</td>
<td style="text-align:left">not available</td>
<td style="text-align:left">not available</td>
</tr>
<tr>
<td style="text-align:left">Claude Haiku 4.5</td>
<td style="text-align:left">Anthropic</td>
<td style="text-align:left">1.00</td>
<td style="text-align:left">5.00</td>
<td style="text-align:left">0.74</td>
<td style="text-align:left">3.70</td>
<td style="text-align:left">1.25</td>
<td style="text-align:left">0.10</td>
<td style="text-align:left">4,096</td>
</tr>
</tbody>
</table>
<p><strong>Standard, a capable agent turn and post-call analysis</strong></p>
<table>
<thead>
<tr>
<th style="text-align:left">Model</th>
<th style="text-align:left">Provider</th>
<th style="text-align:left">In $</th>
<th style="text-align:left">Out $</th>
<th style="text-align:left">In £</th>
<th style="text-align:left">Out £</th>
<th style="text-align:left">Cache write $, full cost</th>
<th style="text-align:left">Cache read $</th>
<th style="text-align:left">Min tokens to cache</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:left">Gemini 2.5 Flash</td>
<td style="text-align:left">Google</td>
<td style="text-align:left">0.30</td>
<td style="text-align:left">2.50</td>
<td style="text-align:left">0.22</td>
<td style="text-align:left">1.85</td>
<td style="text-align:left">not available</td>
<td style="text-align:left">not available</td>
<td style="text-align:left">not available</td>
</tr>
<tr>
<td style="text-align:left">Gemini 3.8 Flash</td>
<td style="text-align:left">Google</td>
<td style="text-align:left">0.75</td>
<td style="text-align:left">3.75</td>
<td style="text-align:left">0.56</td>
<td style="text-align:left">2.78</td>
<td style="text-align:left">0.75</td>
<td style="text-align:left">0.075</td>
<td style="text-align:left">4,096</td>
</tr>
<tr>
<td style="text-align:left">Gemini 3.5 Flash</td>
<td style="text-align:left">Google</td>
<td style="text-align:left">1.50</td>
<td style="text-align:left">9.00</td>
<td style="text-align:left">1.11</td>
<td style="text-align:left">6.66</td>
<td style="text-align:left">1.50</td>
<td style="text-align:left">0.15</td>
<td style="text-align:left">4,096</td>
</tr>
<tr>
<td style="text-align:left">Claude Sonnet 5</td>
<td style="text-align:left">Anthropic</td>
<td style="text-align:left">2.00</td>
<td style="text-align:left">10.00</td>
<td style="text-align:left">1.48</td>
<td style="text-align:left">7.40</td>
<td style="text-align:left">2.50</td>
<td style="text-align:left">0.20</td>
<td style="text-align:left">1,024</td>
</tr>
<tr>
<td style="text-align:left">GPT-5.6 Terra</td>
<td style="text-align:left">OpenAI</td>
<td style="text-align:left">2.00</td>
<td style="text-align:left">12.00</td>
<td style="text-align:left">1.48</td>
<td style="text-align:left">8.88</td>
<td style="text-align:left">2.50</td>
<td style="text-align:left">0.20</td>
<td style="text-align:left">1,024</td>
</tr>
<tr>
<td style="text-align:left">Claude Sonnet 4.6</td>
<td style="text-align:left">Anthropic</td>
<td style="text-align:left">3.00</td>
<td style="text-align:left">15.00</td>
<td style="text-align:left">2.22</td>
<td style="text-align:left">11.10</td>
<td style="text-align:left">3.75</td>
<td style="text-align:left">0.30</td>
<td style="text-align:left">1,024</td>
</tr>
</tbody>
</table>
<p><strong>Frontier</strong></p>
<table>
<thead>
<tr>
<th style="text-align:left">Model</th>
<th style="text-align:left">Provider</th>
<th style="text-align:left">In $</th>
<th style="text-align:left">Out $</th>
<th style="text-align:left">In £</th>
<th style="text-align:left">Out £</th>
<th style="text-align:left">Cache write $, full cost</th>
<th style="text-align:left">Cache read $</th>
<th style="text-align:left">Min tokens to cache</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:left">Gemini 2.5 Pro, to 200k</td>
<td style="text-align:left">Google</td>
<td style="text-align:left">1.25</td>
<td style="text-align:left">10.00</td>
<td style="text-align:left">0.93</td>
<td style="text-align:left">7.40</td>
<td style="text-align:left">1.25</td>
<td style="text-align:left">0.125</td>
<td style="text-align:left">2,048</td>
</tr>
<tr>
<td style="text-align:left">Gemini 3.1 Pro Preview, to 200k</td>
<td style="text-align:left">Google</td>
<td style="text-align:left">2.00</td>
<td style="text-align:left">12.00</td>
<td style="text-align:left">1.48</td>
<td style="text-align:left">8.88</td>
<td style="text-align:left">2.00</td>
<td style="text-align:left">0.20</td>
<td style="text-align:left">4,096</td>
</tr>
<tr>
<td style="text-align:left">Claude Opus 5</td>
<td style="text-align:left">Anthropic</td>
<td style="text-align:left">5.00</td>
<td style="text-align:left">25.00</td>
<td style="text-align:left">3.70</td>
<td style="text-align:left">18.51</td>
<td style="text-align:left">6.25</td>
<td style="text-align:left">0.50</td>
<td style="text-align:left">512</td>
</tr>
<tr>
<td style="text-align:left">GPT-5.6 Sol</td>
<td style="text-align:left">OpenAI</td>
<td style="text-align:left">5.00</td>
<td style="text-align:left">30.00</td>
<td style="text-align:left">3.70</td>
<td style="text-align:left">22.21</td>
<td style="text-align:left">6.25</td>
<td style="text-align:left">0.50</td>
<td style="text-align:left">1,024</td>
</tr>
<tr>
<td style="text-align:left">Claude Fable 5.1</td>
<td style="text-align:left">Anthropic</td>
<td style="text-align:left">10.00</td>
<td style="text-align:left">50.00</td>
<td style="text-align:left">7.40</td>
<td style="text-align:left">37.01</td>
<td style="text-align:left">12.50</td>
<td style="text-align:left">0.25</td>
<td style="text-align:left">512</td>
</tr>
</tbody>
</table>
<p><strong>A note on caching.</strong> Google charge no premium to write a cache, so their write figure is simply the standard input rate, and the storage charge they publish applies to caches you choose to store rather than the automatic caching in use here, so there is nothing extra to pass on. Where a model is marked not available, Google publish no cached rate for it at all, so there is no caching benefit to pass through at any price. The minimum matters as much as the rate: below it a request is simply processed uncached, with no error and no warning.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Carrier Services rate update (2026-09-17)</title>
		<link>https://simwood.com/rates/</link>
		<pubDate>Thu, 10 Sep 2026 15:49:00 GMT</pubDate>
		<guid isPermaLink="false">https://simwood.com/rates/#1789055340000</guid>
		<description><![CDATA[We will be updating our Managed A-Z Termination rates and codes on September 17th 2026. As usual, these changes are colour-coded in our full rate files available through the portal as below. Where your account has custom rates, these are now reflect…]]></description>
		<media:thumbnail url="https://simwood.com/assets/og/pages-rates-28085ca35a.png" width="1200" height="630" />
		<content:encoded><![CDATA[<p>We will be updating our Managed A-Z Termination rates and codes on <strong>September 17th 2026.</strong></p>
<p>As usual, these changes are colour-coded in our full rate files available through the portal as below. Where your account has <a href="/2024/04/custom-rates/">custom rates</a>, these are now reflected in the rate files. Remember, if you'd like more granular prefixes (inc. NPA-NXX) or a more compact rate file, <a href="/2023/08/more-call-tariff-options-including-npa-xx/">we've got you covered</a>.</p>
<p>Unlike other operators, we are not passing on UK origin surcharges, relying instead on our advanced technology to protect you and us from this industry's latest sleazy money-grab. We will maintain this position as long as possible so our customers do not need to worry.</p>
<p><strong>Rate files</strong>
Full rate sheets with codes are now only available through the <a href="https://portal.simwood.com/">portal</a> or from our <a href="https://developer.simwood.com/docs/wholesale/api/v3/">API</a> for active customers. Once logged in to the portal you can find them in the &quot;commercial&quot; section.</p>
<p>The SMS A-Z rate sheet is now available on our portal or via API.</p>
<p>Please contact our sales team if you are not a customer and would like to see our rates.</p>
<p><strong>Ancillary charges (inc. SMS &amp; fax)</strong>
Our charges for ancillary services can be found <a href="https://cdn.simwood.com/docs/simwood_ancillary_charges.pdf">here</a>.</p>
<p><strong>100% SLA</strong>
Our Service Level Agreement (SLA) for our UK carrier services customers is a guarantee of 100% Simwood service availability. Read more <a href="https://cdn.simwood.com/docs/simwood_SLA.pdf">here</a>.</p>
<p><strong>MSA</strong>
Our MSA is <a href="https://cdn.simwood.com/docs/simwood_msa.pdf">here</a>.</p>
<p><strong>Acceptable use policy</strong>
Our AUP is <a href="https://cdn.simwood.com/docs/simwood_aup.pdf">here</a>.</p>
<p><strong>Hardware supply schedule</strong>
Our Hardware supply schedule is <a href="https://cdn.simwood.com/docs/hardware_%20supply_schedule.pdf">here</a>.</p>
<p><strong>Hosted pricing</strong>
Looking for Hosted pricing? Click <strong><a href="/hosted-price-plans/">here</a></strong>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Eight Years On</title>
		<link>https://simwood.com/2026/09/eight-years-on/</link>
		<dc:creator><![CDATA[Charles Chance]]></dc:creator>
		<pubDate>Thu, 10 Sep 2026 13:19:00 GMT</pubDate>
		<category><![CDATA[inside-simwood]]></category>
		<guid isPermaLink="true">https://simwood.com/2026/09/eight-years-on/</guid>
		<description><![CDATA[Hi. I'm Charles. I'm Simwood's CTO, which means I'm accountable for the technology across the group: the network, the platforms that run on it, and the teams that build both.
Some of you have known me for a long time. There's a post from 2018 in which I answered questions much like these as the founder of a company called Sipcentric. It's still online, which is either brave or careless! Reading it back was a useful exercise. Most of what I said then, I would still say now. The scale is what changed.
]]></description>
		<media:thumbnail url="https://simwood.com/assets/og/blog-posts-2026-09-eight-years-on-b371d63ff0.png" width="1200" height="630" />
		<content:encoded><![CDATA[<p>Hi. I'm Charles. I'm Simwood's CTO, which means I'm accountable for the technology across the group: the network, the platforms that run on it, and the teams that build both.</p>
<p>Some of you have known me for a long time. There is
<a href="https://www.nimvelo.com/2018/07/meet-team-charles/" rel="nofollow">a post from 2018</a> where I answered much the same questions much like these as the founder of a company called Sipcentric. It's still online, which is either brave or careless! Reading it back was a useful exercise. Most of what I said then, I would still say now. The scale is what changed.</p>
<h2>The long way round</h2>
<p>My route into telecoms was not direct. Before any of this I had launched an online trading company and an IT consultancy, built a small property portfolio, and opened a couple of bars. I have always been more interested in businesses and people than in any single technology, but IT and telecoms was where my expertise sat, and internet-based communications was where the interesting problems were.</p>
<p>Sipcentric was formed in late 2010, and we rebranded to Nimvelo in 2015. Over nine years we built <a href="https://simwood.com/hosted-pbx/">a hosted platform</a>, and the team to run it, without any significant outside investment. That constraint shaped everything. When there is no funding round to hide behind, you architect carefully, because you are the one who will be supporting it at 2am.</p>
<p>I also said in 2018 that we were working on something new, that I could not say much about it, and that its purpose was to help teams have more productive conversations. Hold that thought.</p>
<h2>October 2019</h2>
<p>Simwood <a href="https://www.commsbusiness.co.uk/content/news/simwood-completes-double-acquisition">acquired Sipcentric</a> in October 2019. Simon was characteristically direct about why: he reckoned we had built the best-architected hosted platform in the market and that almost nobody had noticed.</p>
<p>Shortly afterwards I <a href="https://simwood.com/2019/12/management-changes-2/">stepped up to Group CTO</a>, a role Simwood had not had before. Going from running your own company to running technology inside a larger one is a genuine change, and it takes some adjusting to. What made it work was that this was not the usual sort of acquisition. Several of the Sipcentric team took senior positions in the combined business rather than being absorbed and quietly forgotten. David Maitland, who <a href="https://simwood.com/2026/03/learning-telecoms-by-doing/">wrote in this series back in March</a>, was Sipcentric's second employee at nineteen and is still here running infrastructure and systems. That says more about how the two companies fitted together than any press release did.</p>
<p>What I gained was scale, and colleagues who had been <a href="https://simwood.com/our-network/">operating networks</a> at serious scale since 1996. What Simwood gained, I hope, was a platform team used to shipping.</p>
<h2>What the job actually is</h2>
<p>I am responsible for the ongoing reliability and interoperability of every network across the group, and for the products we build on top of them. In practice the work splits three ways: keeping what exists running properly, building what comes next, and making sure the people doing both have what they need to get on with it.</p>
<p>The middle one gets the blog posts. The first one is where the credibility comes from.</p>
<p>A lot of that foundation is decidedly unglamorous. Database clusters that need to fail over cleanly rather than theoretically. Identity and single sign-on, migrated without locking anyone out. An intermittent lock-up that only ever appears in production, under real traffic, at the least convenient hour. None of it makes a good headline. All of it is the reason customers can put us in the call path and not think about us again.</p>
<p>Some of it has been running longer than the products it now supports. Kamailio has been in Simwood's stack since 2005, and it is still there, doing the same job in a completely different architecture. I told that story <a href="https://simwood.com/2026/05/twenty-years-one-constant-kamailio-at-the-heart-of-a-changing-stack/">on stage at Kamailio World</a> in May: twenty years of change with one constant in the middle of it. Contributing back to the open-source projects we depend on matters to me. We would not have a business without them.</p>
<h2>Back to that thought</h2>
<p>In 2018 I was talking about helping small teams have better conversations, from inside a PBX. Today the AI engineering team and I are building <a href="https://simwood.com/conversation-intelligence/">Conversation Intelligence</a>, which does something similar from an entirely different place: <a href="https://simwood.com/2026/07/introducing-conversation-intelligence-the-carrier-advantage-nobody-else-has/">the carrier layer</a>.</p>
<p>Media is <a href="https://simwood.com/2026/07/real-time-intelligence-at-the-carrier-layer-how-the-media-tap-works/">tapped passively at the network layer</a> and mirrored into an AI pipeline. Nothing touches the call, nothing adds latency, and nothing routes through a third party, because we are the carrier and it is our network. <a href="https://simwood.com/2026/07/operators-turning-a-call-into-structured-signals-your-systems-can-act-on/">Operators</a> watch the transcript as it unfolds and emit typed signals — a fraud score, a detected intent, a compliance flag. Those signals fire webhooks into your platform mid-call, or whisper guidance to the handler while they are still talking. Every conversation becomes <a href="https://simwood.com/2026/07/conversation-memory-and-vcon-the-intelligence-that-compounds-over-time/">a vCon</a>, an open IETF-standard record, held in your storage rather than ours. We genuinely do not want your data.</p>
<p>The pitch is simple: act while the call is still happening, instead of finding out next quarter. <a href="https://simwood.com/fraud-protection/">Fraud caught</a> before the transfer is authorised. A missed disclosure prompted before the call ends. If you would rather read endpoints than prose, it is all in <a href="https://docs.simwood.com">the developer docs</a>.</p>
<p>Different scale, same idea I had eight years ago. It only works now because we own the whole stack, which is precisely what the 2019 deal put together.</p>
<h2>How I try to work</h2>
<p>My answer in 2018 was that I liked being one of the team and would never expect anyone to do something I would not do myself. That has not changed, and it is easier to live by here than it was, because Simwood already worked that way.</p>
<p>What I would add now is a preference for candour. I want to know the difference between what we have shipped and what we intend to ship, in plain terms, early. Optimism about a roadmap is fine. Confusing it with the current state of production is not, and it is the fastest way I know to lose a customer's trust. The same goes upwards: if I am wrong, I would rather be told in the room than discover it in an incident review.</p>
<p>The flip side is ownership. Nobody here waits to be told to fix something they can see is broken, and that is recognised rather than merely expected. You will find the same theme running through most of <a href="https://simwood.com/category/inside-simwood/">the posts in this series</a>.</p>
<h2>Away from the network</h2>
<p>Home is a few rural acres, which supplies a reliable stream of problems that cannot be solved with more compute. There is a garage block mid-conversion and a planning process attached to it, so I have developed a new appreciation for systems where the specification is deliberately ambiguous. The rest of my time belongs to my family, who are unmoved by SIP.</p>
<h2>Still here</h2>
<p>Eight years on from that first post, and seven from the acquisition, I am still doing a version of the same job: building communications infrastructure that other people can rely on without having to understand it. The difference is the size of the network underneath it, and the calibre of the people I get to argue with about how it should work.</p>
<p>That is why I am still here. It is a rare combination, and it has not gone stale yet.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Who owns your supplier - the Gamma deal</title>
		<link>https://simwood.com/2026/09/who-owns-your-supplier-the-gamma-deal/</link>
		<dc:creator><![CDATA[Simon Woodhead]]></dc:creator>
		<pubDate>Thu, 10 Sep 2026 11:18:00 GMT</pubDate>
		<category><![CDATA[commercial]]></category>
		<guid isPermaLink="true">https://simwood.com/2026/09/who-owns-your-supplier-the-gamma-deal/</guid>
		<description><![CDATA[Private equity has bought Gamma at less than half its 2021 price and called it a premium. The money has to come back from somewhere. If you are a partner, two of the three places are you.]]></description>
		<media:thumbnail url="https://simwood.com/assets/og/blog-posts-2026-09-who-owns-your-supplier-the-gamma-deal-4f9904bac6.png" width="1200" height="630" />
		<content:encoded><![CDATA[<p>On 1 September Gamma's board recommended a cash offer of 1,120p a share from Bradbury Bidco, a company controlled by funds advised by Epiris, with HarbourVest and Limewood alongside as co-investors. That values the equity at a little over £1bn. If shareholders, the court and half a dozen regulators agree, Gamma leaves the public market in the first half of next year.</p>
<p>I want to start by saying well done, and I mean it. Gamma has been built into a business turning over £645.8m last year, growing at 11%, with 89% of its revenue recurring and more than 1,500 UK channel partners selling it. A £1bn cash exit is a result, and the people who did the work earned it. There are serious, capable people there, and nothing that follows is about them. It is about the model, and it is written for the partners - Gamma's first among them, but far from only them - who woke up on 1 September to find the ground under their supplier had moved, and who are now, quite reasonably, thinking about their own futures.</p>
<h2>We have written about this before</h2>
<p><a href="https://simwood.com/2025/07/the-bigger-they-are-the-harder-they-fall-dont-be-a-casualty/">Last July</a> I wrote about buy-and-build: acquisitions funded with cheap debt at eight to twelve times EBITDA, and interest cover collapsing. Survivability, I argued, deserves a premium.</p>
<p><a href="https://simwood.com/2026/04/enshitification-in-telecoms/">In April</a> I wrote about enshitification, the point at which a business stops creating value for its customers and starts extracting it from them. Extraction is not a moral failure. It is the equilibrium of a commoditised market with capital to service, and public markets had already marked carriers down after overpriced acquisitions.</p>
<p>And <a href="https://simwood.com/2026/03/diseconomies-of-scale/">in March</a> I wrote that scale does not deliver margin in this industry, that seven to nine in ten deals fail, and that integration destroys the efficiency it was meant to create. <a href="https://simwood.com/2024/03/calling-all-carriers-and-platform-operators-part-1-dinosaurs/">Two years before that</a> I had already called the pattern &quot;debt funded roll-ups&quot;.</p>
<p>Three threads. On 1 September they tied themselves together in one announcement.</p>
<h2>The premium in context</h2>
<p>The headline was a 53% premium to the undisturbed closing price of 732p on 7 April. But a premium is measured from wherever the price happens to be standing, and the question is how it got there.</p>
<p>Gamma's shares peaked at around 2,350p in September 2021. The price the premium is measured from was down roughly two-thirds from that peak. The offer, at 1,120p, is under half of what the market once thought the business was worth.</p>
<p>So the market had made its decision about this business years before Epiris did. The board's stated reasons for recommending the offer include cash certainty and the &quot;removal of execution risks from standalone strategy&quot;, and other proposals were on the table. A board with a good, growing, cash-generative business chose a certain pound today over its own plan for tomorrow. It tells you what the board believed the standalone plan was worth, and what the market had been telling them for several years.</p>
<h2>Where the money comes back from</h2>
<p>A fund does not buy a business to own it. It buys a business to sell it, in a few years, for more than it paid, usually having borrowed part of the price to do so. The interim facilities for this deal come from Ares. How much was not disclosed, but the shape is the shape. A price has been paid, and it has to come back to the fund, with a return on top, from somewhere.</p>
<p>There are only three somewheres. Price: charge the existing customers more. Cost: spend less on serving them. Growth: win more of them, or sell them more.</p>
<p>If you are a channel partner, you are on the receiving end of two of the three. Price is your margin. Cost is the service your customers experience and the support you rely on. Growth is the one everybody hopes for, and it is the hardest, which is why the other two get pulled first.</p>
<p>Which brings me to the AI. The announcement promises &quot;increased investment in product innovation and AI adoption&quot;, and Gamma's own results in March leaned on AI as the growth lever: an AI concierge that answers calls, early voice-agent revenue in Germany growing fast off a small base, and management, to their credit, warning against extrapolating from it. Good. It is the right thing to be building and I would say so whoever was building it. But under a fund that investment sits on the same P&amp;L as the debt service, and that P&amp;L has to produce a return inside the fund's timetable. AI spent on growth is a bet that pays back, if it pays back, in years. AI spent on taking cost out of the business pays back with something close to certainty, on the cost line, which is the line the fund most needs. Which kind does the arithmetic choose?</p>
<p><a href="https://simwood.com/2026/07/ai-is-an-extinction-level-event/">As I argued in July</a>, that is the distinction that decides who survives this. The companies AI finishes are the ones that use it for replacement and cost-out. The ones it makes are the ones that use it for amplification, so the same people do a great deal more, and amplification compounds: by the time the second car pulls away from the line, the first is not merely ahead, it is over the horizon. Compounding cannot be bought late, and it cannot be bought at all from a standing start, because it has already started elsewhere. The alternative I described in July is to spend telephone numbers buying customers instead of building, which is the model this whole post is about, one level up.</p>
<p>The announcement says there will be &quot;no material headcount reductions&quot; in the first twelve months, and no material changes for channel partners. I believe that is sincerely meant. I also note that twelve-month assurances have twelve-month horizons. Completion is expected in the first half of 2027. Count forward from there.</p>
<p>None of this needs bad faith. Nobody here is a villain. It is what the structure does: debt has to be serviced, a return has to be earned, an exit has to be prepared, and the people inside the structure, however decent, execute what it requires. That is what I meant in April. Extraction is an equilibrium, not a choice.</p>
<h2>The third test</h2>
<p><a href="https://simwood.com/2026/07/you-buy-from-who/">In July</a> I gave you two tests for a supplier. Capability: have they already built what you need? Alignment: does their growth depend on winning the customers you are chasing? I want to add a third, because 1 September made it unavoidable.</p>
<p>Who owns your supplier, what do they need from it, and by when?</p>
<p>A business is run for its owners. That is not cynicism, it is more or less what company law says. When a supplier is owned by a fund, it is run for the fund's return, on the fund's timetable, and every partner of that supplier is a line in the model that produces it.</p>
<p>A side-point. Gamma's people, like those at most listed companies, have had share schemes, and I hope a good many of them see something from this. But the directors' own holdings committed to the deal come to about 0.13% of the company, and the equity is overwhelmingly institutional. The result belongs to the people who built it. The cheque, overwhelmingly, goes elsewhere.</p>
<p>Simwood is owned by the people who work in it. There is no external fund. We are largely debt free, and <a href="https://simwood.com/2025/07/the-bigger-they-are-the-harder-they-fall-dont-be-a-casualty/">we published our interest cover</a> last year rather than ask you to take my word for it. Apply the third test to us and the answer is short: the people who need a return from this business are the people answering your tickets, and what they need is for you to still be here in ten years. That is a different set of incentives from a fund with a fund life.</p>
<h2>Three things to do this week</h2>
<p>First, read your change-of-control and termination clauses now, not when the deal completes. Know what notice you can give, what notice you can be given, and what happens to your numbers and your customers' data if you leave.</p>
<p>Second, send the <a href="https://simwood.com/2026/07/you-buy-from-who/">You buy from who</a> questions to your supplier in writing: whose network your traffic ends up on, who else is in the path, and what they are building next year that you are scoping to build yourself.</p>
<p>Third, add the new one to the same email. Who owns you, what do they need from the business, and by when do they need it? A supplier who cannot answer that plainly has answered it.</p>
<h2>The ground moved</h2>
<p>If you built your business on Gamma, or on any supplier that has since been bought, you did nothing wrong. You chose a sound business on the information you had. The ground moved under you. It moved because the public market decided what the business was worth, a board decided cash was better than the plan, and a fund decided it could make the numbers work. None of those decisions involved you. Every one of them lands on you.</p>
<p>So the question is not whether you were foolish then. You were not. The question is whether the next contract you sign is with a business whose owners need you to win, or with a business whose owners need something from you. One of those is a partnership. The other is a line in somebody else's model.</p>
<p>I know which one we are. Who owns your supplier?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Hi, I’m Mariam</title>
		<link>https://simwood.com/2026/09/hi-i-m-mariam/</link>
		<dc:creator><![CDATA[Mariam Rekhviashvili]]></dc:creator>
		<pubDate>Thu, 10 Sep 2026 10:48:00 GMT</pubDate>
		<category><![CDATA[inside-simwood]]></category>
		<guid isPermaLink="true">https://simwood.com/2026/09/hi-i-m-mariam/</guid>
		<description><![CDATA[Hi, I'm Mariam, and apparently I can't resist a new challenge.
Ask anyone who knows me, and they'll confirm: I box, I play tennis twice a week, I've recently picked up padel, and I have a deep love for maths, numbers, and anything technical. I'm also a firstborn daughter, which basically means I'm professionally trained to take care of everyone around me, whether they ask for it or not. It's a lifestyle.
]]></description>
		<media:thumbnail url="https://simwood.com/assets/og/blog-posts-2026-09-hi-i-m-mariam-941c4a148c.png" width="1200" height="630" />
		<content:encoded><![CDATA[<p>Hi, I'm Mariam, and apparently I can't resist a new challenge.</p>
<p>Ask anyone who knows me, and they'll confirm: I box, I play tennis twice a week, I've recently picked up padel, and I have a deep love for maths, numbers, and anything technical. I'm also a firstborn daughter, which basically means I'm professionally trained to take care of everyone around me, whether they ask for it or not. It's a lifestyle.</p>
<p>So when the opportunity came to join Simwood, a UK company, in a field I had zero experience in, telecommunications, I did what I always do with something new and slightly intimidating: I said yes. I joined as an Account Manager, and honestly, the part of the role I enjoy most is the communication side of it, getting to speak to different people, understanding what they need, and building those relationships. So if you're reading this and we haven't had a chance to speak yet, send me an <a href="mailto:mariam.rekhviashvili@simwood.com">email;</a> or<a href="https://ro.am/mariam-rekhviashvili/"> book a call with</a> me. I'd love to catch up!</p>
<p>Six months in, here's where I am.</p>
<p>The team is welcoming and helpful, and has a good sense of humour, which makes a difference when you're navigating a new field and asking a lot of questions. There's a good balance between getting proper support when you need it and being pushed to figure things out yourself, which is honestly the best way to actually learn.</p>
<p>The telecommunications world turned out to be exactly the kind of subject I enjoy, full of logic, structure, and enough complexity to keep things interesting. A bit like learning tennis. Confusing at first, satisfying once things start clicking.</p>
<p>This is also my first time working for a company outside of Georgia, with a UK-based team, remotely with them from a great office in Tbilisi. Being remote doesn't save my colleagues from me, though; Roam (Virtual office platform) makes sure of that. Distance is simply not a barrier when you have questions, and I always have questions. One thing worth mentioning is that, even though Simwood is based in the UK, we also have a small team here in Tbilisi, Georgia, which made the transition much smoother. Getting to work alongside some great Georgian colleagues while also being connected to the Bristol team really does give you the best of both worlds.</p>
<p>That said, I'm very much hoping to make it to the Bristol office before the year is out. I'd love to experience the UK work culture in person and finally put faces to all the names I've been messaging.</p>
<p>One of the things that genuinely surprised me during these three months was discovering what Simwood has actually built in this space and how much it can change the way a business communicates. Coming from outside the industry, I didn't expect to find something that felt this practical and immediately useful. Simwood has developed <a href="https://simwood.com/conversational-ai-voice-agents/">AI agent</a> integration directly into tools people already use every day, such as <a href="https://simwood.com/whatsapp-business-integration/">WhatsApp</a>, Microsoft Teams, and similar platforms. These agents can take calls, transfer them, generate summaries, handle first responses, and basically take care of all the front-line tasks that quietly eat up hours of someone's working day. I say this as someone who came in with no background in this at all. Once I saw how straightforward Simwood has made the integration process and what it actually delivers for a business in terms of time and efficiency, it was hard not to appreciate what's been built here. If you haven't had a chance to explore our new offerings to share them with your users and make their life easier, it's genuinely worth a conversation.</p>
<p>If this is new territory for you as a client, make sure to check out our other blogs where we go into more detail on all of this, or just reach out to us directly, and we'll make sure to walk you through everything you need to know.</p>
<p>These three months have been a solid introduction to a field I knew nothing about, and I'm looking forward to seeing where it goes from here.</p>
<p>Next time I write one of these, hopefully I'll have a Bristol visit to report back on too.</p>
<p>Until then, Mariam</p>
<p>PS: If you haven’t seen our newest podcast episode, you really should <a href="https://simwood.com/2026/06/simcron9-whatsapp-compliance-and-the-future-of-comms/">here</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>USA pricing review / e911</title>
		<link>https://simwood.com/2026/08/usa-pricing-review-e911/</link>
		<dc:creator><![CDATA[Simon Woodhead]]></dc:creator>
		<pubDate>Thu, 20 Aug 2026 17:51:00 GMT</pubDate>
		<category><![CDATA[commercial]]></category>
		<guid isPermaLink="true">https://simwood.com/2026/08/usa-pricing-review-e911/</guid>
		<description><![CDATA[e911 is now available in the API/portal and we're updating our USA prices to reflect it and other commercial changes in the US market.]]></description>
		<media:thumbnail url="https://simwood.com/assets/og/blog-posts-2026-08-usa-pricing-review-e911-00ffdbb09c.png" width="1200" height="630" />
		<content:encoded><![CDATA[<p>There's been an awful lot of change in the US market since we first became a CLEC in 2017 (wow, nearly 10 years ago!) but mostly in the last couple of years. The regulatory regime has tightened, not just for us but crucially for our customers. That has cleaned the market up massively, but operators have had to up their game, and <em>pretending</em> to be a US operator is no longer an option.</p>
<p>That has in turn done a few things for our customer base. It has vindicated our long-held position on scrotes, although the burden on our sales team as a filter has ballooned with so many scrotes looking for a home for their traffic. Moreover, our non-US customers have had to themselves become compliant with new requirements, agencies, and filings. Some have taken this in their stride, others have made a massive ordeal out of it and resent us for changes the FCC has imposed, but we generally support. However you skin it, our costs in the US market have risen exponentially.</p>
<p>There are still operators pretending to offer service in the US and bemoaning us for being compliant. One &quot;peer&quot; advising our customers on US compliance when they have zero presence and zero licence there took the biscuit. If you resent compliance to protect consumers, please feel free to use them and see how long service lasts.</p>
<p>This is a long way of saying that our pricing is woefully out of date, and effective September 1st (for billing October 1st), our rentals on US numbers will increase as below. Naturally, Managed Interconnect customers with a bespoke committed rate will continue to benefit from that rate, at least until contract renegotiation.</p>
<p>Further, while e911 was never relevant to us as a wholesale operator, our customer profile has changed, and it now is. Effective immediately, you can upload address data through our portal and <a href="https://developer.simwood.com/docs/wholesale/api/v3#number-configuration---e911-emergency-services-us-numbers">API</a>. It is in API v3 rather than the newer architecture for easy compatibility with UK 999 integrations and will be deprecated/migrated alongside in due course.</p>
<p>Commercials for e911/911 vary in the US to what our UK customers will be used to. We are not applying any kind of database update fee - they're free of charge - and calls to 911 are also free of charge. However, numbers (a.k.a. DIDs/DDIs) which are e911 enabled (i.e. have had data uploaded against them) are charged a monthly uplift to the rental to cover the elements which are not charged. This is not our model; we've followed local convention.</p>
<p>Our monthly per-number pricing for the US is now:</p>
<table>
<thead>
<tr>
<th style="text-align:left">Tier</th>
<th style="text-align:left">Number rental</th>
<th style="text-align:left">E911 uplift</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:left">Developer</td>
<td style="text-align:left">£2.00</td>
<td style="text-align:left">£0.75</td>
</tr>
<tr>
<td style="text-align:left">Startup</td>
<td style="text-align:left">£1.00</td>
<td style="text-align:left">£0.75</td>
</tr>
<tr>
<td style="text-align:left">Virtual Interconnect</td>
<td style="text-align:left">£0.75</td>
<td style="text-align:left">£0.75</td>
</tr>
<tr>
<td style="text-align:left">Managed Interconnect</td>
<td style="text-align:left">POA</td>
<td style="text-align:left">£0.75</td>
</tr>
</tbody>
</table>
<p>All prices are per telephone number, per month, ex VAT at the time of this blog being published. Current rates are always on our <a href="https://simwood.com/rates">rates page</a>.</p>
<p>Our existing statutory investigation fee is unaffected by this change and will apply wherever a call is routed to 911 and no e911 data exists. In this circumstance, the call cannot be routed to the appropriate Public Safety Answering Point (PSAP), the functional equivalent of UK EHA, because there is no address. This not only risks lives but incurs additional cost and process all round. We will take an <em>extremely</em> dim view of any customers who seek to minimise rental costs by chancing the investigation fee and risking lives in the process.</p>
<p>We will route calls to 911 where the call originates from a US number. Calls for numbers allocated through Simwood <em>should</em> be sent to Simwood, and the same with other providers - same preference as in the UK. However, as in the UK, we will connect any call and deal with the compliance afterwards.</p>
<p>911 should not be tested, but to make this possible, you can configure 933 to route identically and make test calls to 933. The call will answer and read back the address information configured against the number. Furthermore, API updates do not require the overnight batch processing Calypso requires despite the user base being roughly 5x the size. Updates via our API should be reflected relatively instantly. This is useful for testing, but you should not build production logic requiring it!</p>
<p>Hopefully, this is a welcome update that'll help all our customers with US estates improve their offer and compliance.</p>
]]></content:encoded>
	</item>
	<item>
		<title>You buy from who!?</title>
		<link>https://simwood.com/2026/07/you-buy-from-who/</link>
		<dc:creator><![CDATA[Simon Woodhead]]></dc:creator>
		<pubDate>Tue, 28 Jul 2026 13:19:00 GMT</pubDate>
		<category><![CDATA[commercial]]></category>
		<guid isPermaLink="true">https://simwood.com/2026/07/you-buy-from-who/</guid>
		<description><![CDATA[Partnering beats building everything yourself. That leaves the question of who. Two tests: do they have what you need already built, and does their growth depend on winning the customers you are chasing?]]></description>
		<media:thumbnail url="https://simwood.com/assets/og/blog-posts-2026-07-you-buy-from-who-dfbc1ab137.png" width="1200" height="630" />
		<content:encoded><![CDATA[<p><a href="https://simwood.com/2026/07/stop-building-everything-yourself-why-the-fastest-route-to-innovation-is-often-partnership/">Raj wrote last week</a> that the fastest route to market is partnership rather than building everything yourself, and he is right. That leaves the question of who, because “partner rather than build” assumes there is a partner available. Ask a good part of this industry to partner with you and what comes back is a rate sheet.</p>
<p>There are two tests. Capability: do they have what you need, already built, or are you going to build it? Alignment: does their growth depend on winning the same end customers you are trying to win? They are independent, and a supplier has to pass both.</p>
<h2>The capability test</h2>
<p>If all your supplier sells is lines and minutes, you are going to build everything else. The fraud controls, the number management, the recording, the analytics, the AI layer your customers have started asking about and your roadmap has already slipped. You will build all of it while paying a company whose job it was to have built it once, properly, for everybody.</p>
<p>They are not withholding a roadmap out of spite. <a href="https://simwood.com/2024/03/calling-all-carriers-and-platform-operators-part-1-dinosaurs/">I wrote about this two years ago</a> and I would struggle to point at much that has changed since. The people who sold lines and minutes in the nineties are selling the same thing over SIP.</p>
<p>Before you get that far, check whether they <a href="https://simwood.com/2024/04/does-your-carrier-have-any-infrastructure-in-the-uk/">have any infrastructure at all</a>. A good number of the companies calling themselves carriers are reselling somebody else’s, and this is the UK, where it is reseller on reseller on reseller. If that is your situation there is a chain behind your supplier and you probably cannot see the top of it. You know who invoices you, which is not the same as knowing whose network you are on.</p>
<h2>The alignment test</h2>
<p>Now ask where the money you pay your supplier goes. If they also sell direct, or through partners of their own, it goes into a business competing for the customers you are chasing. They can also see your volumes, your growth and your seasonality, because carrying your traffic is how they find out, and in some arrangements they can see which of your end customers holds which number. Some of it you hand over deliberately, because you have to: emergency service records and porting requests are the obvious examples. The rest accumulates as traffic flows and numbers are allocated and ported. Either way your supplier holds a current picture of who your customers are and which numbers are theirs, and no step of it ever felt like handing over a customer list.</p>
<p>None of this requires anybody to behave badly. It is structural.</p>
<p>And it is not only your immediate supplier. In a chain, the conflict may sit two layers above the logo on your invoice, with an operator you have never contracted with, who can see your traffic because it passes through them, and who is chasing your customers with a sales force you have never met. Your supplier may be entirely innocent and entirely powerless, which does not help you.</p>
<p>Now try saying all of that out loud to your NED, your PE backer or your VC. Our strategy is to take share from that company. We fund them out of what our customers pay us. They can see who our customers are. And they turn up across the table in our own pitches. Nobody defends that arrangement out loud, which is why it survives: it is never said to anyone whose job is to ask.</p>
<h2>Where we sit, and what it has cost us</h2>
<p>The question underneath the alignment test is whose platform the service runs on: yours, in which case you buy carriage and numbering and build the rest yourself, or your supplier’s, sold either under your brand or under theirs. Everyone in this market sells some of each. The weighting is the thing, so here is ours next to our purple radioactive friends’, cut on that axis.</p>
<p><img src="/assets/blog/20260728-revenue-mix-pyramids.png" alt=""></p>
<p>The white-label band in the middle of ours is our platform, sold through partners. It is fully white-labelled, but every supplier says that. The end customer sees your name on the product, the portal, the invoice and the support. We send through your own SMTP servers, so we do not appear in the mail headers. Our apps are named anonymously enough that a good number of the people using them do not know they exist as our products at all.</p>
<p>We want no inbound from those end users and no word of mouth, which is why it is built this way. Years of product work has gone out under other people’s names, and the recognition it earned sits with our customers rather than with us. That is the cost, and we keep choosing it.</p>
<p>Our engineering goes into the layers underneath: the fraud controls, the numbering, the recording, the nuisance call handling that protects your customers’ customers, and the Conversation Intelligence and AI voice work Charles’s team has shipped. You put your own name on all of it.</p>
<p>What we build carries no trace of us to the end user, and the relationship goes to whoever sold it. We have done that for years. That is not a claim to be incapable of anything else: there is a direct band on that graphic, and we hold your traffic data, as does anyone carrying it. Weigh the record rather than the promise.</p>
<h2>So</h2>
<p>Email your largest supplier today and ask, in writing, whose network your traffic ends up on, who else is in the path, and what they are building next year that you are currently scoping to build yourself and already paying them for.</p>
<p>It is a fair question from a paying customer. If what comes back is a rate sheet, you have your answer to both tests.</p>
<p>Then ask us the same thing.</p>
]]></content:encoded>
	</item>
	<item>
		<title>The Ministry of Messages</title>
		<link>https://simwood.com/2026/07/the-ministry-of-messages/</link>
		<dc:creator><![CDATA[Peter Farmer]]></dc:creator>
		<pubDate>Mon, 27 Jul 2026 15:54:00 GMT</pubDate>
		<category><![CDATA[regulation]]></category>
		<guid isPermaLink="true">https://simwood.com/2026/07/the-ministry-of-messages/</guid>
		<description><![CDATA[Orwell gave us the vocabulary. Kafka drew the floor plan. On 15 July, Ofcom published the regulations.
Here is the short version, for the busy. Your telephone company will shortly be required by law to inspect the contents of your private text messages, check them against a list you will never see, and destroy the ones that match. Nobody has to tell you it happened. If the operator later works out it should not have done it, nobody has to deliver the message, and nobody has to have kept it. You are left with a right to challenge a decision you were never told about.
]]></description>
		<media:thumbnail url="https://simwood.com/assets/og/blog-posts-2026-07-the-ministry-of-messages-9d9be90f15.png" width="1200" height="630" />
		<content:encoded><![CDATA[<p><em>Orwell gave us the vocabulary. Kafka drew the floor plan. On 15 July, Ofcom published the regulations.</em></p>
<p><em>Here is the short version, for the busy. Your telephone company will shortly be required by law to inspect the contents of your private text messages, check them against a list you will never see, and destroy the ones that match. Nobody has to tell you it happened. If the operator later works out it should not have done it, nobody has to deliver the message, and nobody has to have kept it. You are left with a right to challenge a decision you were never told about.</em></p>
<p><em>That reads like hyperbole. It is a summary. What follows is twelve pages, near enough, of receipts: rule numbers, paragraph references, and Ofcom's own words in Ofcom's own documents. The statement runs to 195 pages before you reach the separate guidance, the part that matters is buried in section 7, and the part that settles the argument is the legal instrument bolted on at the back, which is where I eventually found what this actually does. I make no apology for the length. If you read one section, make it the second.</em></p>
<p>On 15 July, Ofcom published its <a href="https://www.ofcom.org.uk/phones-and-broadband/scam-calls-and-messages/consultation-combatting-mobile-messaging-scams">statement on combatting mobile messaging scams</a>. I have read it, all of it, down to the legal instrument at the back, so that you do not have to, and I can report that somewhere in the drafting a perfectly sensible objective, namely fewer grandparents being fleeced by a fake parcel-delivery text, has been dressed up in the machinery of a surveillance state and sent out into the world with a straight face.</p>
<p>Regular readers will know two things about me. First, that I make my living in the dark compliance arts and have a weakness for a defined term, or, sometimes, for the wonderful world of the ordinary and natural meaning of an undefined one. Second, that I have said, repeatedly and at tedious length, that Ofcom is a child of Parliament. It does not wake up in the morning and decide to be sinister; it executes the will of a Government that would very much like to be seen to be Doing Something about fraud. So this is not a piece about a rogue quango. It is a piece about method, and about the quiet erosion of a principle that ought to survive contact with even the worthiest of causes.</p>
<h4><em><strong>Know Your Traffic</strong></em></h4>
<p>Let me start with the language, because Orwell would have. We already have KYC, Know Your Customer, which is sensible, and which we at Simwood do with rather more rigour than the rules demand. The statement now blesses us with a sequel, KYT, Know Your Traffic: an ongoing obligation to review account activity, monitor volume patterns, watch for new or unusual use of Sender IDs, and investigate what turns up.</p>
<p>I have no quarrel with any of that, and it is important to say why not. KYT attaches to A2P messaging only, the commercial channel, where businesses contract with providers to send appointment reminders and delivery updates. It is a duty about business traffic, it looks at behaviour, volumes, and patterns rather than at what anybody wrote, and we do it already. If the statement had stopped there, this would be a short and rather boring blog.</p>
<p>It does not stop there. There are two blocking duties in this statement, not one, and almost every summary I have read collapses them into each other. The difference between them is the whole point, so let me set them out precisely, from the instrument itself rather than the press release.</p>
<h4><em><strong>The envelope, not the letter</strong></em></h4>
<p>Here is the distinction that matters, and the one that keeps this blog honest. Everything Simwood does today to shun north of 5% of the calls on our network operates on behaviour and metadata. We look at invalid CLI, at dead-number ratios (our beloved UAP), at dialling patterns that no human hand produces, and at what our own systems flag when a suballocated number starts misbehaving. We look at the envelope, not the letter. We have never needed to steam open the correspondence to work out that something is a war-dialler.</p>
<p>Now watch the new rules draw exactly this distinction, and mandate both halves of it. A word on citation, because precision matters here and General Conditions are amended more often than anyone outside this trade would believe: everything I quote below is General Condition C9, as imposed by the Notification at Annex 1 to the 15 July statement. It is not yet in force and it is not what the General Conditions say today. GC C9.3(b) requires providers to block P2P messages sent from telephone numbers they reasonably believe have been used to scam. That is the envelope: who sent it, judged on intelligence about the sender. It is what a careful operator does, and I have no complaint. Then comes sub-paragraph (c), and I am going to quote it in full, because I want no argument about what it says. Providers must “block, via automated means and without undue delay, P2P Messages that contain URLs or Telephone Numbers which they reasonably believe were used as part of a Scam”.</p>
<p>Sit with the word <em>contain</em> for a moment. You cannot know what a message contains without inspecting its contents. All of them, every message, every time, because the offending URL could be anywhere in it. And note the channel. P2P. Person-to-person. The instrument defines it as “a message sent from one SIM to another”, which is to say the text you send your mother. The commercial channel gets the mirror-image duty at GC C9.7. Private correspondence is not the exception to this regime. It is half of it, and, as we shall see, the half that arrives first.</p>
<p>I can hear the answer, so let me make it for them, because it is the best one they have. This is not really reading. Ofcom itself describes what it mandates as, in effect, an exact database matching tool: a lookup against known scam URLs and numbers, with no human required to read anything and no machine interpreting your prose. That is true. It is narrower than the worst thing I could have accused them of, and I am not going to pretend otherwise. It is also beside the point. To find a URL in a message you must parse the message. The narrowness is in what the machine is looking for, not in what it opens. Every envelope is still slit. The clerk simply has a short list and no curiosity.</p>
<p>And Ofcom knows the clerks are already curious, because it says so in the plainest sentence in either document. The guidance states that these are minimum measures, that providers may go further, and that going further expressly includes monitoring messages nobody has reported at all, on probabilistic rules, hunting for anything that looks suspicious. Our rules, it says, neither require nor prevent this. It adds, correctly, that such monitoring is likely to be more intrusive. Then it moves on. The mandate sets the floor. The ceiling is left precisely where it was, and Ofcom has written down that it is leaving it there.</p>
<p>And I know exactly what comes next, because it is what always comes next: if the industry is already doing this, what precisely is your complaint? Three things. Industry practice is not a legal justification, which we put to Ofcom in January in rather blunter terms than that, and which I return to below. What was the practice of some is now the duty of all, including providers who until this moment have only ever looked at the envelope. And whatever the tooling, a regime whose transmission guarantee has been watered down and whose notification duty has been deleted outright is a different animal from one where neither was ever on the table. Narrow tooling does not make a wide mandate narrow.</p>
<h4><em><strong>Mum, it's a scam</strong></em></h4>
<p>Let me make this concrete, because the abstraction flatters it. You text your mother: Mum, whatever you do, do not ring 0330 123 4567, it is a scam. That number is on the list, as by definition it would be, or you would not be warning her about it. Your message therefore contains a telephone number reasonably believed to have been used as part of a scam. C9.3(c) is satisfied. Blocked, by automated means, without undue delay.</p>
<p>Your intention has nothing to do with it, and that is a drafting choice rather than an oversight. Sub-paragraphs (a) and (b) of the same condition both turn on messages <em>intended to Scam the intended recipients</em>; the words are right there on the page. Sub-paragraph (c) carries no such qualifier. The intent test attaches to the number's history, not to your message. And the tool Ofcom has specified, an exact database match, is by design incapable of noticing the word not.</p>
<p>Now, before anyone tells you this is a clever gotcha that Ofcom never considered, it is not, and I want to give them full credit, because the passage is buried in Annex 4 where almost nobody will look. Ofcom sets out the scenario in terms: an individual may copy a scam URL or telephone number to send to a friend, to warn them about a scam. It accepts the message may be blocked. It accepts, expressly, that this interferes with the right to freedom of expression. They saw it coming.</p>
<p>It is the answer that should stop you. Having accepted that your warning will be destroyed, Ofcom reasons that this should not much matter, because the actual scam message containing that same number would also be blocked, so your mother is protected anyway. The warning is redundant, because the danger has already been dealt with.</p>
<p>Hold that against what Ofcom wrote back near the front of the same document, in its own account of how these crimes actually work. The scammer makes first contact by text, and then, in Ofcom's words, may ask the victim to communicate with them using an online messaging app such as WhatsApp or Facebook Messenger. Those are number-independent services. They live under the Online Safety Act, not the Communications Act, and nothing whatsoever in this statement reaches them. So the redundancy argument holds inside one channel only, and Ofcom's own description of the crime has the criminal leaving that channel at the second step.</p>
<p>Follow it all the way through, with your mother rather than with a defined term. The approach comes at her on Facebook, or on WhatsApp, or by email, or as a voice call from the very number you were trying to warn her about, because it is a telephone number and telephone numbers are for ringing. In none of those places has anything been blocked. In none of them does the protection Ofcom is relying on exist at all. The one channel where the danger was neutralised is the one channel where your warning was destroyed, and it was destroyed precisely because it named the danger accurately.</p>
<p>That is the shape of it. The blocking works where the criminal has already gone. The silence works where your mother still is.</p>
<p>And the guidance goes further than the statement let on, so let me put that on the table too. Buried among the validation steps, operators are asked to consider whether and how it may be possible to identify messages where an individual copies a scam URL or telephone number to send to a friend, to warn them about a scam. They are also invited to consider quarantining messages they cannot confidently classify either way, holding them back so somebody can look before anything is destroyed. That is a real thought, properly had, and I would rather credit it than pretend it is not there.</p>
<p>Now read the verbs. Providers <em>must</em> block, via automated means, without undue delay. Providers <em>should consider whether and how it may be possible</em> to spot a warning. One of those is a duty and the other is an invitation to have a think, and both are pointed at the very same message. The only other protection on offer is the one I mentioned a moment ago: take appropriate steps to ensure the end-user's <em>number</em> is not blocked. The number, not the message. Nobody, anywhere, is told to deliver the warning.</p>
<p>And that is the pattern, once you have seen it. What binds is the Notification at the back, and nothing else. Every acknowledgement that this might go wrong, every mitigation, every reassurance that somebody will be thinking carefully, lives in the reasoning or in the guidance, which is to say outside the only text a tribunal would be reading. The duty to block is in the rule. The care is in the commentary.</p>
<p>And two paragraphs before that, the same annex says something which cannot stand beside it. Blocking messages that contain scam URLs or telephone numbers, Ofcom says, does not engage Article 10 at all. Then, two paragraphs later, the warning message, which contains a scam telephone number, is blocked and does interfere with freedom of expression. Same annex, same measure, same morning. They cannot both be right, and the reason they collide is the drafting gap I have already described: because sub-paragraph (c) never asks about intent, the category it creates holds scams and warnings alike, while the rights analysis treats it as though it held only scams.</p>
<p>Whether your destroyed warning even counts as a False Positive is, at best, unclear. The defined term speaks of a message incorrectly identified and blocked on the basis the provider reasonably believed it was intended to scam the recipient, which is a belief sub-paragraph (c) neither requires nor forms. Annex 4 plainly assumes warnings are caught by the false positive machinery, and I hope it is right, because a great deal rests on it. But the definition does not say so, and the definition is what a compliance team will read.</p>
<p>So run the sequence, on either reading. Blocked automatically. Not notified, because that duty was lobbied away. No duty to deliver it once anyone works out what happened, and no duty even to keep it, since Ofcom confirms providers need not retain blocked messages at all. And a right to challenge which you will never exercise, because you do not know there is anything to challenge.</p>
<p>And note that all of this is the mandated floor working exactly as designed, with an accurate list and a correct match. Now consider the ceiling, which nobody regulates. Ofcom's own footnote records that operators already review messages against a broad set of scam indicators, including phrases such as “Hi Mum”, and observes, correctly, that such probabilistic methods are by their nature less precise and produce more false positives. Ofcom neither requires this nor forbids it. It is also, and I feel faintly ridiculous having to write this down, the most ordinary way in the English language to begin a message to your mother.</p>
<p>So there are two layers here, and they fail in opposite directions. The mandated one blocks you warning your mother about a scam, and does so correctly. The unmandated one blocks your child saying hello, and does so incorrectly. Neither of you is told about either.</p>
<p>If you think I am overreading the instrument, take it from its author. Ofcom's Article 8 assessment of these measures, the P2P measures, not the business ones, accepts that they may interfere with the right to privacy, <em>because we expect mobile operators will need to use technology to review the content of private messages</em>. The next paragraph lists the possible harms, and one of them, in Ofcom's own words, is unwarranted surveillance. Their phrase. Their document. Their rules.</p>
<p>And one more detail from the scope provisions, the one that moves this piece from commentary to confession. The content-blocking duty does not fall on “the MNOs”. GC C9.1 applies it to any communications provider that transfers or terminates P2P messages. That includes us. The company whose entire pitch, in this very blog, is that we look at the envelope and have never needed to steam open the correspondence, will from 18 January 2027 be required by law to open it. I am not describing something other people will do to you. I am describing something we will be conscripted to do to you, on pain of enforcement, and I would rather tell you that plainly now than have you discover it later and wonder why I did not.</p>
<h4><em><strong>What Ofcom removed, and who asked for it</strong></em></h4>
<p>If content inspection were the whole of it, I could almost live with it, because a careful operator can do careful things. What I cannot live with is what happened between the consultation and the statement, and who asked for it.</p>
<p>Ofcom consulted on two safeguards, and their reach was the reach of the blocking itself: both attached to automated blocking under GCs C9.3(b), C9.3(c), and C9.7, private and commercial alike. The first was a duty on providers to take steps to stop legitimate messages being caught in their own blocking tools. The second was a duty to tell senders when a message had been blocked. Both are gone.</p>
<p>On the first, the objectors are a roll-call: BT, Sky, Virgin Media O2, VodafoneThree, Mobile UK, and UKCTA. The arguments were that no failure to deliver legitimate messages had been demonstrated, that operators already have every commercial incentive to deliver, and that a duty to carry sitting alongside a duty to block would leave operators walking a tightrope with a penalty waiting on either side. BT went furthest, and said Ofcom was attempting to offload its own Human Rights Act duty onto private operators. Ofcom agreed. An up-front duty to get legitimate messages through became an after-the-fact duty to identify, monitor, and address erroneous blocking.</p>
<p>Orwell's real subject was never the surveillance. It was the language that makes surveillance sayable. He wrote that the great enemy of clear writing is insincerity, and that when there is a gap between what you are doing and what you are prepared to say you are doing, you reach instinctively for the longer word. So read the two formulations again. Ensure the transmission of legitimate messages: six words, every one of them concrete, and you know on reading it who owes what to whom. Identify, monitor, and address instances where messages are blocked in error: longer, softer, and nobody owes you anything. The first is a promise. The second is a process. The same people wrote both, about the same problem, within nine months.</p>
<p>That replacement is a real obligation and I will not pretend otherwise. But look at what it does not do. Where an operator discovers that it destroyed your lawful message in error, Ofcom does not expect it to then deliver the message. The stated reason is that doing so could cause confusion. So the remedy for having your correspondence wrongly destroyed is that the operator performs a root cause analysis and tries not to do it to somebody else. Restoration is not forbidden, to be fair: a provider may unblock where appropriate, Ofcom says, for example following a challenge under GC C9.17. Which is to say the route back for your wrongly destroyed message runs through the challenge you were never told you had grounds to raise. Failing that, you are invited to use some other means of communication.</p>
<p>There is a word for a message that is destroyed, whose contents are nowhere preserved, and which is not restored even once the destruction is admitted to have been a mistake. He gave us that one as well. The memory hole was never a device of malice. It was a device of tidiness.</p>
<p>On the second, the same names. BT, Sky, Virgin Media O2, and VodafoneThree all told Ofcom that notification would be disproportionate, because most blocked messages are scams anyway. I will give the tipping-off argument its due, because it is a real one, and because it is ours as much as theirs: tell a sender their message was blocked and you have handed the scrotes a Haynes manual on bypassing the block, complete with torque settings and an exploded diagram. It is precisely why we publish what we block without publishing how we decide. Had that been the whole of it, I would not be writing this section. But BT also costed it, and told Ofcom that a notification duty would add to its termination payments, and that other providers might drive up notification volumes to harvest the revenue. Note what it costed. Its estimate was framed for P2P messages alone. So the inter-operator payments argument that helped see off the safeguard was costed against private correspondence between individuals, and the safeguard died for both channels.</p>
<p>And then there is the evidence. An earlier draft of this said we were not shown it. That was wrong, and the truth is worse. Ofcom went back to providers in May and asked how often they block legitimate messages by mistake. The providers reported that they hardly ever do: somewhere between never and about once a month. On that basis, Ofcom decided a duty to tell you was not worth the candle.</p>
<p>Now read Ofcom's own footnote to that evidence. The figures are largely built out of complaints. No provider actually measures how often it wrongly blocks. And the rates may be under-reported, because users may not have known their message was blocked, or may not have bothered to complain.</p>
<p>Then read what Ofcom tells operators about hunting for false positives. They must not rely on complaints and challenges as their main method, because the number of challenges they receive may not reflect how much wrongful blocking is actually going on. They should expect to miss it on P2P in particular, for two reasons Ofcom sets out itself: end-users may not know a message was blocked, and they are in any event less likely than business senders to challenge it. Which is to say the regime knows its blind spot is deepest over private correspondence, and shallowest over the commercial traffic that has a contract and a service manager.</p>
<p>So Ofcom knows that complaints do not measure wrongful blocking. It says so, in terms, and writes a General Condition on the strength of it. It then uses complaint-derived data to conclude that wrongful blocking is too rare to be worth telling anyone about. The evidence that nobody complains has been used to remove the mechanism by which anyone would know to complain.</p>
<p>Doublethink was the term for holding two contradictory beliefs at once and accepting both of them. It was not offered as a figure of speech. It was offered as a technique. One paragraph knows that complaints do not measure wrongful blocking. Another counts the complaints and concludes that there is not much wrongful blocking. The two have never met. Both were published on the same morning, over the same name, in the same document.</p>
<p>So here is the finished article. Your lawful message may be inspected, it may be silently binned, nobody is obliged to tell you, and if the operator later works out that it should not have binned it, nobody is obliged to deliver it. The burden falls on you, the wrongly-blocked, to notice the silence, deduce that you have been blocked, and invoke your shiny new right to challenge a decision you were never told about. That is not a safeguard. That is Kafka with a message centre. We publish <a href="https://simwood.com/2026/03/call-quality-reports/">Call Quality Reports</a> so that our customers can see what we are blocking for them. We do not publish how we decide, for the reason I gave earlier, and there is all the difference in the world between telling you a thing happened and handing over the workshop notes. Ofcom has arrived at the opposite instinct on both counts: keep the method to yourself, and do not mention that it happened either.</p>
<h4><em><strong>The cohort nobody asked about</strong></em></h4>
<p>Then there are the volume limits on pay-as-you-go SIMs, which sit in the P2P rules and bite on private messaging only. Here I must declare an interest in my own back catalogue. We told Ofcom, in writing, that we saw no issue with frustrating the bulk sending of P2P messages from PAYG SIMs, and that it was a sensible ex-ante measure at the point of entry rather than an ex-post criminal matter about the possession of equipment. I have not changed my mind. A bot firing thousands of texts an hour is not a person wishing their nan a happy birthday.</p>
<p>So this is not an objection to volume limits. It is an objection to a question Ofcom did not ask.</p>
<p>The rule bites on PAYG and on nobody else. Ofcom says so expressly: pay monthly users will not be constrained, because contracts, credit checks, and billing details make it harder for a criminal to acquire those SIMs in bulk. That is sound as far as it goes. But note why the two cohorts differ in the first place, on Ofcom's own account at the front of its statement: operators do not apply the same level of credit or identity checking to PAYG as they do to a contract. The line Ofcom has drawn is, substantially, a credit line.</p>
<p>Now turn to Annex 3, where Ofcom discharges its duty to have regard to the needs of, among others, persons on low incomes. Its conclusion is that it has not identified any adverse impacts on specific groups of persons likely to be affected in a different way to the general population.</p>
<p>I am afraid it has. A rule that applies to one tariff cohort and expressly not to the other affects that cohort in a different way to the general population. That is what the word only does. Whether the effect is material is a perfectly fair question, and the answer may well be hardly at all. But Ofcom did not ask it. It looked at a measure that bites on prepay and on nothing else, and recorded that it had found no differential impact on anybody.</p>
<p>It matters more than it looks, because Ofcom is not setting the limit. Each operator sets its own, on its own evidence, at whatever level it judges will disrupt scammers without stopping legitimate use. I have no quarrel with that in principle; operators know their own traffic, and a regulator picking a national number would be worse. But the consequence is that how many texts a prepay customer may send before the network stops them is now a commercial judgement, made by the operator, reviewed by nobody in particular, and applied to the one group of customers who did not, or could not, pass a credit check. That deserved a paragraph in the equality assessment. It got a line saying there was nothing to see.</p>
<p>And here is a question the statement never asks, which I will leave hanging because it deserves a proper answer rather than a paragraph. A great many pay-as-you-go propositions are sold on <em>unlimited texts</em>. That word is not Ofcom's to define: the advertising rules permit an unlimited claim only where the user suffers no additional charge and no suspension of service for exceeding a threshold, where any provider-imposed limitation is moderate, and where it is clearly explained in the marketing communication itself. Last year the ASA told EE that even a fair usage policy almost nobody ever hits is still a limitation, and still has to be spelled out. Ofcom has now required every operator to impose a hard cap on how many texts a prepay customer may send, and set it themselves. Advertising appears in this statement only as something fraudsters do; how these caps sit with what the operators' own marketing promises is nowhere considered. Somebody's marketing department is going to have an interesting fourth quarter.</p>
<h4><em><strong>The one definition they would not give</strong></em></h4>
<p>My favourite touch, and I say this as a connoisseur, is the treatment of RCS. Faced with the question of whether RCS falls under the Communications Act or the Online Safety Act, Ofcom has decided that operators are best placed to assess this in the first instance. A regulator that loves a definition almost as much as I do has, on the single question where a definition would actually help, declined to supply one and handed the parcel to the very people it regulates. Marvellous.</p>
<p>The shrug matters more than the joke, because that boundary is the boundary of everything in this statement. Number-based services, SMS and MMS, are regulated under the Communications Act, which is where all of this lives. Number-independent services, WhatsApp, Facebook Messenger, iMessage, are not, and Ofcom says so plainly: they use functionality that does not depend on telephone numbers, so they fall outside the Act. RCS sits on the fence. Which is precisely why nobody would define it.</p>
<h4><em><strong>The half they can reach</strong></em></h4>
<p>So hold that boundary in your head, and then read Ofcom's own account of how these scams actually work. A scammer makes first contact by SMS, and then, in Ofcom's words, may ask the victim to communicate with them using an online messaging app such as WhatsApp or Facebook Messenger. That is not my speculation about what criminals might do once the pipes are watched. It is the regulator's own description of the standard journey, and the second leg of it lies outside the scope of every rule that follows.</p>
<p>Now look at the number doing the heavy lifting at the front of the statement. Forty per cent of UK mobile users report having received at least one suspicious message in the past three months. It is an alarming figure and I do not dispute it. But read the footnote under it. Suspicious messages there means messages arriving in the phone's default messaging app, which is to say via SMS, RCS, <em>and iMessage</em>. iMessage is out of scope. The harm has been measured across a wider set of channels than the remedy can reach, and nobody closes the gap between the two.</p>
<p>And here is the thing I went looking for. Ofcom does think about displacement, once, and the once is instructive. Utility Warehouse warned that capping pay-as-you-go would simply push the scammers onto pay monthly SIMs. Ofcom's answer is genuinely good: it will not, because acquiring pay monthly SIMs at scale is hard. The contracts, the credit checks, the billing details. Displacement, in other words, is defeated by acquisition barriers, and by nothing else. Hold on to that, because it is the only displacement analysis in the document, and it cuts the other way the moment you step over the fence.</p>
<p>Because the industry asked the over-the-fence question too. VodafoneThree and Utility Warehouse told Ofcom, in terms, that increased regulation of A2P messaging risks displacing fraud to other platforms. The statement records the concern, turns to the question of costs, and never comes back to it. I have looked for the answer and I cannot find one. So the one analysis we do have says scammers move unless the next channel is hard to get into, and the next channel here is WhatsApp, whose acquisition barrier is an app store and thirty seconds. On Ofcom's own reasoning, we know exactly where the traffic goes. Nobody has asked what the apparatus is worth once it has gone there.</p>
<p>Consider who can move and who cannot. A criminal enterprise can shift from SMS to an encrypted app for nothing, over an afternoon, and it has every incentive to. We have watched scrotitude migrate from carrier to carrier for thirty years, and it remains remarkably light on its feet. The people who cannot move are the ones for whom SMS simply is the messaging service: no smartphone, no data allowance, no app, or no inclination. They are, and this is not a coincidence, the same cohort we met earlier, the prepay customers whose volume limits nobody thought to assess for differential impact. So the apparatus is built on the one channel the least equipped cannot leave, to catch people who can leave for free, and it will still be running long after they have gone.</p>
<p>Let me forestall the obvious rejoinder, because I can hear it coming. I am not asking Ofcom to extend any of this to WhatsApp, and I would fight it if it tried. My point is the reverse. When a remedy can only reach half the problem, and the half it reaches is the half where the intrusion is deepest and the escape is cheapest, that is the strongest argument yet that this balance was never Ofcom's to strike. A sectoral regulator can only act inside its own statute, so it acts where its statute reaches, whether or not that is where the harm will be tomorrow. Parliament can look at the whole landscape at once, weigh the intrusion against the displacement, and decide whether the trade is worth making at all. Which is exactly what we told Ofcom in January.</p>
<h4><em><strong>Surveillance, outsourced</strong></em></h4>
<p>And here is the part that should trouble you whatever you make of the rest. Strip away the packaging and this is state-sanctioned, private-sector surveillance of private correspondence, at national scale, and I can find no politer word for it than vile.</p>
<p>Consider what the state itself may not do. It cannot read your post, or listen to your calls, on a whim. When it wants the content of your communications it must go through the <a href="https://www.legislation.gov.uk/ukpga/2016/25/contents">Investigatory Powers Act</a>: a warrant, a threshold, a Secretary of State, independent oversight, and a judge. That architecture exists precisely because reading a citizen's correspondence is understood to be one of the gravest things a state can do to its people, so it is fenced about with safeguards.</p>
<p>This statement reaches the same intrusion and quietly steps around every one of those fences. It does not have the state read your messages. It conscripts your telephone company to do it, continuously, on everything, with no warrant, no suspicion, no oversight of the list your words are being checked against, and no judge within a mile of it. You get the intrusion of state interception, delivered with none of the discipline of state interception, and dressed up as consumer protection. Worse, the private conscript has every commercial incentive to over-block. The duty to carry your lawful message was struck out at the industry's request, what replaced it does not oblige anyone to deliver a message they have worked out they wrongly destroyed, and no one has to tell you that any of it happened. All of the snooping, none of the due process, and a Terms of Service where a warrant used to be.</p>
<p>I am not the only one uneasy about this, and I am nowhere near the shrillest. <a href="https://www.ofcom.org.uk/siteassets/resources/documents/consultations/category-3-4-weeks/consultation-combatting-mobile-messaging-scams/responses/amnesty-international-uk.pdf?v=415309">Amnesty International UK responded</a>, and I should say plainly that they are more relaxed about the scanning than I am. They told Ofcom that mandatory scanning is rightly confined to a closed list, and that they did not find the proposals excessively problematic, in part because number-based messaging like SMS already carries low expectations of privacy, given the legacy constraints and the mandatory law-enforcement access built into these systems long ago. They are quite right that this is how it is. I would only say, as we said to Ofcom in January, that the length of time a thing has been done is not an argument that it ought to be. The envelope has been opened for thirty years. Thirty years of opening it has never once been a reason.</p>
<p>What Amnesty was worried about is the part I am worried about, and they got there before me. That the industry-standard filter already advertises AI and pattern analysis rather than the list Ofcom mandates. That the consultation nowhere discusses how any of this sits alongside the surveillance and intelligence powers we already have. That the new mandatory datasets could open fresh vectors for surveillance under bulk powers. And, in terms, that the infrastructure once built could be turned by the security services on URLs and numbers with nothing to do with scams, a point they thought worth making out loud given where this country currently sits on protest and dissent. United Nations experts got a mention. Their central recommendation was that Ofcom should not lean on generic data protection rules, and should define the purpose limits properly, because generic compliance with GDPR is not enough in 2026.</p>
<p>Ofcom's answer, in substance, is that it consulted the Information Commissioner and is satisfied the measures can be implemented in accordance with data protection law. Told that generic data protection would not hold the line, it confirmed that generic data protection was satisfied.</p>
<p>We should be very slow indeed to build this, because machinery outlives the intentions of the people who commission it. A tool built to catch a fake bank text is, mechanically, a tool that reads everyone's texts and drops the ones on a list. Change the list, and you change the target, and the second change is a great deal quieter than the first. We asked ourselves, in <a href="https://simwood.com/2025/02/are-we-evil/">Are we evil?</a>, whether we should wield rather less power than this. It is telling that Ofcom has mandated rather more, and asked itself rather less.</p>
<h4><em><strong>Made by no one you elected</strong></em></h4>
<p>Which brings me back to where I always seem to end up. None of this arrives as an Act, debated by people you can vote out. It arrives as guidance and General Conditions, drafted by an unelected regulator, which the industry will treat as law because the alternative is enforcement. I have <a href="https://simwood.com/2026/02/ofcoms-new-priority-protecting-wayne-rooneys-ego-while-ambulances-get-lost/">written before</a> of my fondness for the quaint American notion that lawmaking belongs to those closest to the People, and for the older instinct that it should be kept out of the hands of arbitrary decision-making by unelected nobles. You do not have to be a card-carrying libertarian to feel the hair on your neck rise when the power to inspect, and to silently suppress, private correspondence is created in this way, for the best of reasons, with the safeguards filed off somewhere between the consultation and the statement.</p>
<p>And I did not merely feel it, we filed it. <a href="https://www.ofcom.org.uk/siteassets/resources/documents/consultations/category-3-4-weeks/consultation-combatting-mobile-messaging-scams/responses/simwood-group-plc.pdf?v=415322">Our response to this consultation</a>, dated 28 January, told Ofcom that the balancing of over-blocking against fraud against invasion of privacy is a matter for an elected Parliament and not a sectoral regulator, and that the mere fact of today's industry practice proves neither that privacy rights have been upheld nor that what happens today is lawful. Ofcom's published answer to the first point runs to a single paragraph, and I will summarise it fairly: Ofcom has various duties relating to telephone numbers, including specific powers to make rules about mobile messaging, and it took them into account. That is a competent answer to the question are you allowed to. It is not an answer to the question should this be you. The second point, that industry practice is not proof of lawfulness, is recorded in the statement and answered nowhere, while the argument it was aimed at survives intact and is deployed more than once in support of the finished rules.</p>
<p>And look at who did the asking. Of the three mobile networks left in this country, Virgin Media O2 is owned outright by a Denver-run holding company incorporated in Bermuda and by Telefónica of Spain, behind which sit the Spanish state and Saudi Telecom. BT and Vodafone are British-incorporated, British-listed, and British-run, and their largest shareholders are an Indian conglomerate and, until last week, Abu Dhabi's state telecoms company. Sky, which is not a network at all but rides on Virgin Media O2, belongs to Comcast of Philadelphia. And VodafoneThree, our largest network, is forty-nine percent owned by CK Hutchison of Hong Kong until the sale to Vodafone completes later this year.</p>
<p>Hold that last one, because it is the most instructive thing I can offer you. When Li Ka-shing's conglomerate proposed to take a minority stake in a British mobile network, the machinery of the British state woke up. Two years of scrutiny. A review under the <a href="https://www.ispreview.co.uk/index.php/2024/05/government-security-review-clears-vodafone-and-three-uk-merger.html">National Security and Investment Act</a>. A Secretary of State. Binding mitigations, including a national security committee inside the merged company. Debates in the Commons. That is what it looks like when this country decides that something touches its interests: an Act, a Minister, and somebody you can hold to it.</p>
<p>Now count what it took to decide that those same networks may read the content of your correspondence and bin it without telling you. One consultation, one regulator, and one paragraph in reply when we asked whether it should be Parliament's call at all. We will spend two years deciding whether a Hong Kong billionaire may own half a network. We will spend an afternoon deciding what the network may read.</p>
<h4><em><strong>A floor is not a safe harbour</strong></em></h4>
<p>One more thing before I sum up, briefly, because it belongs in a different piece and I intend to write that piece. The record-keeping conditions require providers to keep false positive records for at least two years, challenge correspondence for at least one, and KYC and KYT material for at least three after the relationship ends. Note the words <em>at least</em>. Those are floors. I already suspect some will file them as ceilings, delete on schedule, and feel diligent about it.</p>
<p>Because here is what sits on the other side of the ledger. Under section 104 of the Act, the obligation to comply with a General Condition is a duty owed to every person who may be affected by a contravention, and a breach of that duty which causes someone loss is actionable by them. There are gates on it, and I will not pretend otherwise: Ofcom's consent is required, and a provider that took all reasonable steps and exercised all due diligence has a defence. But the ordinary limitation period for a claim of that kind is six years, and nothing puts an equivalent long-stop on Ofcom's own enforcement, which is administrative and not an action under the Limitation Act at all.</p>
<p>So line the numbers up. Two years of records. Six years of civil exposure. No outer limit on the regulator. And no requirement to retain the blocked message itself, which Ofcom confirms and justifies on data minimisation grounds. Add the missing notification, and the person who was wrongly blocked may not discover it for years, if ever, so their clock starts long after everyone's evidence has been lawfully shredded.</p>
<p>Which leaves the operator somewhere genuinely uncomfortable, and this is the part that ought to concentrate a few minds in compliance departments. You will be told what to keep and for how long. You will be told you need not keep the message. And you may then be asked, years later, to account for a decision you no longer hold the evidence to defend. Complying with the minimum is not a defence. It is simply a tidier way of having nothing to say for yourself. That deserves a piece of its own, and it will get one.</p>
<h4><em><strong>To be clear</strong></em></h4>
<p>Let me be unambiguous, because I fully expect to take fire from both directions for this, and I would rather choose the words that get misquoted. The scrotes will wave this blog about as cover for carrying on regardless, and the virtue-signalling luvvies who cheerlead every draconian intervention going will brand me an apologist for fraud. Both will quote me selectively, and neither will be right. Fraud is real, it does grievous harm, and stopping it is both the will of Parliament and a matter of basic decency. We do not need Ofcom to tell us to fight it; we jettison revenue every month doing exactly that, and we would happily do more if the rest of the industry would stop talking and start acting. My objection is not to the mission. It is to a design that deputises private companies, ours now among them, to read the content of lawful messages, block them in silence, with the duty to carry the legitimate ones traded away on request and nobody told when they are dropped, all of it authored by a body that no one elected.</p>
<p>Get those five things right and I will be first in the queue to help. Get them wrong, and this statement will be remembered less for the scams it stopped than for the precedent it set.</p>
<p>One last thing, and it is the tell. The rules come into force in two waves. The A2P rules, the ones about commercial messaging sent by businesses that can be identified, contracted with, and held to account, are given twelve months, and bite on 15 July 2027. The P2P rules, the ones that reach into private correspondence between individuals, are given six, and bite on 18 January 2027. Whatever the operational logic, the effect is that the more intrusive half arrives first and gets half the time to prepare. There is still time to do this properly.</p>
<p><em>Source: <a href="https://www.ofcom.org.uk/phones-and-broadband/scam-calls-and-messages/consultation-combatting-mobile-messaging-scams">Ofcom, Statement: Combatting mobile messaging scams, 15 July 2026</a>. All General Conditions cited in this piece are General Condition C9 as imposed by the Notification at Annex 1 to that statement, dated 15 July 2026, and not as the General Conditions read today.</em></p>
]]></content:encoded>
	</item>
	<item>
		<title>Stop Building Everything Yourself: Why the Fastest Route to Innovation is Often Partnership</title>
		<link>https://simwood.com/2026/07/stop-building-everything-yourself-why-the-fastest-route-to-innovation-is-often-partnership/</link>
		<dc:creator><![CDATA[Raj Dass]]></dc:creator>
		<pubDate>Fri, 24 Jul 2026 15:38:00 GMT</pubDate>
		<category><![CDATA[intelligent-solutions-us]]></category>
		<category><![CDATA[commercial]]></category>
		<guid isPermaLink="true">https://simwood.com/2026/07/stop-building-everything-yourself-why-the-fastest-route-to-innovation-is-often-partnership/</guid>
		<description><![CDATA[In every conversation I have with UCaaS providers, one theme keeps emerging.
There is an understandable desire to build.
Build the new voice capability. Build the messaging platform. Build the AI integration. Build the carrier connectivity. Build the APIs. Build the compliance layer.
After all, building creates ownership, control and differentiation.
But there is another side to the equation that isn't discussed nearly enough.
Every engineering sprint spent recreating infrastructure that already exists is a sprint not spent building the features your customers will actually pay for.]]></description>
		<media:thumbnail url="https://simwood.com/assets/og/blog-posts-2026-07-stop-building-everything-yourself-why-the-fastest-route-to-innovation-is-often-partnership-9689cfd291.png" width="1200" height="630" />
		<content:encoded><![CDATA[<p>In every conversation I have with UCaaS providers, one theme keeps emerging.</p>
<p>There is an understandable desire to build.</p>
<p>Build the new voice capability. Build the messaging platform. Build the AI integration. Build the carrier connectivity. Build the APIs. Build the compliance layer.</p>
<p>After all, building creates ownership, control and differentiation.</p>
<p>But there is another side to the equation that isn't discussed nearly enough.</p>
<p>Every engineering sprint spent recreating infrastructure that already exists is a sprint not spent building the features your customers will actually pay for.</p>
<h2></h2>
<p><strong>The Hidden Cost of &quot;Build&quot;</strong></p>
<p>Building communications capabilities is rarely as simple as it first appears.</p>
<p>Beyond the initial development effort comes the ongoing reality of operating carrier infrastructure, maintaining resilience, managing fraud, handling compliance, supporting numbering, monitoring quality, integrating with multiple networks and continually investing as the market evolves.</p>
<p>None of these activities are what make a UCaaS business unique.</p>
<p>They are simply the foundations that enable it.</p>
<p>Yet they consume engineering resources, product investment and valuable management attention.</p>
<p>Perhaps the biggest cost, however, is one that rarely appears in a business case.</p>
<p><strong>Time.</strong></p>
<p>Every month spent building is another month before customers can buy.</p>
<p>Another month before revenue starts flowing.</p>
<p>Another month where competitors can launch first.</p>
<h2><strong>Speed is Becoming a Competitive Advantage</strong></h2>
<p>The communications market has changed dramatically.</p>
<p>Customers no longer wait years for innovation. They expect continuous delivery of new capabilities, whether that's AI voice, conversational intelligence, WhatsApp, compliance features, analytics or new routing options.</p>
<p>Being first - or simply being early - creates commercial momentum.</p>
<p>Being late often means competing on price.</p>
<p>The companies that consistently win are not necessarily those with the biggest engineering teams.</p>
<p>They are often the ones that recognise where they should innovate themselves, and where partnering allows them to move faster.</p>
<h2></h2>
<p><strong>Build Where You Differentiate</strong></p>
<p>Every technology company should invest in its intellectual property.</p>
<p>But the question every leadership team should ask is:</p>
<p><strong>&quot;Is this capability what our customers buy us for?&quot;</strong></p>
<p>Customers choose UCaaS providers because of the user experience, integrations, workflows, AI capabilities, customer support and overall value delivered.</p>
<p>They rarely choose a provider because it built its own carrier network, numbering platform or voice infrastructure from scratch.</p>
<p>Those capabilities matter enormously, but they are enablers rather than differentiators.</p>
<p>The greatest return on engineering investment often comes from focusing developers on customer-facing innovation rather than rebuilding core communications infrastructure.</p>
<h2><strong>Partnership Accelerates Innovation</strong></h2>
<p>The best partnerships are not about outsourcing innovation.</p>
<p>They're about accelerating it.</p>
<p>By leveraging proven communications infrastructure, providers can introduce new services in weeks instead of months, reduce technical risk and keep engineering teams focused on creating experiences that customers genuinely value.</p>
<p>Instead of asking, &quot;How do we build this?&quot;</p>
<p>The better question may be:</p>
<p><strong>&quot;How quickly can we bring this to market?&quot;</strong></p>
<p>In today's market, speed creates opportunity.</p>
<p>Opportunity creates revenue.</p>
<p>Revenue funds further innovation.</p>
<p>That cycle is difficult to achieve when engineering teams are tied up rebuilding capabilities that already exist.</p>
<h2></h2>
<p><strong>The Commercial Impact</strong></p>
<p>Choosing to partner doesn't just reduce technical complexity, it changes business outcomes.</p>
<p>It can help organisations:</p>
<ul>
<li>Launch new services faster.</li>
<li>Generate revenue earlier.</li>
<li>Reduce upfront engineering investment.</li>
<li>Lower operational complexity.</li>
<li>Respond more quickly to changing customer demands.</li>
<li>Stay ahead of competitors entering the market with new capabilities.</li>
</ul>
<p>Most importantly, it allows businesses to focus on the innovations that truly differentiate them.</p>
<h2><strong>Where Simwood Fits</strong></h2>
<p>At Simwood, we've spent decades building the communications infrastructure that powers voice.</p>
<p>Today, that foundation extends beyond traditional carrier services into programmable communications, WhatsApp messaging and voice, AI-ready voice, conversational intelligence, numbering, compliance and global connectivity.</p>
<p>Our role isn't to replace your platform.</p>
<p>It's to help you expand it.</p>
<p>By providing the underlying communications capabilities as a trusted partner, we enable UCaaS providers to bring new products to market faster while keeping their engineering teams focused on the innovations that create lasting competitive advantage.</p>
<p>Because in a market that moves as quickly as communications, success is rarely about who builds the most.</p>
<p>It's about who delivers value to customers first.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Dialable, but not accountable</title>
		<link>https://simwood.com/2026/07/dialable-but-not-accountable/</link>
		<dc:creator><![CDATA[Peter Farmer]]></dc:creator>
		<pubDate>Thu, 23 Jul 2026 09:23:00 GMT</pubDate>
		<category><![CDATA[nuisance-calls-us]]></category>
		<guid isPermaLink="true">https://simwood.com/2026/07/dialable-but-not-accountable/</guid>
		<description><![CDATA[We have spent the better part of a decade going on about caller ID. Sending valid CLI, blocking the invalid stuff, dipping numbers to check they are real, alive, and able to take a return call. Most of that work is aimed at the obvious scrotes, the spoofers and the offshore dialler traffic no honest network should carry. But the longer you spend cleaning a thing, the more you notice the smudges nobody else is looking at. Here is one we cannot un-see.]]></description>
		<media:thumbnail url="https://simwood.com/assets/og/blog-posts-2026-07-dialable-but-not-accountable-6db2f9adb6.png" width="1200" height="630" />
		<content:encoded><![CDATA[<p>We have spent the better part of a decade going on about caller ID. Sending valid CLI, blocking the invalid stuff, dipping numbers to check they are real, alive, and able to take a return call. Most of that work is aimed at the obvious scrotes, the spoofers and the offshore dialler traffic no honest network should carry. But the longer you spend cleaning a thing, the more you notice the smudges nobody else is looking at. Here is one we cannot un-see.</p>
<p>Start with why a marketing operation has to show you a number at all. It is not decoration, it is accountability. The rules make a marketer present a contactable line so that you, the person on the receiving end of a call, can work out who rang and ring them back. Being reachable is the price of being allowed to call strangers.</p>
<p>Now watch it unravel, quietly and entirely within the law. You ring the number back, and because you have had quite enough of these calls, you withhold your own number. You are perfectly entitled to; that privacy choice is protected, and not only by PECR but within the CLI rules themselves. The marketer's platform sees an anonymous inbound call and rejects it. Anonymous Call Reject is a legitimate feature, older than most of the people now leaning on it. And the presented number is still, in the technical sense, dialable. We would know, diallability is our day job, and a number sitting behind ACR can pass our dips when we present a CLI.</p>
<p>So each individual piece is lawful. The number is presented. The number is dialable. The caller may withhold. The recipient may screen. And yet the one outcome the presentation rule exists to deliver, that you can actually reach the people who rang you, has been quietly engineered away. Worse, it has been engineered away for exactly the people the rule is there to protect, because those most likely to call back with a withheld number are the ones complaining or opting out, and who would rather not hand their number to the very operation that just interrupted their dinner.</p>
<h4><strong>The gap is not technical, it is in the spirit</strong></h4>
<p>This is not a diallability problem, and we want to be careful about that, because the reflex is always to reach for a technical fix. There isn't one to reach for. The number works, technically. The letter of the rules is satisfied. What is defeated is their object, and that is a harder and more interesting problem than a malformed prefix. A party that is under a legal duty to be reachable is using a legitimate feature to be selectively unreachable, and it has chosen to be unreachable to precisely the people the duty was written for.</p>
<h4><strong>What we have done about it</strong></h4>
<p>We have put the question to Ofcom, plainly. Not as a formal complaint, because in law there is nothing obvious to complain about, but as a gap between letter and spirit that someone holding the pen should probably look at, whether that turns out to be a line in the CLI Guidance, a tweak to C6, or a quiet word with the ICO, who own the marketing end of this.</p>
<p>We would always rather surface these things and get them closed than leave them sitting there as an unadvertised technique for the scrotes who collect such techniques. Confidence in CLI is built one boring, unglamorous fix at a time. Consider this one more of them, and another action taken by a network that genuinely wants to do something positive for society about the subject matter.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
