Microsoft Forms로 사내 신청・의뢰 접수창구 만들기 ── 메일과 구두 의뢰를 폼으로 모으기

「서버 계정을 만들어 달라」는 메일로 도착하고, 「프린터 상태가 안 좋으니 봐 달라」는 복도에서 스쳐 지나가며 구두로 부탁받고, 「이 청구서 처리 부탁드립니다」는 책상에 포스트잇으로 붙어 있다. 정보시스템이나 총무・경리처럼 사내 의뢰를 받는 부서로부터, 이런 상황을 어떻게든 하고 싶다는 상담을 자주 받습니다.

의뢰하는 쪽은 「말했으니까 해 줄 것」이라고 생각하고, 받은 쪽의 기억과 메일함만이 의지가 됩니다. 하필 바쁜 날에 한 건이 빠져서, 「그 건 어떻게 됐어요?」로 발각됩니다. Microsoft 365를 도입한 회사라면, 이 문제는 Microsoft Forms를 접수창구로 삼고 Power Automate로 알림과 기록을 자동화하는 「접수의 형태」로 상당 부분 해결할 수 있습니다. 이 글에서는 폼 설계의 실무, 파일 업로드 제약, 접수 플로우의 기본형, 그리고 Forms 단독의 한계와 목록 전기가 정석이 되는 이유까지 정리합니다. 승인・결재 자체의 설계는 별도 글인 「Power Automate로 승인 플로우 만들기 ── 종이와 메일의 품의・신청을 전자화하다」가 주역이므로, 이 글은 「접수」에 초점을 맞춥니다.

대상 독자와 전제 환경

• 대상 독자: 정보시스템・총무・경리 등, 사내에서 의뢰나 신청을 받는 쪽의 담당자. Power Automate를 다뤄본 적이 없다는 전제로 작성했습니다.
• 전제 환경: Microsoft 365를 도입했고, Microsoft Forms와 SharePoint를 사용할 수 있을 것. 플로우 작성에는 Power Automate를 사용할 수 있는 라이선스가 필요하지만, 이 글에서 사용하는 Forms・SharePoint・Outlook・Teams 커넥터는 모두 표준 커넥터 범위이며 프리미엄 커넥터는 등장하지 않습니다(경계 정리는 「Power Automate의 라이선스와 표준・프리미엄 커넥터의 경계」).
• 필요한 권한: 폼을 두는 그룹(팀)의 멤버일 것, 전기 대상 SharePoint 사이트에 목록을 만들 수 있을 것. 테넌트 관리자 권한은 필요하지 않지만, 응답자 이름 기록의 기본값이나 외부 공유 가능 여부는 관리자 설정으로 정해집니다.¹
• 이 글에서 만드는 것: 의뢰를 접수하는 폼 1개, 접수 대장인 SharePoint 목록 1개, 접수 시 동작하는 클라우드 플로우 1개입니다.

1. 먼저 결론

• 의뢰 접수창구는 「입력의 형태」와 「기록의 보관 장소」를 세트로 설계합니다. 현실적인 최소 구성은 「Forms로 접수 → Power Automate로 SharePoint 목록에 전기 → 알림」입니다.
• 플로우의 기본형은 트리거 「새 응답이 제출되면」과 액션 「응답 세부 정보 가져오기」의 2단계입니다. Forms 커넥터에는 이 1트리거・1액션(+폼 세부 정보 가져오기)밖에 없어, 외워야 할 것이 많지 않습니다.²³
• 공개 범위는 조직 내 한정이 원칙입니다. 「이름 기록」을 활성화하면 응답자의 이름과 이메일 주소가 자동으로 기록되어, 성명・소속을 적게 할 필요가 없어집니다. 조직 외에도 여는 설정에서는 응답이 익명이 되어 누가 제출했는지 기록되지 않습니다.⁴
• 파일 업로드 질문은 조직 내 한정 폼 전용입니다. 하나의 질문에서 최대 10개 파일, 파일당 상한은 10MB・100MB・1GB 중에서 선택하며, 파일은 OneDrive for Business에 저장됩니다.⁵
• Forms는 접수창구 전용이라고 확실히 선을 긋는 것이 오래 유지하는 요령입니다. 제출 후 수정이나 진행 상황 확인 기능은 없고, 응답 목록에도 상태 관리 구조가 없기 때문에, 대장은 SharePoint 목록 쪽에 두게 합니다.⁶
• 응답 수 상한은 직장・학교 계정에서 최대 5,000,000건으로 사내 이용에서는 사실상 무제한이지만, 50,000건을 넘으면 개요 그래프나 개별 응답 열람을 사용할 수 없게 됩니다. 상한보다 먼저 「목록 관리의 약함」이 한계가 됩니다.⁷
• 사외로부터의 접수에서 첨부가 필요하다, 건수가 많아 기간계 시스템과 연계하고 싶다, 진행 상황을 의뢰자에게 공개하고 싶다 ── 이 부근부터 Forms의 대응 범위를 넘어서기 시작합니다. 선긋기는 7장의 판단표에 정리합니다.

