From repetitive task to AI project brief: Tech-and-GO! tools and TSS

Introduction

A programme executive spends Friday afternoon copying service details from emails and web pages into a public referral directory. The job repeats every week. Entries still go stale. Someone suggests AI, and the conversation jumps straight to products and grants.

Slow it down. The useful starting point is the Friday-afternoon job: who does it, what arrives, where judgement is needed, how often errors occur, and what a better week would look like. That description can become a project brief. It also gives a vendor less room to sell an impressive solution to the wrong problem.

This guide shows how to write that brief. It uses NCSS's current funding pages for programme facts and the continuing Tech-and-GO! toolkits for planning. The project-framing method is a Social Tech Guild working recommendation, not an NCSS application template or a promise of eligibility or funding.

What the current NCSS route covers

NCSS describes TSS as funding for social service agencies to undertake consultancy, digital projects and project implementation support. Its current page lists three parts: consultancy and implementation support, bespoke digitalisation projects, and pre-scoped or Green Lane solutions.[1]

The numbers matter, but they are ceilings rather than entitlements. On 23 August 2026, NCSS stated that support could be up to 80% co-funding for up to three years. It listed maximum funding of S$250,000 for Part A, S$150,000 for Part B, and S$150,000 in total for Part C, with a usual per-solution cap of S$40,000 or the specific Green Lane cap.[1] The current Green Lane page lists an “AI Personal Productivity Solution” with a maximum fundable amount of S$30,000. A selected solution must meet at least two of its three stated categories: document and content creation, communication management, and knowledge and research.[3]

Do not choose a category by keyword. A custom workflow, a general productivity product and implementation support are different purchases. Ask NCSS which route fits the proposed scope before seeking quotations.

Eligibility and application checks

The TSS page lists organisational, operating-history, board and assessment conditions. It requires a valid Organisational Health Framework for Social Services (OHFSS) assessment; Parts A and B also require completion of organisational health diagnostics. Applications go through the OurSG Grants portal, and the documents shown for application include a valid OHFSS report and vendor quotation.[1]

The current CCT FAQ says the OHFSS assessment must have been completed within the previous 12 months. The FAQ, updated November 2025, also adds two useful cautions: a project cannot receive double funding, and it must not start before the application is approved.[4] The current TSS page also says proposals are assessed on their merits, including fit with social service delivery, relevance of the capability, need for support, cost-effectiveness and expected sector benefit.[1]

Those are source-reported conditions, not an eligibility assessment for your agency. Programme pages and requirements can change. Read the current page and FAQ, then confirm uncertainties with NCSS at the contact listed there before committing money or signing a start date.

Write the brief before asking for quotations

A good brief fits on a few pages. It should let a colleague who does the work recognise it, let a provider price the same scope as its competitors, and let an approver see what will be tested.

NCSS's Tech-and-GO! page has separate toolkits for digital strategy planning, technical evaluation and project implementation. NCSS tells agencies to choose the toolkit according to the project's purpose and customise its templates.[2] The Digital Acceleration Index page also points agencies through strategy, solution review and the TSS funding step.[5]

Use those official resources for the full process. For the first draft, answer the seven parts below in plain language.

1. Describe the problem as work

Name one repeated action. “Improve knowledge management” is too broad. “Every Tuesday, a coordinator checks six public sources and updates a referral sheet used by the helpline” is something a team can inspect.

Add the reason the work exists and the consequence of doing it badly. A referral directory is meant to help staff and members of the public find an appropriate service. A stale phone number wastes time. A wrong eligibility description may misdirect someone seeking help. That consequence should shape both the solution and the review.

Map exceptions before calling the process routine. Programme names change. A service may pause intake without removing its page. Eligibility wording can depend on age, location or referral route. If staff resolve these cases through judgement or a phone call, include that work rather than describing the process as simple copying. NCSS's Digitalisation Playbook recommends a user-centred approach and provides journey-mapping support for documenting processes and touchpoints.[6]

2. Take a small, honest baseline

Measure the current job for two to four ordinary cycles. Count preparation, checking, correction and follow-up, not just typing time. Record where the information came from and which exceptions took longest.

For a directory, a workable baseline might include active staff minutes per update cycle, elapsed days from a source change to a public correction, entries checked, stale entries found, corrections requested by users, and the share of entries with a recorded source and check date.

Use data your team can collect without building another system. A rough baseline with definitions is more useful than a precise-looking estimate nobody can reproduce. Keep unusual weeks visible. If one update took twice as long because a provider's web page was unclear, that is design information rather than an outlier to hide.

3. Put the people in the scope

The person doing the task can explain the awkward cases. The person using the output can explain which mistakes matter. Bring both into scoping and provider demonstrations.

Name a process owner who decides what “current” and “accurate” mean. Name the person who approves public changes, the colleague responsible for data protection or IT review, and the person with authority to pause. If a provider will configure the service, say who accepts that work. Protected review time belongs in the cost.

Keep the service boundary visible. A public directory may contain public organisational information, yet staff notes, contact histories and unpublished service changes may be confidential or contain personal data. “It is all online” is not a data classification.

4. Ask for the smallest useful solution

A first version does not need to find, decide and publish by itself. It could compare a defined set of public pages with the existing directory, flag likely changes, quote the source passage and prepare a draft for review. The reviewer remains responsible for checking the official source and approving any edit.

Keep source links and retrieval dates beside every suggested change. Limit the pilot to a small set of entries and approved sources. Do not connect it to the public directory until the team has tested the draft-and-review workflow. Retain the current update method as the fallback.

Ordinary automation may be enough. Scheduled reminders, required source fields and a simple “last checked” report could solve most of the problem without generative AI. A useful brief states the outcome and lets providers explain why their proposed method is proportionate. For a wider screen of first-project risk, use the first AI project scorecard.

6. Measure the whole pilot

Choose one main workflow measure and a few guardrails before the demonstration. For the directory, the main measure might be total staff minutes per completed update cycle. Guardrails could cover the age of unchecked entries, factual errors, unsupported suggestions, reviewer corrections and public complaints.

Time the preparation and review. A tool that drafts in ten seconds but creates an hour of verification has moved the work rather than removed it. Sample entries that did not change as well as those the tool flagged. Otherwise the team can measure how well suggestions look while missing silent failures.

Agree the comparison period and sample size in advance. Record the version and configuration being tested. Keep rejected suggestions. At the end, choose among a narrow continuation, redesign or stop, as well as scale. The wider implementation guide covers data mapping, responsibility, testing and adoption in more depth.

Prepare the funding conversation

Bring the problem statement, baseline, process map, named owners, smallest scope, provider questions, pilot scorecard, stopping rule and fallback into the Tech-and-GO! templates. Then add the documents and outcomes required by the current TSS route.

Before submission, check the live NCSS page rather than copying figures from this article. Use the AI vendor due-diligence guide when preparing provider questions and evidence requests. Confirm which part applies, whether the OHFSS assessment and organisational health diagnostics are current, how many quotations are needed, which costs and dates are supportable, and what evidence the completion report will require. Do not begin the project while approval is pending.[1][4]

A clear brief cannot secure funding. It can make the decision better. Your team can see the work it is changing, providers can answer the same scope, and NCSS can assess a proposal tied to a real operating need rather than a general wish to “use AI”.

About the author

Darren writes about practical technology choices for Singapore's social service sector through Social Tech Guild.