The clock is ticking toward 4 PM in my study, and the light over the Macedon Ranges is turning the kind of gold that usually signals the end of a productive day. I have just finished seventeen documents for a healthcare client — clinical strategy, PWA logic flows, staff training modules. I had been working in my native tongue, Google Docs, and I felt like the architect. I had built something sophisticated: a tool that would help fifty frontline workers do their jobs better.
Then I move to deliver the work, and the gold light fades.
My client is locked in a Microsoft SharePoint and Teams environment. In Australian healthcare this is not so much a software choice as a geographical reality: if a document is not a .docx file sitting in a specific, nested sub-folder of a Teams channel, it does not exist.
So the work is finished, and the work begins again.
What the conversion actually is
It has six steps, and I have never once counted them out loud. Download each document from Google as a Word file. Check that what landed is the version I meant. Round up seventeen files from my Downloads folder, where they have arrived like orphans. Rename them to the client's conventions. Find the right folder inside their SharePoint. Upload, and hope the letterhead and the formatting have survived the trip.
Forty-five minutes, on a good day. On this day I click through General, then Resources, then Project Alpha, then 2026, then Phase 2, then Drafts. Not there. Files, Shared Documents, Consultant Uploads. Empty. I have worked with this organisation for five months — weekly meetings, daily chats — and I cannot find where to put my own work.
It isn't you, and you're not the only one doing this
Forty-five minutes hunting for a folder is not just lost time. It is the moment you stop asking whether the tool is wrong and start asking whether you are. Am I not technical enough? Why can everyone else find this?
Here is the part worth holding on to. For an organisation with a 200-person IT department, a SharePoint sync error is a ticket. Someone else's afternoon, resolved without interrupting a single billable hour. For a one-person office, the same error is a career interruption — absorbed entirely by the person who is also the strategist, the deliverer and the biller.
You are not doing this badly. You are doing, unpaid and alone, what your client's organisation pays a department to do. The cost is real, it is structural, and it is invisible, which is exactly why it gets mistaken for a personal failing. Nearly every consultant I know who works in Google and delivers into Microsoft is running this same ritual, and most of them think they are the only one.
Why it is like this
Two reasons, and neither is going away soon.
The first is that Microsoft is not a vendor in Australian healthcare, education and government. It is the standard. To board members who built their careers in blue-chip organisations, Microsoft feels safe and Google feels dodgy — despite Google Workspace holding the same IRAP PROTECTED assessment Microsoft does. They do not use Teams especially well either; the General channel is usually a graveyard. But they trust the weight of the brand, and they are not wrong to want a standard.
The second is that Google and Microsoft appear content to let us absorb the cost of their competition. There is no good reason I cannot save a Google Doc back into its own Drive folder as a .docx. It would not dent either company's revenue. It would change the working life of every solo operator in the country.
So stop trying to remove it
This is the shift that took me too long. I kept treating the conversion as a failure — an interruption to the real work, evidence I had chosen the wrong stack. It is not a failure. It is part of the process, the same way invoicing is part of the process. It is not going to disappear because I resent it.
What changes is whether I do it by hand, at the end of a long day, while quietly wondering if I am the problem.
What I built instead
So I built the conversion a home. Not a clever trick — a small, dull, repeatable system, and every part of it lives in my own Drive where I can keep it.
Two folders. One holds the native Google Docs I work in. The other receives the Word exports, one sub-folder per client per delivery. Nothing touches my Downloads folder again.
A sheet with tickboxes. One row per document: the link, a checkbox, the client's naming pattern. I tick what I want and choose one menu item. Apps Script — which Gemini wrote for me — exports each ticked document straight to Word, into the delivery folder, already correctly named. Seventeen documents, one action.
The whole export is one call to the Drive API, and it is worth seeing how small it is:
const blob = Drive.Files.export(docId,
'application/vnd.openxmlformats-officedocument.wordprocessingml.document');
DriveApp.getFolderById(deliveryFolder).createFile(blob).setName(exportName);
That is the line that removes the Downloads folder from my life. About a dozen lines around it handle the sheet, the naming and the stamp. I did not write it from scratch; I described what I wanted and Gemini wrote it, which is the entire argument of this suite in miniature.
If you want to build the same thing, this is the prompt. Open Gemini, paste it, and change the bracketed parts to match your own setup:
Write a Google Apps Script bound to a Google Sheet, for a consultant who works in Google Docs and delivers
.docxfiles to clients.The sheet has one row per document with these columns: Document Name, Doc URL, Include (a checkbox), Naming Pattern, Exported At, Source Revision.
Add a custom menu called Delivery with one item, Export ticked documents. When I run it, the script should:
- Read every row where Include is ticked.
- Extract the file ID from the Doc URL.
- Export each document as
.docxusingDrive.Files.exportwith the MIME typeapplication/vnd.openxmlformats-officedocument.wordprocessingml.document.- Save the file into a delivery folder whose ID I set in a constant at the top, creating a
<client>/<yyyy-MM-dd>sub-folder if it does not exist.- Name the file using the Naming Pattern in that row, supporting the placeholders
{name},{date}and{version}.- Write the export timestamp back to Exported At and the document's current revision ID to Source Revision.
- Untick Include when the export succeeds, so a re-run does not duplicate work.
Handle errors per row rather than aborting the whole run: if one document fails, write the error into that row and carry on. Note that the export endpoint caps at 10 MB, so catch that case and report it clearly. Tell me which Advanced Drive Service I need to enable and how to enable it.
It will give you working code and tell you which service to switch on. If something breaks, paste the error back and it will fix it. That loop — describe, run, paste the error back — is the whole skill, and it is a good deal more accessible than it sounds.
A version stamp. The script writes each document's source revision and the export time back into the sheet, so I never wonder whether the file in the folder is the one I meant. That sheet is also a delivery record I can hand to a client, which has quietly made me look more organised than I am.
A client map. One row per client holding the direct link to their drop folder, their naming convention, their template. I paid the forty-five minutes once. I have not navigated their labyrinth since. Ask for the link at kickoff and you never pay it at all.
A template check, done once instead of anxiously every time. Google-to-Word conversion breaks in five predictable places: header and footer images, custom styles, page-number fields, complex table borders, and fonts the client does not have. I build from a converted copy of the client's own template, check those five things once, and then trust it. The anxiety used to be priced per document. Now it is priced per template.
What it gives back, and what it does not
I want to be straight about the limits, because a system you have been oversold is worse than no system.
The last step is still manual. I drag the files into their SharePoint folder myself, because I have no standing in their tenant to automate it — Apps Script cannot push into a Microsoft tenant where I have no app registration, and I would not want that standing even if it were offered. But it is thirty seconds into a known location, not forty-five minutes of detective work.
Formatting is checked, not guaranteed. And the export endpoint caps at 10 MB for converted files, which is fine for strategy documents and will refuse a very large one.
What I got back was not really the time. It was the end of the small nightly argument with myself about whether a competent person would find this easier.
Don't build what you can't keep
One rule came out of it that I would offer to anyone in the same position.
I once spent eight hours building an automation inside a client's Power Automate licence. The screens did not match the documentation. The interface had changed since the documentation was written. I lost an entire workday to a five-minute task — and when the engagement ended, so did my access. I could not invoice it, could not keep it, and could not build on it again.
That is the sovereignty question in its most ordinary clothes. It is not really about where data is hosted. It is about whether the machinery you build on a Tuesday is still yours on a Friday. Build inside someone else's tenant and you are renting your own competence back from them.
So: build in your own environment, deliver the artefact, keep the machinery. The client gets the .docx and the delivery manifest. You keep the sheet, the script and the map — and they are waiting for you on the next engagement, and the one after that. The work compounds instead of evaporating.
The conversion is part of the job. Your judgement is the job. Put the first one on rails so it stops taking the second one with it.