2. 메일・구두 의뢰의 무엇이 문제인가

메일과 구두로 의뢰를 받는 운영의 문제는, 담당자의 노력으로는 해결할 수 없는 구조적인 부분에 있습니다.

• 누락이 구조적으로 발생합니다. 의뢰가 수신함・채팅・구두・포스트잇이라는 각기 다른 경로로 도착하기 때문에, 「전체 목록」이 어디에도 존재하지 않습니다. 한 건도 놓치지 않는 것을 개인의 기억력에 걸고 있는 상태입니다.
• 서식이 제각각이라 왕복이 늘어납니다. 「PC 설정 부탁드립니다」라는 메일만으로는 대상 PC, 희망일, 사유를 알 수 없어 되묻는 왕복이 발생합니다. 의뢰할 때마다 필요 사항을 떠올려 적는 것은 의뢰하는 쪽에게도 부담입니다.
• 상태가 보이지 않아 「말했다・안 했다」가 됩니다. 의뢰자 입장에서는 접수가 되었는지, 착수했는지, 언제 끝나는지가 보이지 않습니다. 담당자가 「듣지 못했습니다」라고 하면 진흙탕 싸움이 됩니다. 재촉과 확인을 주고받는 것 자체가 양쪽의 시간을 갉아먹습니다.
• 집계할 수 없습니다. 한 달에 몇 건의 의뢰가 있고 무엇에 시간을 쓰고 있는지에 대한 데이터가 남지 않기 때문에, 「사람이 부족하다」, 「이 시스템은 문의가 너무 많다」와 같은 이야기를 숫자로 보여줄 수 없습니다.

이러한 문제는 「의뢰의 입구를 하나로 하고, 필요 사항을 정해진 형태로 받으며, 접수한 순간 기록과 알림이 남는」 구조로 만들면 한꺼번에 해소 쪽으로 향합니다. Forms와 Power Automate를 사용하는 이유는, Microsoft 365를 도입한 상태라면 이 구조를 추가 비용 없이 만들 수 있는 경우가 많기 때문입니다(이 글에서 사용하는 Forms・SharePoint・Outlook・Teams의 각 커넥터는 표준 커넥터 범위입니다. 라이선스에 대한 사고방식은 「Power Automate의 라이선스와 표준・프리미엄 커넥터의 경계」에서 정리하고 있습니다).

3. 폼 설계 실무

질문은 「선택하게 하기」를 기본으로

폼 설계의 목표는, 의뢰자가 망설임 없이 제출할 수 있고 받는 쪽이 되묻지 않고 움직일 수 있는 정보가 갖춰지는 것입니다. 원칙은 「선택지로 받고 텍스트는 최소한으로」입니다.

• 의뢰 종류는 선택지로 만듭니다. 「계정 생성/PC・주변기기/소프트웨어 도입/기타」처럼, 나중에 집계와 플로우 분기에 사용할 축을 선택지로 확정합니다.
• 기한은 날짜 질문으로 받습니다. 「최대한 빨리」, 「이번 주 중」과 같은 편차를 없애고, 플로우 쪽에서 리마인드에도 사용할 수 있게 됩니다(영업일이나 마감일 처리는 「Power Automate의 정기 실행 플로우와 영업일 설계」에서 다루고 있습니다).
• 자유 기술은 「보충 설명」 질문 1개로 모으는 것이 기준입니다. 여기서 한 가지 실무상 주의할 점이 있습니다. 한 줄 텍스트(짧은 답변)에 255자를 넘는 입력이 있으면, 플로우가 동작하기도 하고 동작하지 않기도 하는 알려진 문제가 있습니다. 장문이 들어올 수 있는 질문은 처음부터 「긴 답변」(여러 줄 텍스트)으로 해 둡니다.⁸

그리고 「지나치게 많이 쓰게 하지 않는 것」입니다. 접수 폼의 역할은 의뢰를 빠짐없이 포착하는 것이지, 그 자리에서 모든 정보를 빨아들이는 것이 아닙니다. 질문이 많은 폼은 구두・메일로의 회귀를 초래합니다. 상세한 청취가 필요한 안건은 접수 후 담당자가 연락하는 것을 전제로, 폼은 몇 분 만에 제출할 수 있는 수준으로 억제합니다.

분기로 「관계없는 질문」을 보여주지 않기

의뢰 종류에 따라 물어야 할 내용이 다른 경우에는 분기(branching)를 사용합니다. 선택지 응답에 따라 다음에 표시할 질문이나 섹션을 전환할 수 있기 때문에, 「계정 생성이라면 대상 시스템과 권한을, 기기 고장이라면 자산 번호와 증상을」과 같이 응답자에게는 관계있는 질문만 보여줄 수 있습니다. 분기는 뒤쪽 질문으로만 건너뛸 수 있어(앞쪽 질문으로는 되돌아갈 수 없어), 공통 질문을 전반부에, 종류별 질문을 섹션으로 나누어 후반부에 배치하는 구성이 짜기 쉽습니다.⁹

공개 범위와 응답자 정보 ── 조직 내 한정과 익명의 차이

Forms의 공개 범위는 3종류가 있습니다.⁴

사내 신청・의뢰 접수창구는 조직 내 한정이 원칙입니다. 이유는 세 가지입니다.

1. 「누가 제출했는지」를 적게 하지 않아도 됩니다. 「이름 기록」을 활성화하면 응답자의 이름과 이메일 주소가 응답에 자동으로 붙습니다. 성명・소속・연락처라는 「매번 똑같은 것을 쓰는」 질문을 통째로 없앨 수 있습니다.⁴
2. 1인 1회 제한이나 파일 업로드 등, 조직 내 한정에서만 사용할 수 있는 기능이 있습니다. 「1인당 하나의 응답」도 조직 내 한정인 경우에만 설정할 수 있습니다.⁴
3. 플로우로 의뢰자에게 회신할 수 있습니다. 응답 세부 정보에 응답자의 이메일 주소(Responders’ Email)가 포함되기 때문에, 접수 완료 메일을 그대로 보낼 수 있습니다(5장). 익명 폼에서는 이것이 불가능합니다.¹⁰

참고로 조직 전체의 기본값으로 응답자 이름을 기록할지 여부는 Microsoft 365 관리 센터의 Forms 설정(「기본적으로 이름 기록」)에서 관리자가 제어할 수 있습니다. 외부 공유(조직 외부로의 응답 요청) 자체를 테넌트 차원에서 허용할지 여부도 같은 화면의 설정입니다. 회사 차원에서 「사내 설문조사는 익명이 기본」과 같은 정책이 있는 경우에는 이 부분도 확인해 둡니다.¹

그럼에도 사외에 열어야 할 필요가 있는 경우에, 무엇을 잃게 되는지도 정리해 둡니다.

• 누가 제출했는지 기록되지 않습니다. 조직 외부에도 연 폼의 응답은 익명이 되어, 응답자는 로그인하지 않고도 제출할 수 있습니다.¹¹ 사칭도 중복 제출도 폼 쪽에서는 막을 수 없습니다. 「1인당 하나의 응답」 제한도 조직 내 한정에서만 사용할 수 있으므로, 같은 사람이 몇 번이든 보낼 수 있습니다.⁴
• 첨부를 받을 수 없습니다. 파일 업로드 질문은 조직 내 한정 폼 전용입니다.⁵
• 플로우에서 의뢰자에게 회신할 수 없습니다. 응답자의 이메일 주소(Responders’ Email)를 가져올 수 없기 때문에, 접수 완료 메일 자동 회신이라는 가장 효과적인 장치를 사용할 수 없게 됩니다(이메일 주소를 자유 기술로 적게 하는 운용은, 수신처 오타가 그대로 도착하지 않는 메일이 됩니다).
• 애초에 허용되어 있지 않은 경우가 있습니다. 외부 공유는 테넌트 관리자 설정으로 금지할 수 있기 때문에, 링크를 배포해도 응답할 수 없다는 사고가 발생합니다. 사전에 관리자에게 확인하시기 바랍니다.¹

사외용은 「건수가 적고 첨부도 본인 확인도 필요 없는 설문조사적인 접수」까지가 안전권입니다. 그것을 넘어선다면 7장의 판단표대로 웹 폼 쪽 설계로 전환합니다.

개인 폼인 채로 두지 않기 ── 작성자의 퇴사에 대비하기

간과되기 쉽지만 중요한 논점입니다. 개인이 만든 폼은 그 사람의 계정에 연결되어 있어, 퇴사 등으로 계정이 테넌트에서 삭제되면 계정 관련 데이터는 삭제로부터 30일 후에 사라집니다.¹¹ 접수 폼은 업무의 입구이므로, 담당자 개인의 소유물로 하지 말고 그룹(팀)의 폼으로 만들거나, 부서 이동・퇴사 시 소유권을 이관하는 운용을 정해 둡니다.⁸

한 가지, 플로우 쪽에서 주의할 점이 있습니다. 그룹 폼은 Power Automate 트리거의 폼 ID 목록에 표시되지 않기 때문에, 폼 편집 화면 URL에 있는 FormId= 이후의 값을 복사하여 폼 ID로 직접 입력해야 합니다.³ 수고가 하나 더 들지만, 특정인 의존을 피하는 가치가 더 큽니다.

4. 파일 업로드 사양과 제약

「견적서 PDF를 첨부하여 구매 신청」, 「오류 화면 스크린샷을 첨부하여 장애 보고」처럼, 의뢰에 첨부 파일이 따르는 경우는 많습니다. Forms의 파일 업로드 질문 사양은 정확히 파악해 둘 필요가 있습니다.⁵

• 조직 내 한정 폼 전용입니다. 공개 범위가 「자신이 속한 조직 내 사용자만 응답 가능」 또는 「조직 내 특정 사용자가 응답 가능」일 때만 추가할 수 있으며, 조직 외부에도 연 폼에서는 사용할 수 없습니다. 즉 「사외 거래처가 첨부 파일과 함께 신청하게 하는」 용도로는 Forms를 사용할 수 없습니다.
• 하나의 질문에서 최대 10개 파일까지 받을 수 있으며, 파일당 크기 상한은 10MB・100MB・1GB 중에서 선택합니다.
• 파일 종류를 제한할 수 있습니다. Word・Excel・PowerPoint・PDF・이미지・동영상・음성 중에서 허용할 종류를 선택할 수 있어, 「견적서는 PDF만」과 같은 방식으로 받을 수 있습니다.
• 저장 위치는 폼 소유자에 따라 달라집니다. 개인 폼이라면 작성자의 OneDrive for Business에 있는 「App > Microsoft Forms > (폼 이름) > (질문 이름)」 폴더에, 3장에서 권장한 그룹 폼이라면 그룹의 SharePoint 사이트에 응답자가 업로드한 파일이 쌓여 갑니다.

플로우에서 업로드 파일을 다루려면 수고가 하나 더 필요합니다. 「응답 세부 정보 가져오기」로 반환되는 업로드 질문의 응답은 파일명이나 ID를 포함한 JSON 문자열이므로, 「JSON 구문 분석(Parse JSON)」으로 스키마를 지정하여 분해하고, first(body('Parse_JSON'))?['id']와 같은 식으로 파일 ID를 꺼낸 뒤 파일 가져오기 액션으로 전달합니다.¹⁰

스키마를 만드는 방법은 공식 절차대로 실물에서 생성하는 것이 확실합니다. ① 플로우를 저장하고 테스트 실행하여 폼에서 파일을 하나 업로드한다 → ② 실행 이력에서 「응답 세부 정보 가져오기」를 열어 해당 업로드 질문의 출력을 복사한다 → ③ 「JSON 구문 분석」 액션의 「샘플에서 생성」에 붙여넣는다, 라는 3단계입니다.¹⁰

직접 작성하고 싶은 경우에는 사용할 프로퍼티만 선언한 최소 형태로 충분합니다(선언하지 않은 프로퍼티가 반환되어도 JSON 구문 분석은 통과합니다). 공유 링크를 만드는 데 필요한 것은 파일 ID뿐이므로 사실상 이것뿐입니다.

{
    "type": "array",
    "items": {
        "type": "object",
        "properties": {
            "id":   { "type": "string" },
            "name": { "type": "string" }
        },
        "required": [ "id" ]
    }
}

여기서 가장 중요한 주의점은 응답이 배열로 반환된다는 것입니다. 공식 식이 first(body('Parse_JSON'))?['id']처럼 첫 번째 요소를 꺼내는 형태로 되어 있는 것은 그 때문입니다.¹⁰ 참고로 first(...)는 파일이 하나라는 것을 전제로 한 작성법입니다. 여러 파일을 허용한 질문에서는 응답이 파일별 객체를 나열한 배열로 반환되므로, 구문 분석 결과를 Apply to each로 돌려 파일을 하나씩 가져옵니다(첨부가 하나로 충분한 의뢰라면 질문 쪽의 상한을 1개 파일로 해 두는 것이 간단합니다). 또한 파일 가져오기에 사용하는 커넥터는 앞서 말한 저장 위치에 맞춥니다. 개인 폼이라면 OneDrive for Business 커넥터, 그룹 폼이라면 저장 위치가 그룹의 SharePoint 사이트이므로 SharePoint 커넥터로 해당 사이트를 지정하여 가져옵니다. 그룹 폼에 대해 OneDrive 커넥터로 파일을 찾아도 발견되지 않는, 조합 착오가 자주 발생하는 걸림돌입니다.

받은 파일을 승인 요청에 첨부하여 돌리는 경우에는, 파일 콘텐츠를 바이너리로 첨부 필드에 전달합니다.¹² 다만 승인 액션이 메일에 첨부할 수 있는 파일은 5MB까지이며, 이를 넘는 첨부는 승인자가 Power Automate 포털의 승인 목록에서 확인하는 동작이 됩니다.⁸ 큰 파일은 첨부로 돌리지 말고 SharePoint에 저장하여 링크를 돌리는 쪽이 확실합니다.

5. Power Automate로 접수를 작동시키기

기본형은 2단계 + 3개의 출구

Forms는 응답이 도착해도 기본적으로는 아무에게도 알려주지 않습니다(폼 소유자용 알림 설정은 있지만, 수신처도 본문도 선택할 수 없습니다¹⁰). 접수를 업무로서 작동시키는 것은 Power Automate의 역할입니다. 플로우의 기본형은 트리거 「새 응답이 제출되면」으로 폼을 지정하고, 이어서 「응답 세부 정보 가져오기」로 각 질문의 응답을 동적 콘텐츠로 꺼내는 2단계입니다.² 그 다음 출구는 「대장에 기록」, 「의뢰자에게 접수 알림」, 「담당 팀에게 알림」의 3가지입니다.

flowchart TD
    Submit[의뢰자가 Forms로 제출<br/>조직 내 한정・로그인 완료] --> Trigger[새 응답이 제출되면<br/>클라우드 플로우 시작]
    Trigger --> Details[응답 세부 정보 가져오기<br/>응답을 동적 콘텐츠화]
    Details --> Record[SharePoint 목록에 항목 생성<br/>상태 - 접수완료]
    Record --> Ack[의뢰자에게 접수 완료 메일<br/>응답 내용 사본을 삽입]
    Record --> Team[담당 팀의 Teams 채널에 게시]
    Record --> Need{승인이 필요한 종류?}
    Need -- 예 --> Approval[승인 플로우로<br/>시작 후 승인 대기]
    Need -- 아니오 --> Work[담당자를 배정하여 대응]
    Approval --> Back[결과를 목록에 다시 기록]
    Work --> Back2[대응 상황을 상태 열로 갱신]

개념도와 실제 화면 사이의 간극이 가장 헷갈리는 부분이므로, 이 그림을 그대로 만들 때의 클릭 절차도 적어 둡니다. 전기 대상 SharePoint 목록은 먼저 만들어 두시기 바랍니다.

1. Power Automate 포털을 열고, 왼쪽 메뉴의 「만들기」에서 「자동화된 클라우드 흐름」을 선택합니다. 플로우 이름을 입력합니다.
2. 트리거 검색란에 「Forms」를 입력하고, 「새 응답이 제출되면」을 선택합니다.²
3. 트리거의 「폼 ID」에서 폼을 선택합니다. 그룹 폼은 목록에 나타나지 않으므로, 폼 편집 화면 URL의 FormId= 이후를 붙여넣습니다(3장).³
4. 「새 단계」→ 검색란에 「Forms」→ 액션 「응답 세부 정보 가져오기」. 여기서도 같은 폼을 지정하고, 「응답 ID」에는 트리거의 동적 콘텐츠 「응답 ID」를 넣습니다(자동으로 들어가 있는 경우도 있습니다).²
5. 「새 단계」→「SharePoint」→「항목 만들기」. 사이트 주소와 목록 이름을 선택하고, 각 열에 「응답 세부 정보 가져오기」의 동적 콘텐츠(각 질문의 응답)를 할당합니다. 상태 열에는 접수완료와 같은 고정값을 넣어 둡니다.
6. 「새 단계」→「Office 365 Outlook」→「메일 보내기(V2)」. 「받는 사람」에 동적 콘텐츠인 Responders’ Email을 넣고, 본문에 응답 내용 사본과 예상 소요 일수를 적습니다.¹⁰
7. 「새 단계」→「Microsoft Teams」→「채팅 또는 채널에 메시지 게시」. 담당 팀의 팀과 채널을 선택하고, 종류・기한・의뢰자와 목록 항목 링크를 싣습니다.
8. 오른쪽 상단의 「저장」→「테스트」로 수동 테스트를 시작하고, 실제로 폼에서 1건을 제출합니다. 각 단계의 입출력을 열어 값이 예상대로 들어가 있는지 확인합니다.

승인으로의 분기를 추가하는 것은 이 다음입니다. 먼저 위의 1~8만으로 「1건을 제출하면 대장에 올라가고, 의뢰자에게 메일이 가고, 팀에 알림이 뜨는」 지점까지 통과시킨 후에 조건 분기를 쌓아 가는 것이 안전합니다.

SharePoint 목록으로 전기하기 ── 접수 대장 만들기

접수한 의뢰는 플로우의 첫 부분에서 SharePoint 목록에 한 행씩 전기합니다. 목록에는 응답의 사본에 더해, 폼에는 없는 「관리를 위한 열」을 갖추는 것이 포인트입니다.

의뢰자에 대한 추가 질문이나 경위는 메일로 흩뜨리지 말고 이 목록(또는 목록 항목에 연결된 Teams 스레드)으로 모으면, 「말했다・안 했다」의 기록이 한곳에 갖춰집니다. 뷰를 「상태=미완료」로 만들면 조회에서 그대로 사용할 수 있는 대응 목록이 됩니다. Excel로의 전기용 템플릿도 있지만¹⁰, 여러 명이 계속해서 상태를 갱신하는 대장에는 뷰・열 형식・버전 이력을 가진 목록 쪽이 더 적합합니다. Excel 대장에서 목록으로 이행하는 사고방식은 「Excel 대장을 SharePoint 목록으로 교체하기 ── 공유・이력・플로우 연계로 「대장이 망가지는」 상황을 졸업하다」에 정리되어 있습니다.

접수 알림 ── 「도착했습니다」를 첫 1분 안에 돌려주기

메일 의뢰와 가장 체감 차이가 나는 부분이 여기입니다. 플로우에서 2종류의 알림을 보냅니다.

• 의뢰자에게 보내는 접수 완료 메일. 조직 내 한정 폼이라면, 응답 세부 정보에 포함된 응답자의 이메일 주소(Responders’ Email)로 Outlook 커넥터를 통해 그대로 보낼 수 있습니다.¹⁰ 본문에는 응답 내용 사본과 「3영업일 이내에 담당자가 연락드립니다」와 같은 안내를 삽입합니다. 의뢰자가 재촉하고 싶어지는 원인의 대부분은 「도착했는지조차 알 수 없다」는 것이므로, 이 메일 한 통으로 문의가 상당히 줄어듭니다. Forms 자체에도 응답자용 확인 메일 설정이 있지만, 문구를 업무에 맞출 수 있는 것은 플로우에서 보내는 방식입니다.¹⁰
• 담당 팀에게 보내는 Teams 알림. 개인 앞으로 메일을 보내면 다시 특정인 의존이 되므로, 담당 팀의 채널에 게시합니다. 종류・기한・의뢰자와 목록 항목 링크를 실어 두면, 채널이 그대로 「신규 의뢰 수신함」이 됩니다.

승인으로 연결하기

「소프트웨어 구매는 상사 승인이 필요하다」와 같은 종류는 접수 플로우에서 승인 액션(시작 후 승인 대기)으로 연결합니다. Forms의 응답 내용을 승인 요청에 삽입하는 템플릿도 마련되어 있어, 승인 결과에 따라 의뢰자에게 결과 메일을 돌려주는 형태까지 한 번에 구성할 수 있습니다.¹⁰ 승인 종류, 타임아웃과 독촉, 승인 기록을 남기는 방법과 같은 설계 논점은 「Power Automate로 승인 플로우 만들기 ── 종이와 메일의 품의・신청을 전자화하다」에서 자세히 다루고 있으니 그쪽을 참조하시기 바랍니다. 접수 플로우가 안정적으로 작동하기 시작하면, 플로우의 공동 소유자 설정과 오류 시 알림도 조기에 넣어 둡니다(오류 처리 설계는 「Power Automate의 오류 처리와 재시도 설계」를 참조).

6. Forms 단독의 한계 ── 그래서 목록 전기가 정석

Forms만으로 접수를 완결시키려 하면 다음과 같은 벽에 부딪힙니다.

• 제출 후 상태가 보이지 않습니다. 기본적으로 응답자는 제출한 내용을 나중에 수정할 수 없습니다. 작성자 쪽에서 응답자 본인에 의한 응답 저장・수정을 허용할 수 있는 설정이 배포된 환경도 있지만, 그것은 응답 내용의 수정 수단에 그칩니다. 폼 설정으로 마련되어 있는 것은 접수 시작・종료 일시나 1인 1회 제한 등이며⁶, 자신의 의뢰가 지금 어떤 상태인지(접수완료・대응중・완료)를 확인하는 화면은 없고, 「제출한 후」를 지원하는 기능은 없다고 생각하는 편이 실태에 맞습니다. 수정을 허용하지 않은 환경에서 수정이 「재제출」로 이루어지면, 어느 쪽이 최신인지는 받는 쪽이 판단하게 됩니다.
• 응답 목록의 관리 기능이 약합니다. Forms의 응답 화면은 집계와 열람을 위한 것으로, 상태 열도 담당자도 가질 수 없고 「미대응만 표시하기」도 불가능합니다. 접수 관리에 필요한 것은 목록을 「계속 갱신해 가는」 기능이지만, 그것은 Forms의 대응 범위 밖입니다.
• 상한은 건수보다 기능 면에서 먼저 영향을 미칩니다. 직장・학교 계정의 폼은 폼당 최대 5,000,000건까지 응답을 받을 수 있고, 질문은 200개, 텍스트 응답은 질문당 4,000자까지입니다(이 외에도 1회 응답당 텍스트 응답 합계 200,000자라는 제한도 있지만, 이는 한 응답자가 한 번의 제출 안에서 도달하는 종류의 상한이며, 응답이 쌓여서 도달하는 것이 아닙니다). 실무에서 먼저 영향을 미치는 것은 건수가 아니라 기능 제한으로, 50,000건을 넘으면 개요 그래프・개별 응답 열람・인쇄 등을 사용할 수 없게 되어 CSV 내보내기로만 취득할 수 있습니다.⁷ 사내 접수에서 건수 상한에 도달하는 일은 거의 없지만, 장기 운영하는 폼에서는 「Forms에 쌓아 두는」 설계 자체가 영향을 미치게 됩니다. 응답이 늘어나면 내보내기 후 응답을 지우라는 안내로 되어 있어¹¹, 어느 쪽이든 이력을 둘 곳은 별도로 필요합니다.

즉 Forms는 「입력의 형태를 배포하는 도구」로서는 우수하지만, 「접수한 후를 관리하는 도구」는 아닙니다. Forms는 접수창구, 대장과 상태 관리는 SharePoint 목록, 알림과 연계는 Power Automate라는 역할 분담이, 각자의 특기 분야를 따른 정석입니다.

7. 어디까지 Forms로 받을 것인가 ── 판단표

접수창구의 도구 구성에는 단계가 있습니다. 기준을 표로 정리합니다.

판단의 감각으로는, 「의뢰자가 사내에 있는 동안은 Forms로 버틸 수 있고, 사외가 얽히면 설계를 바꾼다」입니다. 사외와의 종이・FAX・메일 첨부 주고받기를 접수창구째 재검토하는 이야기는 「FAX 수주를 웹으로 옮기려면 ── 이중 운영 기간 설계와 단계적 이행 실무」나 「메일로 도착하는 주문서・청구서 PDF를 Power Automate로 자동 처리하기 ── 저장・분류・알림・판독 설계」에서 다루고 있습니다.

8. 정리

메일과 구두 의뢰가 힘든 이유는, 의뢰의 전체량이 어디에도 없고 서식이 갖춰지지 않으며 상태가 보이지 않았기 때문이었습니다. Microsoft Forms로 입구를 하나로 만들고, 조직 내 한정+이름 기록으로 「누가 제출했는지」를 자동화하며, Power Automate로 접수 순간에 대장 기록과 접수 알림을 돌려준다. 이 형태만으로도 「그 건 어떻게 됐어요?」라는 주고받음은 상당히 사라집니다.

설계의 포인트는, 선택지 중심으로 지나치게 많이 쓰게 하지 않는 폼, 조직 내 한정과 익명의 차이에 대한 이해, 파일 업로드 제약(조직 내만・최대 10개 파일・파일당 최대 1GB) 파악, 그리고 Forms에 대장 역할을 기대하지 않는 것입니다. Forms는 접수창구, 목록이 대장, 플로우가 알림과 연계. 이 역할 분담을 지키는 접수 체계는 담당자가 바뀌어도 오래 계속 돌아갑니다. 그리고 사외로부터의 접수나 첨부, 건수와 연계 요건이 커지기 시작하면, 그때가 웹 폼 개발이나 전용 시스템을 검토할 타이밍입니다.

다음 한 걸음 ── 첫 번째를 만들 때의 체크리스트

처음부터 모든 의뢰를 하나의 폼으로 모으려 하면, 질문이 늘어나 아무도 사용하지 않게 됩니다. 먼저 한 종류만으로 통과시켜 보시기 바랍니다.

• 대상으로 삼을 의뢰를 한 종류만 선택한다(건수가 많고 서식이 흔들리는 것이 적합합니다)
• 질문은 5~10개로 억제한다. 의뢰 종류・기한・보충 설명 3가지는 반드시 넣는다
• 자유 기술은 「긴 답변」으로 한다(한 줄 텍스트의 255자 문제를 피하기 위해. 3장)
• 공개 범위를 「조직 내 한정」으로 하고, 「이름 기록」을 켠다
• 개인 폼이 아니라 그룹(팀)의 폼으로 만든다
• 전기 대상 SharePoint 목록을 먼저 만든다. 상태・담당자・대응 메모 3개 열을 반드시 갖춘다
• 플로우를 「응답 세부 정보 가져오기 → 항목 만들기 → 접수 완료 메일 → Teams 게시」 순서로 구성하고, 테스트 실행으로 1건을 통과시킨다
• 접수 완료 메일에 「언제까지 무슨 일이 일어나는지」를 적는다
• 플로우에 공동 소유자를 1명 이상 추가한다(작성자가 자리를 비워도 고칠 수 있도록)
• 2주간 운영하여, 되묻는 일이 발생한 항목을 폼의 질문에 추가한다

여기까지 되었다면, 의뢰 종류를 하나씩 추가해 갑니다. 늘려야 할 것은 폼의 질문이 아니라 종류의 선택지와 분기입니다.

관련 글

• Power Automate로 승인 흐름 만들기 ── 종이와 메일 결재·신청을 전자화하다
• Excel 대장을 SharePoint 리스트로 바꾸기 ── 공유・이력・플로우 연계로 「대장이 깨진다」를 졸업하기
• Power Automate로 업무 자동화하기 ── 클라우드 플로우・데스크톱 플로우 구분과 오류 처리 설계
• 메일로 도착하는 주문서・청구서 PDF를 Power Automate로 자동 처리하기 ── 저장・분류・알림・읽기의 설계

관련 상담 영역

합동회사 코무라소프트에서는 Microsoft 365를 활용한 사내 업무의 접수・대장・알림 구조 만들기 상담부터, Forms로는 감당할 수 없는 사외용 웹 폼・업무 시스템 개발까지 다루고 있습니다.

• 기술 상담・설계 리뷰
• Windows 앱 개발
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

Microsoft Forms의 파일 업로드 질문은 사외 사람도 사용할 수 있나요?

사용할 수 없습니다. 파일 업로드 질문은 폼의 공개 범위를 「자신이 속한 조직 내 사용자만 응답 가능」(또는 조직 내 특정 사용자)으로 설정한 경우에만 추가할 수 있으며, 조직 외에도 응답을 허용하는 설정에서는 이 질문 자체를 사용할 수 없게 됩니다. 업로드된 파일은 조직의 OneDrive for Business에 저장되며, 하나의 질문에서 최대 10개 파일, 파일당 10MB・100MB・1GB 중에서 선택한 상한까지 받을 수 있습니다. 사외에서 첨부 파일을 받고 싶은 경우에는 OneDrive/SharePoint의 파일 요청 기능을 함께 사용하거나, 웹 폼 개발을 검토합니다.

Microsoft Forms의 폼은 몇 건까지 응답을 받을 수 있나요?

직장 또는 학교 계정의 폼은 최대 5,000,000건까지 응답을 받을 수 있습니다(GCC High/DoD 환경은 50,000건). 사내 신청・의뢰 접수에서 이 상한 자체 때문에 곤란해지는 일은 거의 없지만, 50,000건을 넘으면 개요 그래프 표시나 개별 응답 열람 등의 기능을 사용할 수 없게 되어 CSV 내보내기로만 취득할 수 있습니다. 또한 응답 목록에는 상태 관리 기능이 없기 때문에, 건수와 상관없이 접수한 의뢰는 Power Automate로 SharePoint 목록에 전기하여 대장으로 관리하는 것이 정석입니다.

폼 응답자가 누구인지 자동으로 기록할 수 있나요?

공개 범위를 조직 내 한정으로 하면 기록할 수 있습니다. 「자신이 속한 조직 내 사용자만 응답 가능」으로 설정하고 「이름 기록」을 활성화하면, 응답자의 이름과 이메일 주소가 응답과 함께 자동으로 기록되어, 성명이나 소속을 굳이 입력하게 할 필요가 없어집니다. 1인 1회로 제한하는 옵션도 조직 내 한정일 때만 사용할 수 있습니다. 반대로 「모든 사용자가 응답 가능」으로 설정하면 응답은 익명이 되어 누가 제출했는지 기록되지 않습니다. 사내 신청・의뢰 접수창구는 조직 내 한정이 원칙입니다.

신청 접수창구는 Forms와 SharePoint 목록 중 어느 쪽으로 만들어야 하나요?

입력하는 사람의 편의성을 우선한다면 Forms, 대장으로서의 관리를 우선한다면 SharePoint 목록입니다. Forms는 스마트폰에서도 입력하기 쉽고 질문 분기나 필수 설정도 간단하지만, 제출 후 수정이나 진행 상황 확인이 불가능하고 응답 목록의 관리 기능도 약하다는 접수 관리 측의 약점이 있습니다. 실무에서는 「Forms로 접수하고 Power Automate로 SharePoint 목록에 전기한다」는 구성으로 만들면, 입력의 편의성과 대장 관리를 양립할 수 있습니다. 열이 많은 정형 신청에서 입력자 전원이 목록을 다룰 수 있다면, 목록의 폼으로 직접 접수하는 구성도 선택지입니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.